So you have just finished developing a web solution, have created a web manifest with your myriad of changes and you go to save the manifest. Then you see something similar to:
Arrgh! So what just happened? Well apparently sometimes when saving your manifest data to the VIRTUALFILESYSTEM the data can fail to save properly. The manifest contents is actually a serialized XML file listing all of the components. Once this happens your manifest can no longer be saved, worse yet, once you close the manifest window you will never be able to open it again. This can be a real pain if you don’t remember all of the changes you had in your manifest. Sure, you could rebuild your manifest by change date, but what if there are components in the development system that have been modified within the date range you don’t want in your bundle?
Well one thing you can do is to fix the manifest. Now depending on where the save failure occurred you might end up missing some components. I have been luck in the past and have had the XML file just loose all of the closing XML tags.
The following steps can be used to try to recover your manifest. Hopefully, your recovery will be a full one, but if not at least you will be able to re-open the manifest and add back any missing items.
First open the SLX administrator and use the SQL Query tool to find your row in the VIRTUALFILESYSTEM. The query will be something like:
Select * from VIRTUALFILESYSTEM where itemname = ‘Here is my manifest name.xml’
There are actually two rows in the VFS for your manifest, one with the XML extension and one without. The XML extension is the one that contains the contents of the manifest and is the one you want.
Test your query in the SLX Admin. You should see on the bottom half of the result preview the blob data which contains the XML. You will be able to see the XML in plain text. Copy the contents of the XML, not including the Blob Size line or any empty lines before the actual start of the XML.
With the XML data copied, I find it is easiest to use Visual Studio to help me identify the malformed XML. Open the XML in VS. You will see that VS will identify improperly closed tags with red lines under them. If you float over them you will get a message “Tag not closed”:
If you scroll all the way to the bottom we should be able to start adding the missing closing tags. Start by typing “</”. VS intellisense should display what the next tag should be that needs to be closed:
Select the specified tag. Continue to do this until you close “</bundleItemHierarchy>”. Your XML should now look something like:
Now there is some special stuff after this. Depending on if your manifest contained additional action items or delete actions there may be more, but at a minimum you need the following after the “</bundleItemHierarchy>”
<bundleItem modelId=”af988c91-97c8-4527-b072-e021c9e2cb1a” itemTypeName=”Sage.Platform.BundleModel.RootBundleAction, Sage.Platform.BundleModel”>
<RootBundleAction xmlns:xsi=”http://www.w3.org/2001/XMLSchema-instance” xmlns:xsd=”http://www.w3.org/2001/XMLSchema”>
The finished XML should look something like:
Now with the completed XML, copy the entire contents of the XML (there should be no spaces before the start or at the end of the XML).
To get this back into the database you in all likelihood wont be able to use a simple query like:
update VIRTUALFILESYSTEM set itemdata = ‘[PASTE IN THE FIXED XML HERE]’ where virtualfilesystemid=’b914c7e17f0447c3ab78d6b757ec032a’
This is because the XML string in all likelihood will be long enough for SQL to treat it as a TEXT data type and you can not implicitly or explicitly convert one of these types to the other. You will likely get the following type of error:
“Implicit conversion from data type text to nvarchar is not allowed”
Instead of a straight update, you can use the WRITETEXT method in a T-SQL statement. The following should work:
EXEC sp_dboption ‘slx75_dev’, ‘select into/bulkcopy’, ‘true’
DECLARE @ptrval binary(16)
SELECT @ptrval = TEXTPTR(itemdata)
WRITETEXT virtualfilesystem.itemdata @ptrval
‘[PASTE IN THE FIXED XML HERE]’
EXEC sp_dboption ‘slx75__dev’, ‘select into/bulkcopy’, ‘false’
You obviously need to change the value in your statement in the sp_dboption calls to your SalesLogix database name and also change the WHERE line to match a criteria that uniquely identifies the row you want to update in the VFS.
OK so after running the update command, cross your fingers…
Reload your project in the SalesLogix Application Architect, or log back in and you should now be able to see the previously corrupted manifest. Hopefully it will contain all of the missing components. If you still get errors, unfortunately that means that the XML wasn’t just missing the closing tags and part of the XML is actually missing.
So What causes this? It appears that if there is any problem with the manifest (Something having been deleted, or if the manifest had something removed yet the category designator still exists in the manifest it will error out when saving. ALWAYS PRESS THE VALIDATE ALL ITEMS BUTTON IN THE BUNDLE ITEMS TAB BEFORE SAVING THE MANIFEST! If you get an error DO NOT SAVE! This will corrupt your XML file and make further changes to the manifest impossible.
Hopefully Sage will address this rather serious potential issue soon.