Develop and Deploy

Theory

Contents
1. Business Process ................................................. 3
1.1 The Agenda for this Module.............................................. 3 1.2 Developing Business Process Models .............................. 4 1.3 Adding Components to a BPM ......................................... 5

2. Data Flow Management......................................... 6

2.1 Data Flow ......................................................................... 6 2.2 Message Map ................................................................... 7 2.3 Message Map Pre Assignments ....................................... 8 2.4 Message Map Post Assignments ..................................... 9 2.5 Process Specific Messages .............................................10

3. Executing Processes .......................................... 12

3.1 Publish Process ...............................................................12 3.2 CWS: Related Content is published as well.....................13 3.3 Execute Process ..............................................................14 3.4 Validating, Publishing and Running .................................15

4. Business Process Types .................................... 16

4.1 Long-lived Process ..........................................................16 4.2 Short-lived Process .........................................................17 4.3 Page Flow Process ..........................................................18

5. User Interfaces .................................................... 19

DEVELOP AND DEPLOY

5.1 Cordys XForms ................................................................19 5.2 User Interface at Runtime ................................................20 5.3 Model View Controller......................................................21 5.4 User Interface at Designtime ...........................................22

6. Business Rules ................................................... 23

6.1 Rules ...............................................................................23 6.2 Rule Definition Elements .................................................24 6.3 Decision Table .................................................................25

Page 2 of 25

DEVELOP AND DEPLOY

1. Business Process
1.1 The Agenda for this Module
Agenda
Making Processes Executable
Data Flow Management Executing Processes

Business Process Types

User Interfaces Business Rules

Making Processes Executable After modeling processes you want to run them. In order to do this you have to develop the activities and implement them. Data Flow Management What happens to the data of the process and how can you influence it? Executing Processes Running the actual process. What happens, how does it work. Business Process Types What sort of processes can you make with Cordys and what is the difference. User Interfaces How do you use user interfaces in Cordys and in processes. Business Rules Applying business rules and decision tables in Cordys.

Page 3 of 25

DEVELOP AND DEPLOY

1.2 Developing Business Process Models

Developing Business Process Models - Embed Services
Qualify & Analyze Run & Monitor Design & Model

Develop & Deploy

Embed services into process models 1 Expose applications

(packages and legacy) in a SOA way

2 Implement process
model activities

The first step in making the activities executable is working out the activities in detail, so we get a view of the reusability of components, involved system functionality and users and roles. This work is normally already started in the Design and Model phase. Now the design is worked out and several groups of developers will start working on the development of the missing web services and user interfaces. Service development is not discussed further in this module, in the developing services and data modeling part this is discussed in detail. The services and user interfaces are embedded in the business processes.

Page 4 of 25

DEVELOP AND DEPLOY

1.3 Adding Components to a BPM

Adding Components to a BPM
List of components that can be added to a BPM
User Interfaces Web Service Operations

Business Process Models

Decision Tables Case Models
Web Service
Operation Sub-Process User Interface Role

Work Lists
Organization Units Roles

Business Calendars
Empty Activities

Designing a process gives an overview of what you want the process to be like. You define the flow and steps the process should take. What you are going to do after that is making the process executable. This has several advantages. The process will execute exactly the way you designed it, because youre executing that design Any changes made to the design will change the execution as well. This saves time working on two different models/programs It is incorporated into the business, allowing you to use your companys resources directly in a BPM

Page 5 of 25

DEVELOP AND DEPLOY

2. Data Flow Management

2.1 Data Flow
Data Flow
All process data is stored in the Message Map

At runtime responses are added to the Message Map

Data can be copied to and from the Message Map by making assignments

BPML and Message Map together form a process instance. You can see the BPML as the program code and the Message Map as the data part where the code is executed on. All runtime process data is stored in the Message Map. As we have seen earlier the Message Map holds a record containing information about the process like start time and current owner. At runtime all responses of the executed web services are added to the Message Map. So if we do not explicitly delete data from the message map, the message map grows while the process progresses. If activities are skipped, the corresponding responses cannot be seen in the message map. Data can be copied to and from the Message Map by making assignments. So we can even add our own data to the message map. In fact that is what you do if you set the values for an input request of a service.

Page 6 of 25

DEVELOP AND DEPLOY

