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

   The labels will come into play when you sequence the tasks.

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 you 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) 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 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, 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 Cloud 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: The CIC Studio currently supports the use of up to 99 parameters.

Sequencing tasks

Once you've added all the tasks necessary to complete a transformation, you must sequence them in the correct order. Think about the flow of data, and where data must be at the end of one step to be ready for the next one.

For example, to go from database to spreadsheet, you must:

• Select the information from the database (Database Select Adapter)
• Transform the data (Ruleset)
• Convert the data to a spreadsheet (ConvertSpreadsheet task)
• Write the data to the spreadsheet (File Write Adapter)

Therefore, the task sequence would look like:

Label	Task	Pass	Fail
readDB	com.company.example.dba.DbAdapter	next	end
ruleset	com.company.example.rs.rs	next	end
convertSS	ConvertSpreadsheet	next	end
write	com.company.example.write.write	next	end

To put tasks in order, highlight them in the table under Script and click the Move the selected step up or Move the selected step down buttons for each task, until the tasks are listed in the correct sequence.

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.