Creating and Understanding the Fulfillment Workflow

This tutorial aims to guide you through the process of creating a fulfillment workflow to manage the disabling of multiple accounts. First, the workflow receives a list of Business Request Items and performs the disable operation on each. Additionally, it checks basic logic, such as verifying if there are any accounts to disable using line rules.

To create the workflow, we will follow these steps:

Use the fulfillment workflow template available in Workflow Studio.
Familiarize yourself with the basic structure and activities of the provided template.
Add code/operation base activity to disable multiple accounts.
Compile and publish the workflows.

Create a Fulfillment Workflow

In this example, our goal is to create a fulfillment workflow that can handle disable all input accounts. Follow the instructions below to develop the workflow.

Login to Workflow Studio
Go to your Demo folder or any folder you have created containing sub folders Workflows>Application
Right-click on the Application folder in the Workflow Studio and select New Workflow > Fulfillment Workflow from the context menu to create a new fulfillment workflow.

Upon creation, you will see the fulfillment workflow with the following default activities. Let me give you a brief summary of these activities:

ValidateClaimedBusinessRequestItems: This activity validates the business request items associated with incoming calls from consoles, APIs, etc. It retrieves data from the database to verify the business request items exist and haven't been tampered with. It also verifies their status to ensure they are in the appropriate state (e.g., "ready for fulfillment") to be processed by the workflow. This activity also updates the Fulfillment Process ID for the business request item to indicate the workflow instance that is currently fulfilling the business request item.
SetOperationInputs: This step within the workflow extracts necessary data from business request items and transforms it into a format suitable for use as input parameters for the chosen operation activity.
DragOperationActivitiesHere: This is a placeholder where you can drag and drop additional activities into the workflow. e.g. Operation Base Activities, System Code Activity etc.
SetBusinessRequestItemStatus: This activity sets the execution status of the business request items, indicating whether it was successful or not.

Save the workflow by clicking on the Save icon in the toolbar and provide a suitable name for the fulfillment workflow. Once you save, the workflow will reload and show you the default activities.

You may notice that I used 'FW' followed by the workflow name. This is the naming convention we typically use for fulfillment workflows, though it is not mandatory. Start with the prefix 'FW' followed by a descriptive name that reflects the workflow's action. For example, a workflow that deletes accounts would be named 'FW Delete Accounts.
Additionally, if the workflow is custom-built for a particular customer, it's advisable to include a customer-specific prefix before the "FW" prefix. This prefix can be either the customer's full name or an abbreviation. For instance, a workflow designed for a customer named "Acme Corporation" could be named "AC FW Delete Accounts" (using the abbreviation "AC") or "Acme Corporation FW Delete Accounts

Now, double-click the SetOperationInputs activity, or right-click on the activity and select the first option, Edit SetOperationInputs_ExecuteCode. This will open the code editor window.

Ensure that your workflow name, rather than the template name, is set in all three locations. Repeat the same steps for the SetBusinessRequestItemStatus activity.

If the workflow name is missing in any of the three locations for both the SetOperationInputs and SetBusinessRequestItemStatus activities, save and close the workflow window. Once closed, reopen the workflow, and it will update your workflow name in all locations.

We will perform the disable account operation using the default operation available in EmpowerID. To find the necessary activity, go to the Activities pane or you can also find the activity by going the Search tab, enter the relevant search text, and select the DisableAccountOperation from the search results. Afterward, drag and drop the activity to the "Drag Operation Activities Here” placeholder.

Click on the newly added operation activity and provide a suitable name and description. In the Name field, enter ‘DisableAccount,' and in the Description text box, enter 'Disabling account for the Fulfillment workflow’.

Click the Visual Studio icon in the top bar to open the workflow or solution in Visual Studio.

Before making changes to the workflow in Visual Studio, first save and close the workflow window in Workflow Studio.

Return to Visual Studio. You may see a File Modification Detected popup. Click the Reload All button.

In Solution Explorer, double-click SetOperationInputs_ExecuteCode.cs and scroll down to the Implement method. There, you can see commented code with examples for validating the Business Request and retrieving items from the Business Request.

Add the following code after the end of the comments.

 List<Guid> accountGuids = CurrentWorkflow.ValidateBRIs.ClaimedBusinessRequestItems.Select(a=>a.RequestDataTargetResourceID.Value).Distinct().ToList();
 var targetAccounts = new E.TList<Account>(C.Account.GetByAccountGuids(accountGuids).Where(a=>!a.Disabled).ToList());
 CurrentWorkflow.DisableAccount.TargetAccounts = targetAccounts;

The above lines of code are the recommended way to retrieve data from the database in bulk.

The above code snippet demonstrates the following key concepts:

Data Retrieval from Business Request Item: In the first line, we retrieve the data from BusinessRequestItems and store it in a list of type Guid.

Efficient Data Retrieval: In the second line, it utilizes bulk retrieval methods (GetByAccountGuids) to minimize database interactions.