2.2 Message Map

Message Map
Constructs (1)

Assignments (2)
Pre Assignments: before construct is performed Post Assignments: after construct is performed

In the BPM Editor you can switch to the Message Map view by selecting the Message Map tab. At the top of Message Map view all the constructs are listed. Beware that the constructs are not ordered. Under the construct list are two tabs, Pre Assignments and Post Assignments. Pre Assignments are assignments that are executed before the construct itself is started. Post Assignments are assignments that are executed after execution of the construct itself is finished.

Page 7 of 25

DEVELOP AND DEPLOY

2.3 Message Map Pre Assignments

Message Map Pre Assignments
Source
Process Specific Messages
Instance Properties Attachments Activities up stream

Target
Business Identifiers Attachments Process Specific Messages Input structure of selected activity

The pre assignments view consists of three parts: Source Assignments Target Assignments The assignments that you define here are executed before the construct itself is executed. So in case of a web service call you can use these assignments to set the input values of the input message. If the construct is a loop you can add assignments to set initialization values of the loop. An assignment consists of a target (XPath expression), which specifies the XML node that will get a new value, an operation (usually copy, but more complex functions are also possible) and a source, which tells on which data the operation will be evaluated. Target The target shows message structures of Process Identifiers, Process Specific Messages and the message Input structure of the selected activity. This is quite convenient because usually you will set the input messages of services or user interfaces. Source The source shows message structures of Process Specific Messages, Instance Properties and message structures (of input, output and error messages) of preceding upstream activities. Message structures of downstream activities are not presented since these responses will not be available at runtime, because the process will not have executed them yet.

Page 8 of 25

DEVELOP AND DEPLOY

2.4 Message Map Post Assignments

Message Map Post Assignments
Source
Process Identifiers
Instance properties Attachments Process Specific Messages

Target
Business Identifiers Attachments Process Specific Messages

In - and Output Message of

selected activity Activities up stream

The post assignments view in fact is the same as the pre assignments view except for the fact that post assignments are executed after the construct is executed. Since the request is already sent the target pane does not show the input message from the activity anymore and the response of the activity is added to the source pane.

Page 9 of 25

DEVELOP AND DEPLOY

2.5 Process Specific Messages

Process Specific Messages Usage Example

In order to persist data you can also add new nodes to the message map: <MyMessage> <Products> <ProductID>42</ProductID> <ProductName>Singaporean Hokkien Fried Mee</ProductName> </Products> </MyMessage> In order to predefine the structure of these messages you can create Process Specific Messages. When you open the Message Map view you will be able to see and add Process Specific Messages. These messages and element structures are visible in the entire process; it does not matter where you create them. The difference between an element and a message is the fact that you can drag and drop messages on start, end and other constructs (where relevant) and elements can only be used to assign data. Start Messages While starting a process, a process input message (XML structure) can be provided. This way you can provide input parameters. By placing the message on the start event construct it defines it as a required message and the process will not be started without the existence and contents of this message. End Messages When a process ends, a process output message can be defined. By placing the message on the end event construct of the process, the message will be delivered to the parent process (if called synchronously) or calling web service (if shortlived). Usage Example
Page 10 of 25

DEVELOP AND DEPLOY

In order to define the (XML-)structure of the output message, the message structure is specified by adding a process specific message and associating it to the end construct.

Page 11 of 25

DEVELOP AND DEPLOY

3. Executing Processes
3.1 Publish Process
Publish Process

Design Time

Collaborative
Workspace

BPMN Definitions Publish

Run Time

Business Process Management

BPML Definitions

At Design time models are stored in Business Process Model Notation (BPMN) format. When published, models are stored in Business Process Model Language (BPML) format. In order to edit models the CWS processor hasto be running. In order to publish models the business process management processor must be available.

Page 12 of 25

DEVELOP AND DEPLOY

3.2 CWS: Related Content is published as well

CWS: Related Content is published as well
Development Environment

CWS

BPMN Definitions Publish

BPML Definitions
Runtime Environment

BPM Management

Usually Development and Target Organization are the same When processes are implemented all related content is published to your organization at once. So all roles, web services and user interfaces do not have to be published separately.

Page 13 of 25

DEVELOP AND DEPLOY

3.3 Execute Process

