Installation and Configuration

I’ve just completed reading through the installation and configuration manual for AX2012 and came across chapter 5 on workflow. This chapter is a must read for anyone starting out in workflow on Microsoft Dynamics AX2012. It covers/explains all the topics that one needs to know about workflow (apart from the development side) including:

1. Descriptions of all the available workflow types (previously templates) from the following modules
   1. Accounts Payable (Invoiceing, payments, remittance etc..)
   2. Accounts Recievable (Journals, Free text invoices, customer payments etc…)
   3. General Ledger and Fixed Asset workflows
   4. Budgeting
   5. Travel and Expense (Cash advance, expense report, travel, dispute management etc…)
   6. Procurement and Sourcing (Catalogs, Purchase requisitions, Purchase Orders, Vendor modifications etc…)
   7. Project Management and Accounting
   8. User management
   9. Organisation workflows.
2. Configuring the workflow environment
   1. Email templates (both generic and configuration specific templates)
   2. Batch Job setups
   3. Notification setups
   4. Workflow queue setups
   5. Explanation of the workflow infrastructure and how all the components interact with each other.
3. Creating configurations
   1. Line level workflows
   2. Conditional and manual decisions
   3. The graphical workflow configuration utility
   4. Workitem assignments (queues, hierarchies, workflow users, workflow roles)
   5. Approval policies
   6. Versioning.

All in all this manual is well worth the read for first time users.

Happy Daxing

Download at partnersource: https://mbs.microsoft.com/partnersource/communities/training/trainingmaterials/student/course80221.htm?printpage=false

Setting up notifications on Approvals

Yesterday i received a query from a client on how to setup a notification so that the person who submits a document to workflow gets notified once it had been approved. I quickly recorded the following screencast. I recommend watching it in high quality otherwise everything is a bit small.

Cancel Workflow – The Process

I always think better with diagrams, so I quickly drew up this diagram on when code gets executed after a user has clicked the “Cancel” button on either the workflow history form or the document’s (e.g. PurchReq) form. This helps me to know how to clean up my document on cancellation, by placing the code in the correct place.

Cancel Workflow Process

Look out for a more detailed document on the rest of workflow in the next few weeks.

Security Keys for Workflow History

I’ve recently been working on a client site setting up security in Dynamics AX workflow and the question of access to the workflow history form (accessed via yellow workflow bar) as well as the re-assign, resume and cancel buttons on that form was raised. After a few minutes investigation I found them under the SecurityKey BasicMisc.

Remember that turning off access to workflow history via the security key will remove the Workflow History button from Basic -> Enquiries as well as from your Yellow Workflow Bar

Summarised: (Label, Key)
“View History” – > WorkflowViewHistory (key)
“Resume” -> WorkflowStatusResume (key)
“Reassign” -> WorkflowStatusReassignWorkItem (key)

How to run multiple Dyanamics AX workflow websites on IIS 7

Previously I have written up a post on how to run multiple workflow websites on the same server. The instructions are pretty IIS 6.0 specific, so here is an update on how to do this on IIS 7.

Step 1 – Create a new business connector configuration
1. Click start, control panel, administrative tools, Microsoft Dynamics AX 2009 Configuration.
2. Select Busines Connector from “Configuration Target”
3. Click Manage, Create Configuration.
4. Provide an intuitive name for the business connector configuration e.g. AX2009_DEV. You will need to use this in a few minutes again, so make a note of it.
5. Click ok.
6. Select Connection tab, select the AOS that is already there and click edit.
7.  Provide the correct server name, instance name and TCP/IP port, click ok.
8. Click apply to save your new configuration.
9. Select your previously selected configuration and click ok (this is so that your already existing website will still work).

Step 2 – Duplicate the website files
1. Open up My Computer and navigate to c:/Program Files/Microsoft Dynamics AX/50
2. Duplicate the Workflow folder  and rename the new folder to something intuative like “WorkflowDev”
3. Edit the web.config file inside the newly created folder using Notepad or similar text editor.
4. Replace the line “<appSettings/>” with

