Evaluate Overview

The service “Evaluate” is used to store useful information for the process. We could basically put any XSLT and/or its functions into the “expression” and store it for later use in the process. Some of the common uses of this service are to store inputs, store outputs, used as a counter in loops, perform arithmetic or string manipulations, and etc. This service also comes in very handy when we want to maintain a good readable and easy to follow process canvas.

Evaluate Use Examples

Evaluate Basic Use

In this example we have a field for Name in [LastName], [FirstName] format. In the “Test Evaluate” button process we have an Evaluate service named “GetName”. Within “GetName”, we are using xslt substring functions to retrieve the FirstName and LastName values. We accomplish this by parsing the user-entered input string for FullName.

Here’s a closer look at the Evaluate service configuration:

Notice that we’re using XSLT functions substring-after and substring-before to get first and last names respectively. In this way we can use first name and last name later in the process without having to use substring functions again.

Here’s how the output logs for the Evaluate “GetName” service:

Storing a Variable for a Process

In this example, we use the Evaluate service to store the Shopping Cart’s “View Type” variable in a process and then reference this variable later in the same process.

This is useful when there are multiple branches of a process that will retrieve a variable different ways. The rest of the process will use the variable exactly the same, so in order to cut down on duplicate logic, we have each branch of the process define the variable in their own way.

Here we can see the process canvas:

In this process we want to retrieve the Shopping Cart’s View Type value. This can be either “Content” or “Grid”. Here are all the following cases we can encounter:

  1. The user has previously selected a view type which was saved to a cookie. We retrieve this value from the cookie and will load the page in the user selected view type.
  2. The user has not previously selected a view type for the shopping cart. We will load the page in its default view (which we save in a Configuration Variable).

In both branches of the button process, an Evaluate service named “CartViewType” is used to store the variable in an Eval named “View”. This creates a “CartViewType/View” variable (whose value can be either “Content” or “Gridview”) within the WorkData of the process that we can reference later.

Here are the two Evaluate service configurations:

Evaluate 1

Evaluate 2

Notice that we’ve named both the evaluates as “CartViewType” and the evaluate node as “View”. This way we can use “WorkData/CartViewType/View” in “BinaryDecision” service without worrying about which Evaluate runs. See below the Binary Decision:

The result of the binary decisions determine which visibility of areas on the page.

Storing a QueryToRun

A common use for evaluates is storing a SQL query which will be referenced later when we actually want to run it.

This could be done to store the text of the query and then reference it in two Queries. In the example below, the query to JDE needs to be made twice. The first RunQuery returns the results, but it then only returns the requested records. So if 100 records exist, this query only returns the top N records (where N is a process input value). The second RunQuery need to run the query again to find out how many records exist total.

This could also be done so that two process flow branches could each create a QueryToRun variable and the actual RunQuery can then reference it and not have to know which branch it came from.

Maintaining a Sum in a Loop

Sometimes as you For-Each through results you would like to maintain a running sum. This can be achieved through an EASYProcess ForEach loop and “Sum” Evaluate which is set override itself (NewSum=OldSum+[value]).

In this example we have a table which has user input textboxes. The table has three columns. The product code, a column which denotes if order is placed or not, and a user input for the product cost. Our objective here is to return a total sum of all the the products that have been ordered and display it on the page as “Grand Total”. To achieve this we first run a split over the desired columns. In this case the columns “Order Placed” and “Product Cost” are relevant to us.

Now we set up a For-Each loop that will iterate through the results of the Split service. Before the For-Each loop begins, we set a variable “Sum” as 0. This will be our running count which will grow as we continue the loop.

Inside the Split’s for-each loop, we can first check if the “OrderPlaced” flag is true. When it is equal to “True”, we add its value to the running sum with the “Sum” Evaluate service. Finally when the loop is finished, we have our final total in the “Sum” Evaluate service.

In the SetFieldProperties, we set the “Grand Total” text box with the sum variable by referencing the “Sum” evaluate.

Here we can see that we have two evaluate services named “Sum”.

  • The outer “Sum” contains an eval named “Total” that has been initialized to 0.
  • The inner “Sum” also contains an eval named “Total”. Here the value of total is set to the effect: (Sum/Total + Split/ProductCost)

This way the inner “Sum” will start off with 0 as the seed value and keep updating itself with the calculated total of the incoming ProductCosts also while making sure their OrderPlaced flag is true. In our example Sum/Total will increment as follows:

  1. Sum/Total = 0 + 12.49 = 12.49
  2. Sum/Total = 12.49 + 14.99 = 27.48
  3. Sum/Total = 27.48 + 9.99 = 37.47

IMPORTANT: For a service to work like this, the OverrideExistingOutput property for the service needs to be set to True.

Below are screenshots of how the sum increments while the For-Each loop runs the rows one after the other.