Pre-Processing and Filtering: In the second line, it filters the retrieved accounts to exclude those already disabled, preventing unnecessary operations.

Preparation for Bulk Operations: In the third line, it constructs a list of enabled accounts to pass to the DisableAccount operation activity, which performs the disabling action in bulk.

The approach outlined below is not recommended. Refer to the following code snippet for clarification.

       //Should never do this
       E.TList<C.Account> accounts = new E.TList<Account>();
       foreach(Guid acGuid in accountGuids) 
       {             
           C.Account ac = C.Account.GetByAccountGUID(acGuid);
           accounts.Add(ac);
       }

The issue with this approach is that it results in a separate database call for each account GUID. If the accountGuids list contains 100 GUIDs, the code will execute 100 individual database queries. This generates significant overhead and slows down the workflow considerably, especially in scenarios where multiple instances of the workflow might be running concurrently. Therefore, we should use bulk retrieval methods. If they do not exist for a specific component, ask the EmpowerID developer to create one for you.

Add the following code after this line CurrentWorkflow.BusinessRequestItemDictionary[bri.RequestDataTargetResourceID.Value] = bri;

 //Check if this item RequestDataTargetResourceID account is already disable to be ignore
 if (targetAccounts.Where(a => a.AccountGUID == bri.RequestDataTargetResourceID.Value).Any())
 {
     bri.ProcessStatus = 4;
     bri.BusinessRequestItemFulfillmentStatusID = 3;
 }

This is the complete implementation of the Implement method in the SetOperationInputs_ExecuteCode.cs class. And this is what we pass to our Operation Activity.

In Solution Explorer, open the SetBusinessRequestItemStatus_ExecuteCode.cs file. If you see red wiggly lines, it means it is pointing to the wrong workflow, so you need to replace it with your workflow name.

After replacing BRRequestItemFulfillmentTemplate with your workflow name, the code should look like this.

Add the following code snippets to the Implement method in the SetBusinessRequestItemStatus_ExecuteCode.cs file.

Remove the line of code “businessRequestItems.Add(bri);” from inside the foreach loop, and instead, add this line

just before “BusinessRequestItem.Update(businessRequestItems);”

Here is the complete code for the Implement method that you should have.

Compile and Publish the Workflow

We compile and publish the Fulfillment Workflow in Workflow Studio the same way we publish our UI workflows. Once published from Workflow Studio, we also publish them through the EmpowerID Web UI.

The Fulfillment Workflow is fundamentally linked to an Item Type Action. This linkage is configured in the No Code Flows section of the EmpowerID system, where it specifies the workflow to be executed when a Business Request Item (BRI) of that Item Type Action is approved or rejected. To learn about the No Code Flows, refer to this documentation: No Code Flows

Debug the Fulfillment Workflow

a) To debug the Fulfillment Workflow tracing is a crucial debugging tool. Tracing provides a record of the workflow's execution path and the values of variables at various stages. By examining the trace logs, you can gain valuable insights into the workflow's behaviour and pinpoint potential issues. You can add tracing to your code like this

You can check these logs in DebugView++ and Event Viewer.

b) Another way to debug the Fulfillment workflow is to use a separate machine. In the latest version, this method is not supported. To proceed, go to Infrastructure Admin → EmpowerID Servers, then click on the Server Jobs tab. In the search box, type “business request,” select the Business Request Fulfillment Job, and note the ID from the URL.

c) Open Task Manager and go to the Services tab. From there, stop the EmpowerID Worker Role Service.

d) Open the Fulfillment Workflow .cs file in Visual Studio, and place a breakpoint where needed.

e) Open the Command Prompt, navigate to the bin folder as shown in the screenshot below, and run the following command by hitting enter.

f) Attach to the w3wp processes in Visual Studio, then return to the Command Prompt and press Enter. Your breakpoint will be triggered in Visual Studio.

Summary:

The first code shape SetOperationsInput (SetOperationInputs_ExecuteCode), where we identify the component to use, such as a group or account. For optimal performance, retrieve these items in bulk rather than one by one.
Next, pass the list to an operation activity, which allows bulk processing. There are many pre-built operation activities designed for bulk actions.This approach is recommended for efficiency.
We use a dictionary (BusinessRequestItemDictionary) to map component GUIDs to Business Request Items, which helps in tracking items during status updates. This dictionary allows for efficient lookup of the relevant BRI when updating its status based on the outcome of the operation activity
After executing the Operation Base Activity, we proceed to the second code shape SetBusinessRequestItemStatus (SetBusinessRequestItemStatus_ExecuteCode).
For each operation activity that supports bulk processing, an OperationExecutionSummary is returned, providing an execution summary.
It is then the developer’s responsibility to update the status and implement the logic for status updates. The developer needs to process the OperationExecutionSummary, use the BusinessRequestItemDictionary to find the corresponding BRIs, and update their statuses accordingly
Always perform bulk updates rather than single updates for each Business Request.
Publish the Workflow and link it with the Item Type Action.