Processes PDF Print E-mail

The processes tab allows you to create new process lists or create and edit existing proccess lists.

Process lists provide a level of control over your data processing that goes beyond simple rules lists. Like rules lists, process lists are linked to a specific business object. Another similarity to rules lists is the fact that you can define many process lists for a single business object.

Process lists consist of one or more process actions strung together. The available actions are as follows:

Process Actions

Insert Insert the current data into the database. The target table will be determined by the object name.

Update Update a record in the database with the current object data. The target table is determined by the object name, and requires a Primary Key to be defined on the table in order for the update to work.

Delete Deletes a record in the database whose key data is shared by the object. The target table is determined by the object name, and requires a Primary Key to be defined on the table in order for the delete to work.

Validate Call a specified validation list. Processing will halt if the validation fails due to execution errors OR validation errors.

Stop Halt the execution of the current process list. Control returns to any parent process list, or terminates for the current transaction.

Transform Call a specified transformation list. Processing will halt if any errors occur during transformation - these tend to be execution errors.

Sub-Process Call another process list for the same or any other business object. For other business objects, the values for any shared parameters will be transferred to the new business object as it begins its process list.

Using Process Lists

Each process list action can be made to execute conditionally by linking a Boolean Expression business rule to the step. If the conditional returns True, the process action executes - if False is returned, the step is skipped and the next step in the process list is executed (unless the next step is also dependent on a boolean expression).

Process lists provide a lot of freedom to structure behavior as simply or as complicated as you like. To that end, it can sometimes be difficult start planning a process list. Here are some things to keep in mind:

Any process list for any object can be executed as a sub-process action for any other process list. If the objects owning the two lists are different, any parameters shared between the two objects will have their values available to the sub-process list being executed. This is very useful when you have a load object and need to process the customer attributes of the load object, for example - you can just execute the necessary customer process list as a sub-process action from the load object's process list.

Clever use of sub-processes and conditionals can effect very complex behavior. For example, if you have a status attribute, you can structure a boolean expression rule to return True if the value of that status attribute is set to Error. Likewise you may have a separate process list that contains operations that attempt to reconcile or correct an errored transaction. By combining the boolean expression that recognizes the error status and the error-handling sub-process, you can divert errored transactions to the error-correction process.

Process Lists and Requirements

Process lists should have a major role to play in the implementation of your requirments, because they join together many sub-taskings involving whichever business objects you need. For example, the "New Customer" process may involve determining that customer data is not present in the database, verifying that the customer data is valid, assigning some default values, and finally inserting new customer data into the database. That process may look something like this in Lexicon:

  • Verify valid customer data
  • Assign default values
  • Insert new customer data

A business rule called 'is_New_Customer' may be used to determine if the New Customer process needs to be run, or if processing can continue without executing that process (if the customer was already in the database).

 


OpenLexicon.org | Home arrow Documentation arrow OpenLexicon Wizard Categories arrow Processes
Home
News
FAQ
Downloads
Installation
Getting Started
Documentation
Forums
Training
Links
Licences
Customers & Partners
Contact Us
Login
Username

Password

Remember me
Lost Password?
No account yet? Register