Execute Process

Process Models
Run Time

Start Process Business Process

Management

BPML

Message Map

Process Instances

Once a model is published to the run time model repository, it can be executed. If a model is executed, a copy of the model is made and a message map added. The Message Map holds a record containing information about the process like start time, current owner etc. BPML and Message Map together form a process instance.

Page 14 of 25

DEVELOP AND DEPLOY

3.4 Validating, Publishing and Running

Validating, Publishing and Running
Validation
You can validate your process to check for errors, warning and information

Running a BPM
A BPM need to be Publish in order to run, test and debug it

From within CWS you can

Run a process

Debug a process
Run interactively View related process instances

Validation You can validate your process to check for errors, warnings and information. Running a BPM A BPM needs to be published in order to be able to run, test and debug it. From within CWS you can Run a process Debug a process Run interactively View related process instances

Page 15 of 25

DEVELOP AND DEPLOY

4. Business Process Types

4.1 Long-lived Process
Long-lived Process
Transport Company
Input Send Quote Request Output Quote pricing

Check resources

based on ratings

Ok?

Notify Customer

Personnel and equipment

planning system

Tariff system

Manager Approval

Notification System

Someone in a factory needs to transport some goods. He calls a transport company to get a quotation. In order to make a quotation the people at the transport company need to know some data about the transport, check if there are resources available, put some pricing, approve the final quotation and send the quotation back to the customer. Long-lived Process: Only process ID is returned Process runs asynchronously => No feedback on errors

Page 16 of 25

DEVELOP AND DEPLOY

4.2 Short-lived Process

Short-lived Process
CFO Output financial report Send Financial Information Request Input

Process Financial Information Request

BPM
Request and receive Financial info Request and receive Financial info Request and receive Financial info Request and receive Financial info

Agent

Financial Systems and Business Units

Short-lived Process: Output message returns synchronously A typical example is the incorporation of a new business unit. Suppose there is a company that consists of several business units. Each Business Unit periodically reports their financial report. A real agile company would be able to integrate the results of the newly added business unit in the next report. Suppose each Business Unit has its own systems, services and xml formats. What has to be changed if a Business Unit is added? By using web services integration on a technical protocol level is established. Systems are now able communicate. Integration on the data level is done in the Business Processes. This will be the case for all processes and User Interfaces that use want compiled and aggregated data over business units. What happens if Business Units have their own systems, services, xml formats? What has to be changed if a Business Unit is added? How can we improve agility of the solution?

Agility can be improved with the following change: Transform reports to generic report (Business Objects). Use only generic reports in compilation process. Collect all data in separate service.

This way integration is done at a service level.

Page 17 of 25

DEVELOP AND DEPLOY

4.3 Page Flow Process

Page Flow Process
Automated task handling
Wizard-like way of completing tasks Grouped activities

When your process contains several tasks that are fulfilled by the same user, you can set the process in Page Flow mode. On completion of a task, the next and succeeding task (for the same user) is automatically opened within the same window that was already open as a consequence of the preceding task. Page Flow allows you to build a logical sequence of operations or decisions in a process which are presented as one flow of user interface screens. This enables you to include the logic server side for the sequence in (backend) processes, instead of building (complex) logic in the closely related forms. To the user it feels like working in a wizard. The screens follow each other up, instead of having to open and complete or close every task seperately. More information about Page Flow in the module Workflow.

Page 18 of 25

DEVELOP AND DEPLOY

5. User Interfaces
5.1 Cordys XForms
Cordys XForms
Based on W3 recommendation
CAF page Model based (JavaScript)

JavaScript is used
Add Logic Add Components dynamically

WysiWyg editor (RAD)

Event Driven

Page 19 of 25

DEVELOP AND DEPLOY

5.2 User Interface at Runtime

User Interface at Runtime
1. XForm is converted to HTML
2. Service operations are executed

At runtime presentation of the user interface takes place in two phases: First the XForm is converted to HTML by the XForms Service Container. Then service operations are executed to fetch the data. Cordys User Interfaces (XForms) have the .caf extension. In the picture above you see a more detailed description: 1. XForms Client Contacts the web server to get the required .caf (URL) The web server hands over the request to the XGateway The XGateway hands over the request to the XForms Engine (service container) 2. XForms Engine Generates HTML Reads the XForm definition (.caf file) Translates the labels to the specified language. Prepares the Model by reading the WSDLs of the web service operations. Sets validations on controls by reading the XSD definitions Generated HTML is cached, for faster responses (depending on content expiry setting). XForms Client Send SOAP requests for automated models to fetch data.

