Monday, October 13, 2014

Bizagi - Load Balancing - Where to specify the URL used in notifications to point to the load balancer?

Bizagi sends notifications to users when they are assigned to a particular task, this is known as Automatic notifications, these notifications include the following default message:

Here is a brief information about the case 1251 (Id Case: 1251):<br>Creation Date: 10/13/2014<br>Category: Processes<br>Process Definition: Vacation Request<br><br>Click here <a href=3Dhttp://dev-mymachine/BizagiApp/default.aspx?widget=3Dactivityform&idCase=3D1251>1251</a> to view the case online.

As default Bizagi will use the machine name where it was generated as part of the link, if you want to point these links to the load balancer address you will need to configure the PROTOCOL, SERVER_NAME and APP_NAME based on your configuration, to do this you will need to add the following elements to your WebApplication/web.config file:


    <add key="SERVER_NAME" value="LoadBalancerHostName" />
    <add key="APP_NAME" value="BizagiApplication" />

This will produce the following output:

Here is a brief information about the case 1251 (Id Case: 1251):<br>Creation Date: 10/13/2014<br>Category: Processes<br>Process Definition: Vacation Request<br><br>Click here <a href=3Dhttp://LoadBalancerHostName/BizagiApplication/default.aspx?widget=3Dactivityform&idCase=3D1251>1251</a> to view the case online.

Which will point users to the load balancer instead of the cluster machine

Friday, August 22, 2014

Bizagi Sub Processes Parent / Child

Sub processes is one of the best reusable elements that you can use to support your business, they allow you to encapsulate logic and share it with other processes, but it's also one of the elements that creates coupling, the concept is fully explained here: "Loose Coupling". So how do you design sub processes that are truly re-usable and easy to maintain?

Sub-processes as a functions


The typical approach to use sub processes creates dependencies between the caller and the sub process, therefore any change to the parent may impact the child and same applies for the changes in the child, that's called highly coupled design. To work around this and create cleaner processes you should consider your sub processes as "functions" that will be called and return a result. Let me clarify this with a simple "hello world!" code. Let's imagine that you want to create a sub process to standarise the "greeting" messages, therefore you want to solve this problem:

function parent() {
    recover_name;

    child_create_greeting(); 

    print greeting message;
}
Current approach most of the times:
var name;
var greeting;
function parent() {
    name = recover name;

    child_create_greeting();

    print greeting message;
}

function child_create_greeting() {
    greeting = "Hello " + name;
}
I know this is a silly sample, but bear with me for a moment, and check the next approach:
function parent() {
    var name = recover name;

    var greeting = child_create_greeting(name);

    print greeting message;
}

function child_create_greeting(name) {
    greeting = "Hello " + name;
    return greeting;
}
The result is the same, but now your child and parent may evolve without impacting each other every time you do a change. Same concept could be applied in Bizagi processes, in the sample above I was using the variables name and greeting to share information with the parent, but what if I create a "message" envelop, that both processes share and act as communication between both? something like this:
message {
    var name;
    var greeting;
}
function parent() {
    message.name = recover name;

    child_create_greeting(message);

    print message.greeting;
}

function child_create_greeting(message) {
    message.greeting = "Hello " + message.name;
}
This creates an element where both processes will agreed as sharing mechanism and therefore they will be able to evolve without any impact, as long as the "message" element follows the original agreement. This translated to Bizagi concepts is just an entity that will hold the information that sub-process requires and where it will store the result of it's work. The responsibility of the caller process is to create the message instance, assign the parameters and then use the result stored there. Does it make sense? let's see it in action:

A real problem

The "Hello world!" sample is good way to explain basic concepts, but let's face it, it's worthless if you don't see something that it's applicable to real life problems, so here's a typical problem: "Our company requires an standard way to authorize different requests across our organization, therefore we need a reusable sub process that will be plugged in processes like, but not limited to: Travel Expenses and Vacations".

Model your sub processes as reusable process

The first step is understanding that your approval process will have different contexts and therefore it should be modeled with that independence in mind, the trick here is to be able to understand that your sub process is not approving Expenses or Vacations, it's approving a Requests (Value of the expense) or actions (Taking vacations), and therefore you will model your sub process to approve "requests" or "actions".

The Process and sub process definition

Vacation request:



Approval:



Data Models

Vacaction Request Model



Approval Sub Process Model



As you may noticed the M_Message entity is used in both processes, I added the suffix _I or _O for Input and Output to make it easier to understand. Now it's time to fill in the variables and passing them from the caller to the sub process, let's jump to code.

Passing "parameters" to the sub process

As explained above the M_Message entity will be used as communication element between the caller and the sub process, and therefore any element require by the Approval Sub process should be placed there, that includes simple data, like "Value to approve", "Date requested" and Entities (like Employee, Request Detail, etc), here I'm using "request type" to enable the sub process to handle different kinds of messages.
var reqType = CHelper.getEntityAttrib("P_RequestType","idP_RequestType","RT_Code = 'REQ'");
<VacationRequest.entApproveRequest.entRequestType_I> = reqType;
var requestMessage = String.Format("Requesting vacactions starting from {0} for {1} days.", <VacationRequest.dStartDate>, <VacationRequest.iDays>);
<VacationRequest.entApproveRequest.entRequest_I.RequestDescription> = requestMessage;
This step is just populating the "message" that we are using to pass the values, now we will set the entity to the attribute that will be referenced in the sub process, <Sub_Approval.entMessage>


Congratulations, you've just created a re-usable sub process that is truly re-usable and it wont break the parent caller every time you create a change on it, and the most important element, you can reuse it in any process without changing the sub process to adapt new callers. Love to hear your comments!