<appSettings>
<add key="BUSINESS_CONNECTOR_CONFIGURATION" value="[BUSINESS CONNECTOR NAME FROM STEP 1.4]" />
</appSettings>

5. Save and exit notepad

Step 3 – Create your website application pool
1. Open IIS Manager: Start, Control panel, Administrative Tools, Internet Information Services (IIS) Manager
2. Expand your server node, Click application pools.
3. Click add Application Pool (on the right)
4. Enter and Application pool name E.G. MicrosoftDynamicsAXWorkflow50Dev
5. Select .Net Framework v2.0.50727
6. Select Classic from the Managed pipeline mode.
7. Click ok to close.
8. Select your newly created application pool, click advanced settings.
9. Ensure that the managed Pipleine mode is set to classic.
10. Under Process Model -> Identity, click “…”, select custom account, click select, enter your bcproxy account details used for your previous workflow website. e.g. domain\bcproxy. Click ok to close, click ok to close the select window.
11.  Set the IdleTime-out (minutes) setting to 0.
12. Set Regular Time Inteval (minutes) (under Recycling section) to 0.
13. Click ok. Your application pool is now setup.

Step 4 – Create Application
1. In IIS Manager, expand the Sites node, expand “default website”
2. Right click on default website and click “Add Application”
3. Provide a name for your application e.g. MicrosoftDynamicsAXWorkflow50Dev
4. Select the application pool you created in step 3
5. Under the physical path node click … and browse to the folder you copied in step 2. e.g. C:/Program Files/Microsoft Dynamics AX/50/WorkflowDev, click ok
6. Ensure that your connect as settings are set to Pass-through authentication.
7. Click ok.

Step 5 – Select your website with AX.
1. In Dynamics AX 2009, naviagate to Administration -> Setup -> Workflow Infrastructure configuration wizard, under website select your new application that you created e.g. http://myserver:80/MicroftDynamicsAXWorkflow50Dev
2. Validate the website and complete the wizard.

You should now have multiple workflow websites running successfully in IIS 7.0

For more information on setting up your workflow infrastructure in dyanmics Ax 2009 check out this post.

Happy Daxing!

Security issues in assigning workflow items

Recently I’ve been having some issues regarding security rights in workflow in Dynamics AX 2009. We keep on receiving the following error: Stopped (error): Work item could not be created. Insufficient rights for user [USERID].

After some investigation I found the code being executed that checks security when assigning workitems at SysWorkflowEventDispatcher::completeWorkItem() line 63. There are three checks done. But the two that I was interested in were the checks for 1. Menu Item access to the Workflow Document Menu Item specified on the approval/task AOT element and 2. Document access to the record in question.

I checked and confirmed that the user in question had sufficient rights for the Menu Item and Table, yet the workitem still refused to process, however once I gave the user full rights for the security keys to which the table and menu item belonged the workitem was able to assign correctly. E.g. The user had permissions to read and write to the PurchaseReqTable, but didn’t have full rights to the Security Key VendTables, once full rights were given on the security key all worked fine.

This is just my observation of the security and how it practically works out (see link to official documentation below), unfortunately this is not desirable behavior in workflow, as it reduces the security control available to administrators. I was able to overcome the menuitem issue by creating my own menuitem and assigning it a unique security key. However for the PurchReqTable I decided to leave the security as is because of other implications of changing it. If however you have your own custom table that you are working off, you would be able to assign a unique security key to it.

Happy Daxing.

Microsoft documentation on security in workflow : http://msdn.microsoft.com/en-us/library/cc641033.aspx

Demo leave application workflow template

This last week I have been away in Kenya again doing some development training for Microsoft partners in the area. The last item of our training was a crash course in workflow development where we attempted to get through creating a Leave application workflow template including an associated form, table, status enum etc in the last afternoon of the training. For those of you who attended the training and would like to download the demo, please find the attached XPO (this is just a demo and has not intended for use in production at all).