Page 20 of 25

DEVELOP AND DEPLOY

5.3 Model View Controller

Model View Controller

Model: manages the data synchronization

View: comprises the user interface layout and presentation details Controller: manages and synchronizes model and view

Model View controller is a common architecture pattern. An important result of this design is the fact that if one has multiple views on the same data (model) and data is changed within one control, changes are propagated to the other views automatically. Model The model manages the data synchronization View The view comprises the user interface layout and presentation details Controller The controller manages and synchronizes model and view

Page 21 of 25

DEVELOP AND DEPLOY

5.4 User Interface at Designtime

User Interface at Designtime
WYSIWYG editor (RAD)
Drag and drop:
WS Operation

Model

Schema Fragment

View
Control

Customization JavaScript is used

Add logic
Add components dynamically

Event Based

Cordys provides WysiWyg editor to generate and develop user interfaces. In a WysiWyg editor (RAD) during design time you see what the result of your action is. (If you for example develop in Notepad you cant). Drag and drop: WS Operation Schema Fragment By dragging and dropping of a WS-AppServer Operation (or Schema Fragment) model, view and controls are generated. If it is an operation containing also navigation and update methods, navigation and update controls are also put on the XForm and the model is automatically set to "automatic". Automatic means that data is retrieved as soon as the form has been initialized. Customization by using JavaScript can add: Logic Components dynamically Event Based Events are used to provide easy hooks to pop customizations in. Since XForms are generated on basis of WSDL, it becomes key. The higher the Quality of the WSDL, the better the generated UI will be.

Page 22 of 25

DEVELOP AND DEPLOY

6. Business Rules
6.1 Rules
Business Rules
Insert Business Object
GetEmployeesObject

New hire added to the system

Rule: All

Rule: Sales person

CRM system

Activity

Activity

Sub-process

Sub-process

HRM Process

CRM Process

Rules Support an Event Driven Architecture: More flexibility Rules can be combined and cascaded. Conditional execution of processes, conditions are programmed with rules not within processes Separation of concerns Every domain can maintain and add his own processes, decisions on implementation Changes take place with less people and systems involved => more agility Better maintainable Changes have impact on less code. New Processes can be added without process changes Decision Logic is separated from BPMs Rules are not programmed out in BPMs or services so they can be maintained separately. If rules change no code has to be rebuilt. Business Logic is separated from Application Logic Applications and systems often need application logic. By separating business logic from application logic the system becomes better maintainable. The idea is that business rules come closer to the business.

Page 23 of 25

DEVELOP AND DEPLOY

6.2 Rule Definition Elements

Rule Definition Elements
Condition
Complex, technical conditions using functional libraries

Actions
Trigger Business Process Assign Trigger Web Services .

Options
Override Mutex ....

A rule definition consists of two elements: the Condition and the Action. Condition A conditional statement: if - then (optionally else) (nesting is allowed). The condition uses a value(s) from object context. Action There are several types of actions: Insert / Update / Delete / Abort (constraint rules) Sending/Starting a SOAP Message / Inbox / Web Service / Business Process (Business Rules) Assignment (inc. java functions) (constraint rules) In order to hide complexity you can create rule templates, which can be used in decision tables. This way less technical people can (re)use them in the decision tables. Templates can be made for actions as well as conditions.

Page 24 of 25

DEVELOP AND DEPLOY

6.3 Decision Table

Decision Table
Business View on Business Rules
Group of Conditions defined on a Business Entity

In a decision case a group of rules is defined on a business entity. This business entity can be a Business Object, which is defined in WS-AppServer, but it can also be a schema fragment like you made in the data modeling module. Actions can vary from setting values in the business object to sending notifications and starting business processes. In fact a decision table provides a logically organized way of representing rules. An interesting application of decision tables is using a decision table in a business process. By putting the logic in the decision table one can modify process behavior without modifying a process. Getting logic out of your processes in fact enables change. In the exercises an example is given.

Page 25 of 25