Stopped (error): Failed to find workflow instance. Failed to find workflow instance.

We recently recently came across an issue at a client site where workflows instances would be completed but the status would be “Stopped (error)” with error messages saying “Failed to find workflow instance. Failed to find workflow instance. Failed to find workflow instance. Failed to find workflow instance” after investigating the issue for quite a while and not finding a solution I eventually found a post at “Peng’s Dynamics AX“ Blog where he listed a hotfix that Microsoft released to resolve this bug. The knowledge base article for KB2398999 and download link can be found at: http://support.microsoft.com/hotfix/KBHotfix.aspx?kbnum=2398999&kbln=en-us&sd=mbs#step2

Thanks to Peng for reporting this issue to Microsoft and following up with them for a year! You can view the original blog post here.

Resource Page for Known issues in AX2009 Workflow

Recently came across this blog page with a list of workflow resources including hotfixes videos etc…

https://community.dynamics.com/product/ax/axtechnical/b/axresources/archive/2012/02/13/resource-page-for-workflow-in-microsoft-dynamics-ax-2009.aspx

X++ Exception: Workitem could not be created.

I have been doing some tests with a new custom workflow and came across the following scenario. (Note: this describes a solution to one of the many issues that may cause this error message)

I developed a custom workflow and its setup its corresponding configuration, I was able to submit and everything but ended up getting the following error in my workflow history when the workflow system tried to assign a workitem to me:

Stopped (error): X++ Exception: Work item could not be created. 
Insufficient rights for user Jonathan.
 at SysWorkflowWorkItem-create 
SysWorkflowWorkItem-createWorkItems 
SysWorkflow-save SysWorkflowQueue-resume 
SysWorkflowMessageQueueManager-executeTask 
SysWorkflowMessageQ

After exploring for a while I found an additional line on my batch server’s event log stating “X++ Exception: The workflow system could not access the business document data. Report this issue to your system administrator.” which once can trace back to line 68 of the SysWorkflowDocument.assertAsUser method.

I reviewed the query linked to my workflow document of my custom template and realized that one of the links or ranges caused no records to be returned, ever. Fixing the query and resuming my workflow caused the workitem to process correctly.

Unfortunately this error message was a bit cryptic for the actual issue at hand, but I hope this will help someone who runs into the same issue in the future.

Workflow threw an exception for the following reason: Class MyDocumentClass cannot be instantiated.

I’ve been battling trying to get one of my new AX2012 workflows to function properly. Whenever one tries to create a configuration against the template the info dialog says “An unexpected error has occurred while opening the workflow. See the event log on the AOS and contact your system administrator to resolve the issue.” Reviewing the event log gives the error “Workflow threw an exception for the following reason: Class MyWorkflowTypeDocument cannot be instantiated.“

Resolving the issue required me to make use of the “Generate Full CIL” function in the AX developer workspace. Located on the toolbar to the right of the AOT button. Initially this didn’t help as some other classes or tables (still in development) didn’t compile (even unrelated to workflow). After removing these offending classes and tables and regenerating the CIL I was able to create a new workflow configuration

Workflow history error – Stopped (error): Could not find user

If you have ever coded with the WorkflowParticipant provider class you may have come across the following stop error in workflow history “Stopped (error): Could not find user”. After spending a couple of hours tracing through code I eventually located the cause of the error.

In my case the participant provider class is supposed to retrieve an employeeId from a form and translate it to a userID which it  then returns in the WorkflowUserList. However in my case no user relation had been setup between the employee and the user thus the class ended up adding an empty user to the list causing the SysWorkflowProviderService::resolveDueDateAsUser  method to fail as there it couldnt find the blank user. Thus:

Resolution:
1. Always check the user id’s that you are adding to WorkflowUserList that your provider returns, to ensure that they are not empty.

E.G: Wrong:

