Call is used to call a process from within another process. This is useful for maximizing code reuse and minimizing clutter in the process canvas.
For example, an EASYCommerce site will probably display the price of an item on the catalog, the item main page, and the shopping cart. However, it would be poor programming to duplicate the pricing logic on each of these pages. So, instead there is one pricing process and that is called with a Call process in each of the pages a price is needed.
Call Use Examples
Basic Use Example
In this test example, we have a process which calls a stand alone process. A stand alone process is not run through a webpart or button, but must be called from elsewhere. One of the ways this can be called is in our “Call” service.
Our simple process defines an input and then calls a test process we created. The input is defined as a static string “123abc” in the Input evaluate. This is then referenced in the Call service.
Processes should usually take the input data and transform it in some way or perform some action with it. It is good programming to always have an Output node for your process so future developers know where to reference (this is discussed more in detail later).
In our example, we are transforming the input string. As long as an input string is given, the process is successful. Here are the logs when we pass the “123abc” value.
If we wanted to reference this transformed string we could do so with WorkData/CallTestProcess/Output/Value.
Here are the process logs when our input to the process has been changed to a blank value or when process is called, but with no inputs.
The process output node returned with a message that we could return to the user if we wanted, and a Success True/False flag which we could use as a developer for our process to check if it was successful. These values and the message were predetermined by the stand alone process. Here is the output nodes configuration:
This means whenever you are using a Call process, you must be aware of the inputs it needs and the outputs it gives in order to use them correctly.
Using Call for “AddToCart”
In this example, we are choosing to reorder an item from the order history. So we look up the items and their corresponding quantity from the order history table and pass those values to an “Add To Cart” process. There are many places on the site where we can “Add To Cart”, so a separate process was created that can be called from the catalog, item main page, order history page, etc.
Here on the process canvas we an see we are ForEach-ing through the results from GetOrderDetails and if certain conditions are met, “AddItemToCart” is called.
Here is the Call service configuration. You can see the ProcessId is specified. This is the AddToCart process. The developer must know what inputs are required by the process being called. In this example, some basic information about the items to add to the cart is required and passed through in the Inputs.
When we run this process by clicking the “Reorder” button on the site, we can see in the logcs that the AddItemToCart process is called. Within the xml logs of that process, we can see our passed in input:
Referencing the Process Call’s Output Node
When stand alone processes are developed, it is good programming to end it with an Output evaluate which gives the status on what occurred. If our parent process needed to reference anything inside of a process call, it should only reference the Output node. This is because if the process ever changes, it may not be apparent to the developer that a certain service in the process should never be renamed because other processes are using that value. It should be apparent to developers that the Output node is referenced by other processes and if its format were to change, it would cause issues.
In this example we have a “Reorder” button process which reorders an order from the user’s order history. Within that process we are calling an “AddToCart” process. Here we can see the output for the AddToCart process call we made. The item we passed in was not found so a return message was returned. If we wanted we could return this message to the user on the webpage. Alternatively, we could have our reorder button process reference this ReturnCode 2 and create our own messages based on the different ReturnCodes we encounter.
Using Input XML
In this example, we have a pricing process which accepts as input the data on the items to be priced. This means the process should have a format which allows for multiple items to be sent. We could do this by passing in input xml and have the pricing process loop through the the item nodes. Here is an example of the input that would be passed to the process via the input XML:
Here we can see the Call service configuration and the EASYProcess logs for the process it is calleing. Notice the input XML was correctly passed in to the process as outlined in the service.
This pricing process then loops on the Item nodes and performs the pricing actions.