none
Missing workflow activity data after upgrading MIMWAL on server RRS feed

  • Question

  • I recently built V2.17.0927.0 MIMWAL and deployed it onto a server already running a previous version of MIMWAL V2 (not sure of the version)

    Deployment was done using the register PS script - ran it twice because the first time I had specified the incorrect SitePortalName and corrected that on second run. Except for warning about the portal name no errors were shown

    After deployment I went to update a WF and found that the contents of any activity for a WF that used a MIMWAL function no longer had any config data in it - so just the activity containers existed in the WF with no data for the activity

    Could not find any documentation indicating any specific way to update the version of the MIMWAL on a server so I assumed this was the correct method. Has there been any other reports of this type of issue

    Thanks for any assistance

    Wednesday, November 29, 2017 3:29 AM

Answers

  • Looks like you built the new version with a new signing key?? Also did you not run the UpdateWorkflowXoml script?
    • Marked as answer by Craig J Tucker Thursday, November 30, 2017 12:07 AM
    Wednesday, November 29, 2017 11:29 AM
    Owner

All replies

  • Looks like you built the new version with a new signing key?? Also did you not run the UpdateWorkflowXoml script?
    • Marked as answer by Craig J Tucker Thursday, November 30, 2017 12:07 AM
    Wednesday, November 29, 2017 11:29 AM
    Owner
  • Hi Nilesh,

    Dont think the signing using a new signing key was the issue but not reading the deployment instructions fully  where the last statement is to run the UpdateWorkflowXoml powershell script definately was. Looking at the records in the WorkflowDefination table can see the xoml includes the version for the WorkflowActivityLibrary assembly which of course was changed. Hence the workflow did not reference the new assembly version and this broke the links

    Thursday, November 30, 2017 12:15 AM
  • Running UpdateWorkflowXoml  script is a not mandatory but recommended step as it remediates many other deployment mis-steps. From the steps you had followed and you corrected the error on Portal name that would have prevented updates to assembly redirect in web.config, my money is on the signing key. If you type "assembly" without quotes at the Run prompt on the server, you can confirm the public key used by the old assemblies and can confirm if the new one has the same or not. You can also check this looking at the old Xoml as well if you have a backup copy.
    Thursday, November 30, 2017 7:35 AM
    Owner