userList.add(SysCompanyUserInfo::emplId2UserId(resp);

Right:

respUser = SysCompanyUserInfo::emplId2UserId(resp); 
if (respUser == '') { 
    throw error(strfmt("No user relationship defined for employee %1",resp)); 
} 
userList.add(respUser);

Rollup 7 Released

Microsoft has release rollup 7 for Microsoft Dynamics AX 2009 service pack 1. Of course the most interesting part to me are the two workflow bugs that it resolves.

1. One can start multiple workflow instances for the same record
2. Records in the workflow history form are displayed very slowly

We’ve come across both of these issues and are really glad that official fixes have now been released.

Happy Daxing

Rollup 6 Workflow fixes

With the release of Hotfix Rollup 6 for Dynamics AX, it seems like a number of issues relating to workflow have been resolved. Checkout the full list over at the Knowledge Base. The one in particular that I’m quite interested in relates to last weeks post on security issues for workflow.

The work-items that were being created when that issue occured remained in status pending and were not removed from the processing queue. The hotfix (KB971260) makes a change to the SysWorkflowEventDispatcher class to catch the error and stop the workitem from processing. It doesn’t seem like the correct security is being applied as yet.

 

Why is my yellow workflow bar not displaying

My most common complaint regarding workflow from users or developers is “MY YELLOW WORKFLOW BAR IS NOT DISPLAYING”. So here is my mental checklist of probable causes to help resolve this common issue (this is a list in progress as there always seems to be a a new reason for why this is happening, so if you have found additional reasons please post them in the comments below)

1) Check that your canSubmitToWorkflow method on your form is returning true, if you are trying to submit to workflow. It may be that the rules that are setup are not allowing the record to be submitted. e.g. no lines have been added yet for the Purchase Req.
2) If the user is supposed to be approving the record, check that the record is still assigned to him (Basic -> Workflow History). This sounds silly but users often see the email notification in outlook and try and approve their again when it may already have been approved or escalated.
3) Check that a workflow configuration exists and is marked as active for the record type in question
4) Ensure that your form is workflow enabled.
5) Ensure that the correct data source is marked as the workflow data source for your form.

If you are still struggling, here are some less common reasons
1) No submit menuitem has been defined for workflow template selected as the active workflow configuration. I’ve experienced this when I’ve got 2 workflow configurations for the same record type with the first configuration kicking off the second one as a sub-workflow. In this case the second workflow does not require a submit menuitem. However Dynamics AX marks both as default and may pick-up the one without the submit button as the default and subsequently not anything because no submit button is available.

Happy Daxing.

No action bar displayed when accessing from email

I recently discovered another weird quirk in workflow relating to jumping directly to a record in AX from an email notification. If you are running in a multi-company environment and the user’s default company is different from the company in which the workflow document resides, the yellow workflow bar will not be displayed when accessing the record directly via the drill-down functionality in workflow notification emails, assuming that there was no already opened AX client. Re-opening the form manually reveals the workflow bar.

It appears that the sequence in which the AX client and user defaults are loaded causes the SysWorkflowFormControls class to not be in the correct company context when trying to load the necessary workitems/actions for the record in question.

Solution:
My work-around for this is to perform a manual changecompany around the code in the SysWorkflowFormControls.showWorkItemActions method.

e.g.

changecompany(_workItemTable.CompanyId)
{
...
}

I hope this helps someone resolve this rather strange error.

Regards
Jonathan

Importing workflows – Configuration IDs

I have just been doing some exporting and importing of workflow configurations from one company account into another and noted something possibly expected, yet strange.

When importing, the new workflow configuration that is created maintains the configuration id that existed in the company that the workflow was exported out of, instead of allocating a new configuration id. If the number sequences are the similar e.g ####_200 in both systems then there shouldn’t be to much of an issue, however if the number sequences are quite unique per company your configuration ids may be become inconsistent. In our case the number sequences contain a different suffix per company e.g ####_200CEE and ####_200CEU.

I’m not sure if I would classify this as a bug or desired functionality, but it is definitely something to take note of when doing imports and exports.