This is the fifth of a multi part series on Nav 2016 events and workflows. This post will be on how to make a workflow response.
First part : What are events and the advantages they provide.
Third Part: Creating event subscribers
Fourth Part : What are workflows and how to make a workflow step
Fifth part: Making a workflow response
Seventh Part: Assigning workflow step predecessors
Eighth Part: Putting it all together
Workflow responses are where the real work gets done inside a workflow. As we learned form the previous post. There isn’t that much to making a workflow step. In a workflow response, you can put in as much or as little code as needed. Sometimes these are only a few lines. For example setting a few fields or displaying a message on the screen. Responses work off of what ever record they are given from the workflow step. In the previous post, the example passed a customer record. If the response required additional records you will have to get them yourself. You can setup multiple responses for each workflow step. Because of this, your responses should be clear in their purpose. If you find when you are making your responses that a lot is going on, you might want to break it down into multiple responses. This way you can potential reuse your responses for other workflows.
This looks kind of familiar
A lot of the following steps are very close to how we made a workflow step.
Just like the workflow step, there are two parts to making a response. First we need to add it to the library of response. Second we need to add the code to check for our response and the actaully carry out the response.
To add our response to the library its best to setup a function that subscribes to the “OnAddWorkflowResponsesToLibrary” event from the “Workflow Response Handling” codeunit. This event will fire whenever the workflow page is opened, which will guarantee that our responses will be in the library when ever we go to add or change workflows. In the new function you just created add the in a “Workflow Response Handling” codeunit variable. The only line of code we need is the following.
WorkflowResponseHandling.AddResponseToLibrary(‘SETDEFAULTCUSTOMER’. DATABASE::Customer, ‘Set defaults on the customer record’, ‘GROUP 0’);
This will add a new response to the Library, the response ID will be ‘SETDEFAULTCUSTOMER’. It will use the customer table, and has a description of ‘Set defaults on the customer record’. Next we need to set up a function that will run this response. The ‘GROUP 0’ I will go over into a later post. What it allows you to do is add in parameters to your responses. For this example we will leave out parameters for now.
Create a new function that subscribes to “OnExecuteWorkflowResponses” in the “Workflow Response Handling codeunit. Inside this this function we get passed a boolean “ResponseExecuted” that stats weather or not this particular response was taken care of. We also get passed the record we are working with as a variant. The last parameter is the “Workflow step instance” record. The “Workflow Step Instance” table keeps track of all workflow instances that are going on at the same time.
Inside this new function we need to set up a switch:
IF WorkflowResponse.GET(ResponseWorkflowStepInstance."Function Name") THEN BEGIN
CASE WorkflowResponse."Function Name" OF
ResponseExecuted := TRUE;
Bacailly this little snipit looks to see what the response code is. If the response code is something that we want to handle then we do something about it. Make sure you set the ResponseExecuted to TRUE after you have taken care of the response. Otherwise Nav will keep looking for something to handle this response. It might even be a good idea to check to see if your response was already handled. Especially if you know other people will be using your responses. This way you can see if they overwrote your response for their own purposes. The SetCustomerDefaults is a function we will make next.
Next we need what we want our response to do. For this demo we are simply going to set a default address. For this we need to set up a funcation that takes in the customer we are going to modify as well as the Workflow Step Instance. This is mainly to get parameters but again, we wont worry about that for now. Our last function that we need will look something like the following. We need the customer record and the WorkflowStepInstance. You should also include a “WorkflowStepArgument” record variable in this function. This is mainly to get parameters but even if you dont need them its a good idea to include it anyway just in case you change the response later.
IF WorkfowStepArgument.GET(WorkflowStepInstace.Argument) THEN BEGIN
Customer.VALIDATE(Address, '123 Nav Street');
But what about…
So you might be thinking, why not do this in the Insert customer trigger? Here’s why: What happens if the user no longer wants this feature? If you put the code in the customer table you would have to do some dev work to remove it. Having it in a workflow response allows the user to do this. They can simply remove the workflow response them selves. Saves you a call/email/support ticket from the user and saves you dev time even thought the change is small. Depending on how you work with customers the change could take a week or so to get to them in the next patch.
Next we will look at changing the step/response matrix to allow only . – 03/28/2016