To get this workflow to run you can following the following steps:
1. Import XPO into your environment.
2. Add the LeaveApplication menu item to one of your module menu’s (optional)
3.  Restart AX client
4. Open Workflow configurations under Accounts Payable -> Setup
5. Create a new configuration, by selecting new and then choosing ‘Leave application…’
6. Configure the workflow by providing the relevant instructions and assignee.
7. Open the Leave Application form and create records. Once saved these records should be available for submission to workflow. A yellow workflow bar should appear with a ‘Submit’ button
8. Click submit.
9. Run the form ‘tutorial_workflowprocessor’ under the forms node in your AOT to get your workitems to processs. Click start.
10. Refresh your Leave application form.
11. Check out your workflow history to confirm that the record has been processed.

Happy Daxing

XPO Download

Workflow Wishlist #2 – onDelegateEvent

Wish:
The second item on my wishlist for Dynamics AX workflow is to have an “onDelegateEventHandler” option available for tasks and approvals. I must admit that this would most probably not be a very widely used function within AX workflow, but here is why I would like to have one.

Given the way that workflow manages the assignment of workitems, there is no way of determining when and to whom tasks are assigned to people, in order to perform some type of custom action like updating an external system or table. Even making use of custom ParticipantProviders, one does not have a guarantee that it will end up at the person that your provider class is returning, due to delegation settings.

Thus an onDelegate event handler would be very useful. Unfortunately workflow does not have any eventhandlers for individual workitems, rather just set on tasks, so this may be difficult to accomplish.

My workaround:
It is relatively easy to tap into the WorkflowTrackingTable’s (Table) saveTracking Method and kick off some custom action using the record ‘trackingTable’. The trackingTable record contains a useful field  called TrackingType (enum WorkflowTrackingType) which can provide you with more informations as to what has just occurred. E.g. WorkflowTrackingType::Delegate, WorkflowTrackingType::EscalationPath, WorkflowTrackingType::Creation. Using this you can then perform whatever action you would like to do e.g.

if (trackingTable.TrackingContext == WorkflowTrackingContext::WorkItem)
{
  if (trackingTable.TrackingType == WorkflowTrackingType::Creation)
  {
        doAction(trackingTable.User); //this is the user to whom the workitem has finally been assigned 
  }
  else if ((trackinTable.TrackingType == WorkflowTrackingType::Delegation) || (trackingTable.TrackingType == WorkflowTrackingType::EscalationPath))
  {
       doAction(trackingTable.ToUser); //to whom the workitem is now assigned (delegated/escalated)
  }
}

N.B. Be warned, you are modifying system classes so be careful when you are installing new hotfixes or upgrading.

Happy Daxing

Comments Suggestions?

Workflow Wishlist:

#1. canApprove / canReject Logic

#2. onDelegateEvent

#3. canSubmit logic

Workflow Wishlist #1

Through my Dynamics AX workflow development, there has been a number of features that I would really like to see implemented in future versions of AX workflow.

So over the next while I will publish a number of them along with my work-arounds in the mean time.

#1 – canApprove/canComplete/canReject logic
I’m not sure if others struggle with this issue, but I would love to see logic built into the AX workflow framework that allows one to specify conditions that the workflow document must meet before the user can complete a step. E.g. A purchase requisition is submitted to the company’s buying department for a completion task, where certain fields such as vendorID must be filled in. The workitem owner should not be able to complete the workitem until the condition has been met.

It would be really great to see some form of logic built into the AX workflow configuration form to allow for creating a canComplete/canApprove condition (similar to the automatic actions conditions).

My workaround: Its easy enough to build this type of logic into the Approve/Complete menuitem class for the task or approval. Where the workitem is simply not actioned if the condition is not met. On the one hand this allows for much more flexibility in your rules, however every configuration that one sets up will be forced to use the same rules.

Please let me know of ways that you have managed to workaround this issue or whether you would find this type of thing valuable.

Workflow Wishlist:

#1. canApprove / canReject Logic

#2. onDelegateEvent

#3. canSubmit logic

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.