Join and split activities

Chapter 19 Working with Sybase Unwired Orchestrator

Join and split activities

Join mapping

Unwired Orchestrator distinguishes between the following types of joins:

AndJoin
OrJoin
RuleJoin

For more information on the different types of joins, see section Introducing Sybase Unwired Orchestrator Concepts.

Unwired Orchestrator concept	PowerDesigner concept
AndJoin	Synchronization with <<AndJoin>> stereotype
OrJoin	Synchronization with <<OrJoin>> stereotype
RuleJoin	Synchronization with <<RuleJoin>> stereotype

Insert OrJoin and Insert Andjoin commands
From a process or an end object with many input flows, you can use the Insert OrJoin or the Insert AndJoin command from their contextual menu to easily insert joins.

Split mapping

Unwired Orchestrator distinguishes between the following types of splits:

Single Rule
Multi-Rule
Rule Split

For more information on the different types of splits, see section Introducing Sybase Unwired Orchestrator Concepts.

Unwired Orchestrator concept	PowerDesigner concept
Single Rule	Decision with <<SingleRule>> stereotype
Multi-Rule	Decision with <<Multi-Rule>> stereotype
Rule Split	Synchronization with <<RuleSet>> stereotype
AndSplit	Synchronization object with a <<Split>> stereotype

Insert Split, Insert Multi-Rule, Insert Rule Set and Insert Single rule commands
From a process or a start object with many output flows, you can use the Insert Split, the Insert Multi-Rule or the Insert Rule Set command from their contextual menu to easily insert splits.
When the process or the start object has only two output flows, you can use the Insert Split, the Insert Multi-Rule or the Insert Single Rule command from their contextual menu to easily insert splits.

SingleRule

SingleRule element defines a simple "If-Then-Else" expression. Therefore the corresponding decision object must have only two outgoing flows and one of the two flows must designate a "False" path that is expressed by typing "else" or "no" in the Alias box of the Condition page of the flow property sheet.

MultiRule

MultipleRule element defines a cascading "If-Then- Else-[ If-Then-Else [If...Else]]" expressions. You can define each "Then" path using an output flow together with a RuleOrder extended attribute that defines the order of the nested "If-Then" expression. You can set this Rule Order but it will be computed by default within the Initialize event handler of the flow outgoing from a Multi-Rule decision (even if the rule orders are not specified, the first generation will set them). You express the last "Else" path by typing "False" or "No" in the Alias box of the Condition page of the flow property sheet.

RuleSet

RuleSet (RuleSplit) element defines several rules that can be satisfied simultaneously and each rule satisfied conducts to a new path of the business processing flow. So this element allows you to define a split based on rules.

Orchestrator RuleSplit contains a set of:

XSD schemas
Target nodes
Named rules

You design a set of XSD schemas using variables. Each variable must have an XSD data type (a message format that references an XSD file and that has an XSD stereotype).

Unwired Orchestrator concept	PowerDesigner concept
XSD schema	Variable with complex type

You design target nodes using outgoing flows from the decision object.

Unwired Orchestrator concept	PowerDesigner concept
Target nodes	Outgoing flows from the decision object

You design a set of named rules using business rules on outgoing flows from the decision object.

Unwired Orchestrator concept	PowerDesigner concept
Named rules	Business rules on outgoing flows from the decision object

You define Rules by creating business rules with <<Decision Rule>> stereotype. Then you associate one or several business rules to each flow outgoing from the RuleSet Activity. Since several rules can be linked to the same target node (or one rule can be linked to several target nodes), you can associate the same business rule to different flows using the Rules page of the flow property sheet.

During generation, all the business rules used by the output flows of the RuleSplit synchronization are browsed and PowerDesigner generates:

Only one Orchestrator rule for each business rule (even if it is used by several flows). The code of the business rule is used to define the name of the rule and the Server Expression attribute is used to define the expression of the rule
One target node for each output flow. The Alias attribute in the Condition page of the flow property sheet is used to define the name of the target node (if the Alias box of the Condition page is empty, the code of the flow is used)

When the Rules collection is empty, it means that there are as many rules as target nodes. So for each flow, there is one rule and one target node.