Adding and defining tasks

The first step in defining a Business Process is to add tasks to the Script section of the Business Process editor.

1. In the Business Process editor, under Script, click the Add button.
2. Under the Task column, click Click to select task to prompt a list of tasks to choose. The list of tasks includes both objects you've created within the Project (i.e. Adapters, Rulesets, etc.) and general tasks (i.e. Add, CompareValues, etc.). Double-click to select the object you want to use/what you want to do.
3. Click in the Label column to create a label for this task. Although you can label the task anything (or leave blank), it is best to choose a name that allows you to clearly identify the task it corresponds with, especially when performing similar tasks. For example, if you have two tasks that use CreateFile, you should label them in a way that distinguishes them. Such as:
   • createfileA
   • createfileB

   Likewise, if using multiple objects, such as File Adapters, be sure to make them specific. For example:

   • fileReadAdt
   • fileWriteAdt

Labels can come into play when sequencing tasks as you define your Business Process.

Defining Properties

With the task highlighted, view the Properties tab. Set parameters in this tab.

Note: You may be wondering: "Didn't I set my parameters within each object?" The short answer is yes. When you create an object, you define what it does within the object. For example, if you create a File Read Adapter, you define within the adapter the File Path and File Names for which files it should read.

The parameters within a Business Process allow Clarify to pass data between objects and tasks. The data contained in the file that the File Adapter reads must be passed to the Execute Transformation task for transformation. It is the data (temporarily housed in a node in Clarify) being passed that you must create parameters for.

Node parameters you'll encounter in the Business Process editor include:

• Storage Nodes: a container for temporary data to be passed between objects and tasks. When an object reads or picks up data, a Storage node is created.
• Source Node: points Clarify to the existing storage node it needs to use. For example, a Ruleset can't read data from a file but it can transform that data if it’s in a node.
• Target Node: when a task or object changes the source data, the new, changed temporary data becomes target data. That target data, under its new name, can then be written or further manipulated.
• Update Node: a container for temporary data used to update a database
• Source Context Node: a container for the internal context values to populate the environment (env) and global (glb) levels of the Variables tab in a Ruleset editor. (For example, the sender ID and receiver ID for an inbound EDI document, as they would be included in the environment level in the Variables tab.)
• Target Context Node: a container for the internal context values contained within the environment and global levels of the Variables tab from a Ruleset. (For example, a global level variable value populated in the Ruleset.)

For example, if you add a File Read Adapter to the script, highlight that File Read Adapter task, and view the Properties tab, you will be asked to define:

• storageNodes: to the right, Clarify indicates this will be the adapter's payload

When you click in a storageNodes parameter, a blank list will pop up and present you with the options to create a New Parameter or New Variable.

• A parameter is used to supply data between Business Processes and other objects. A parameter in one Business Process can receive variable data from another Business Process.
• A variable is data created inside the Business Process and used only in the Business Process where it was created. If a task inside the Business Process retrieves the initial data, and that data is written in the same Business Process, create a variable.

For example, a File Read Adapter populates the variable with data automatically. Its source node contains the data the File Read Adapter got directly, therefore it uses a variable. If it can be populated inside this Business Process task or object, then a variable should be used.

On the other hand, a File Monitor picks up data and passes it to an Event, and the Event passes the data to a Business Process. Because the data is being passed from object to object before coming into a Business Process, a parameter must be used.

Another example could occur between two Business Processes. Suppose you want to take data in Business Process 1 and make it an email attachment to be sent from Business Process 2. You can populate the target data in Business Process 1 using a variable. Then, pass the variable into the Business Process 2's parameter which can send the email with the data attached.

The most common data types for a parameter or variable are:

• StorageNode: Data from a single file or source
• Array: Data from multiple files or source. This would be used, for example, with MGets or MPuts.
• String: A string of characters

Double-click to choose a data type. The new variable or parameter appears with a default name under the Variables section in the top-right corner of the Business Process editor.

Click on the default name and rename the variable or parameter. The names of nodes are arbitrary, but if your Business Process contains many data manipulations, node names can quickly become important. When naming nodes, try to give some indication of where the data came from and what format it is in.

When you define the properties of a task that uses that data - for example, the Ruleset, that sourceNode variable will be available to select.

For example, suppose you have a File Read Adapter, a Ruleset, and a File Write Adapter in your Business Process:

• The File Read Adapter reads data and populates a newly-created storage node variable named incoming-data.
• The Ruleset transforms that data. For its source node variable, you would use the previously created incoming-data.
• The transformed data would need its own storage node to reside in. The Ruleset populates a newly created storage node variable named outgoing-data.
• The File Write Adapter writes the transformed data to a file. For its source node variable, you would use the previously created outgoing data.

In addition to nodes, parameters in the Properties tab change based on the task being defined. For example, a Ruleset task needs its settings defined (which would be its Transformation Settings object). A SendEmail task needs values for To, From, Subject, and Message parameters.

In the Properties tab, parameters in bold are mandatory.

Note: Clarify currently supports the use of up to 99 parameters.

Using control flow tasks

Control flow tasks (i.e. a task composed of several other tasks) are available that provide easier looping and conditional constructs. For each control flow task, many other tasks can be executed. For example, when using For Each, you may have many different tasks nested under the task, and each one will be executed.

They are:

• For each: For each item in a list, a specified task is executed. This includes multiple tasks.
• Do while: Executes tasks while a specified condition is true. Tasks are executed before the condition is checked. The specified task is executed before the condition is checked. This means that the specified task is always executed at least one time. Then the condition is checked. If the condition is true, then it executes again (then the condition is checked again). And so on.
• While do: While a specified condition is true, a specified task is executed. The condition is initially checked before the given task is executed. This means that the condition is checked first before the task is performed. If the condition isn't immediately true, then the task is never executed.
• If/Then/Else: If a given condition is true, a specified task(s) will be executed in the “then” block. If the given condition is false, the specified task(s) will be executed in the “else” block. In the example below, different Business Processes will execute based on the result of the initial “If” statement.

Note: The Force Step Failure task can be used to force the entire step that it is contained within a control flow task to fail. When using control flow tasks, if a singular task does not complete successfully, the overall control flow task (If/Then/Else, for example) may not appear as failed in the Auditor. By using the Force Step Failure task, an optional error message can be provided when the task is executed (thereby providing better troubleshooting).

An example might be:

• If....
• ….Read Customer File Adapter
• ….….….Then launch BP1
• ….….….…....Else Force Step Failure.

In this simple case, had the Customer File Adapter not been available, the Force Step Failure would have stopped the overall control flow task. Had it not existed, the overall task would not have stopped executing all other tasks that followed.