Post by Viorel Morosanu |
Microsoft has introduced a new development concept in Dynamics 365 for Finance and Operations (D365FO) which allows extending the standard functionality without actually modifying the original code. Customisation using overlaying is similar to the customisation approach used in the previous Dynamics AX versions, and the aim of this blog is to present, from the development point of view, a workaround to implementing a new workflow type in D365FO, based on a standard table without overlays. The key element of the solution is a new table used to store the workflow related information. The method canSubmitToWorkflow() of the new table will be used to make the Submit button available in the UI instead of overlaying the standard table.
The new Application Object Tree (AOT) elements required:
- A new table to store workflow related data
- The workflow category
- The workflow document (sometimes called the business document)
- The workflow type
The development is split in several steps to make the process easier to follow, and I have used the standard customer table to create a customer request workflow type as an example.
Step 1: Create a new workflow category
The workflow category will bind the new customer workflow type to the AR module and will add the related workflow entry into the module list page.
Step 2: Create a new enum to trace the workflow approval status in UI
The tracking information will be available in the document details form. A workflow status of Approved, Return or Denied will mark the related customer as Open, On hold or Closed.
Step 3: Create a new table to store the workflow related information
The following customisations are required for the new table:
- Keep the new customer workflow table and the standard CustTable synchronised. Use chain of command for the insert() method of the standard table, set delete actions, and restrict the delete operation for customers with workflow activity in progress.
- Only two types of join can be used to link the new customer workflow table to the standard customer table: inner and outer join. Consider the existing customers in database and create a script to populate workflow data for existing customers when inner join type is preferred.
- All fields in the new table should be read only: we use them for tracking purposes in the UI but only the workflow should update these values.
- Override the table method canSubmitToWorkflow() and add the logic to show or hide the submit button in the UI.
- Create a static method updateWorkflowState() to be called by the workflow event handlers when the status must be updated.
Step 4: Create the workflow document (query)
The workflow document is the information that will go through an approval process, in our case a customer record.
Two application elements compose a workflow document in the AOT:
- The document query – created manually by the developer
- The document class – generated by the workflow type wizard
The document query is used to expose customer fields in the workflow editor expression builder. It is a best practice to set the Fields dynamic property to No and expose the necessary information only in workflow designer.
Step 5: Create and update the workflow type block
The Workflow Type wizard will have as input the workflow category, the document query and the CustTable menu item pointing to the document details form.
The document class is one of the elements generated by the wizard. It can expose calculated fields (parm methods) used in the workflow designer to make conditional decisions. These methods are good candidates for unit testing as they do not involve user interaction.
Event handler class
From the development point of view, we control at the workflow type level whether the workflow is started, cancelled, or completed.
The workflow engine knows internally the status of the workflow. The purpose of the status field updated by this event handler class is to allow the progress to be displayed in the UI and to act on a particular workflow event.
Submit manager class
The submit manager class contains the logic to be executed once a work item is submitted (display the submit dialog, get the notes text, activate the workflow type and change the status to submitted). Make sure the workflow controls are updated after the submit operation to avoid resubmitting the same record multiple times.
Step 6: Enable the workflow on the CustTable form
At this step we enable in code the workflow for the customer table using the new form data source.
The main benefit of this approach is to keep the workflow code and data isolated. Prior to D365FO platform update 20, this was the only way of adding workflow functionality based on a standard table without overlaying the canSubmitToWorkflow() method.
D365FO platform update 20 includes extensibility enhancements that permit Chain of Command for form methods, so canSubmitToWorkflow() method is available at the form level. Also, the properties WorkflowEnabled, WorkflowDataSource and WorkflowType can be set directly at the data source level using form extensions.
Extending Microsoft Dynamics 365 for Operations Cookbook, Simon Buxton
Dynamics AX 2012 Blueprints: Developing a Product Approval Workflow, Murray Fife
Dynamics AX Workflow Wanderings: Hints and Tips for Dynamics AX Workflow, Jonathan Halland