WPS: Business Process Elements: Activities

Activities are the individual business tasks that implement the larger business goal represented by the process.
An activity can be divided as basic, structured, or associated with processing.

Basic Activities : The basic activity implements a singular aspect or task with in a business process. Basic activities are do not embed other activities within them.

List Of Basic Activities :

 

Invoke activity :  

 

Use this activity to call an operation on a specific partner. Operations can be either one-way (asynchronous) or request/response (synchronous). 

Assign activity : 







Use this activity for basic data manipulation through the use of expressions, to map service endpoint references to or from partner links, or to copy some form of information from one part of your process to another.

Receive activity :  

 

The receive activity provides Web services to the process partners by waiting for external input from the partners, and channeling it into the process. It can have one or more associated reply activities if it is used in request-response operations.

Receive activities can either start a process, or receive a message in an already running process. Configure the receive activity to be one of these types using the Create a new process instance if one does not already exist setting on the Details tab of the Properties view. When selected the receive activity starts a new process.

Receive choice activity :  

 

It is a combination of receive and choice. When a specific message is received, a matching path of activities are executed.

• Receive choice can be used to start a process instance. 
• This activity waits for 1 to N possible messages. 
• A correlation set specified for each case. 
• Each case can have different permissions. 
• If we select an interface with multiple operations when a process is created, it begins with a receive choice instead of receive.
• A timeout case executes control path if a message is not received with in a certain time evaluated by an expression. Timeout is an IBM extension to BPEL 

 Selects one branch of activities to execute based on receive case. Receive cases are interface operations  

Reply activity :  

 

Use this activity in a synchronous (request/response) operation to return the output or fault to the partner that initiated the operation. This activity specifies the same partner implementation as the corresponding receive activity. A reply is always sent to the same partner from which a message was previously received.

Wait activity :  

 

Use this to stop the process for a specified period of time. You configure this activity either by telling it how long it should hold up the process, or by specifying when it has waited long enough. 

Empty action activity :  

 

Use this activity as an undefined object to act as a placeholder within your process. You might do this if you were designing a process that you expected somebody else to implement, or if you were trying to synchronize the activities within a parallel activity.  

Snippet activity :  

 

Use this activity to compose visual expressions and Java™ code and thereby insert custom behavior into your process. 

Business Object Map activity :  

 Use this activity to compose a mapping between process variables that refer to business objects. Variables that do not point to business objects cannot be transformed using a business object map.

Note: You must create a new business object map each time you want to use one. Reuse of business object maps is not supported. 

WPS: Business Process (WS-BPEL) & It's Elements

Business Process :
                             Business processes are part of the service component layer. WS-BPEL(Web Service Business Process Execution Language) is the language for composing business processes. 

•  BPEL facilitates the building of composite integration applications by allowing reuse of existing it assets exposed as services.
• BPEL supports the required technology patterns for business: error handling, compensation, asynchronous processing.
• BPEL Process can invoked as a SCA component
• BPEL can invoke other SCA components
• SDO is slandered data format for messages
• BPEL implements interface partners and reference  partners.

Business processes are executed in process server as either  micro flows or long running process.

• micro flow is used for executing short business processes or small unit of work with in a large business process.
• Long running process involve servies that do not respond immediately run over a period of time and can involve people(human task).

Elements in Business Process :

1. Partners                             : Define parties interacting with the process
2. Variables                           : Specify information used while running the business process
3. Correlation Sets               : Match messages to the correct process instances
4. Fault Handlers                  : Recover from partial and unsuccessful work done in the current                                                   scope of the business process.
5. Compensation Handlers : Contains actions that perform reverse operations for a particular                                                    scope or activity
6. Event Handlers                 : Perform work based on an event or an asynchronous message
7. Activities                            : These are used to define the process logic.

WPS: Business Objects, Service Data Objects & Framework

Business Object & Framework : 

                     Business Objects are SOA core components and it provides an abstraction layer for data objects. Business Object Framework is intended to provide data abstraction for service component. Component interfaces use Business Objects as inputs and outputs.

 







Business Object FrameWork is composed by following components:

1. Business Object : It refers to the fundamentl data structure for representing business data and not to the overal stucture.

• Business objects are modeled using xml schemas(XSD).
• At run time BO's are reprasented in memory as an SDO instance usind commonj.sdo..DataObject
• Business Objects are collection of elements with names and data types.

          We have two types of business objects:
                 1. Simple business object composed of sclars
                 2. Hierarchical business objects with elements that contain other business objects.

• Business object compare utility shows the structure of business objects in two different modules or libraries and allows you to visually determine additions, removeals, and changes. Also the "Copy Report to Clipboard" option allows you to paste changes into a document or other report.

2. Business Graph : It is used to wrap a top level business object and provide additional information that is used to enhance the data. The data graph includes change summary, event summary, verb information. It is an optional container around a business object.
3. Business object type meta data : It is available to annotate business objects with application specific information.
4. Business object service : A set of services that fecilitate working with business objects.

Service Data Object & Framework :
                  SDO Provides a framework for data manipulation and SDO framework supports manipulate data without connection to source.

Key components of the SDO framework are:
1. Data Object: Fundamental data Structure for representing Business data.
2. Data Graph: A container for hierarchical set of data objects. It incledes the change summary that records modifications to the data.

3. Data Object MetaData : Metadata is the object's scheme definition. It contains information about the data in the data object (property types, relationships constraints.)

WPS: Import and Export Bindings in Websphere Process Server

WPS: Import and Export Bindings in Websphere Process Server

EXPORT  : Exports process incoming requests from outside SCA modules
IMPORT  : Imports process outgoing requests to components outside SCA modules
BINDING : Binding determines how imports and exports interact with componets outside a module

• An Import binding describes the specific way an external service is bound to an import component.
• An export binding describes how that export is published or made available to clients out side the module.
• Binding includes protocal, message format and invocation style.

Most Imports and Exports use the following components:

DataBindings      : A mapping between native data format to Business Object. The DataBinding java class takes a streem of data and builds a business object or takes a business object and builds a streem of Data.
Function Selector : It assign incoming messages or requests to the correct service operation.
DataHandlers      : These are used by databindings or function selectors to transform data from one type to another.

WPS : Libraries in Websphere Integration Developer

Libraries in Websphere Integration Developer

• Libraries are projects used to store shared resources by several modules
• Libraries are accessed by adding them to module dependencies.
• Libraries are not runnable applications. It has no assemble diagram.
• Library projects do not include other types of business integration resources such as SCA components.

Library Components:

1. Dependencies -- Used to include other libraries,projects, predefined resources.
2. Integration Logic -- Contains artifacts theat perform business services(mediation subflows,Business calender)
3. Data -- Business Objects.
4. Intefaces -- Service interfaces and it's operations.
5. Transformations - Contains data maps and relationships

Library Deployment :

A library can deploy in server in two ways.

1. Deployinh libraries in modules (default setting)
    -- A copy of the library JAR file is included  in each module that uses it.
    -- After deployment, if changes in library resources than modules using that library must be               updated and redeployed.

2. Deploying libraries globally( memory save by this option)
    -- Library is deployed as a delpoyable JAR file.
    -- The resources references for a module are configured to use the global library using the               module deployment editor
    -- this option saves memory but you mush deploy each library independently.

WPS: Mediation Routing Primitive : Type Filter

Type Filter mediation primitive : Conditionally route a message based on the message type, by comparing the message against a list of user defined xpaths and types.

The Type Filter mediation primitive uses XPath expressions to allow you to direct messages down different paths of a flow, based on their type.

The Type Filter mediation primitive has one input terminal (in), one fail terminal (fail), and multiple output terminals, (one of which is the default terminal). The in terminal is wired to accept a message and the other terminals are wired to propagate a message.

Each of the output terminals, apart from the default terminal, is associated with an XPath expression and a type. The elements of the message identified by the XPath expressions are compared, in turn, with the associated type. The primitive always uses the first matching output terminal. The default terminal is used if the message meets none of the conditions.

If an exception occurs during the filtering, the fail terminal propagates the original message, together with any exception information.

Usage:

You can use the Type Filter mediation primitive to check that the inbound message has elements of a specific type. If the criterion is not met you can raise a fault using the Fail mediation primitive, or send an error response.

Type Filter Properties:

Filters :
    A list of XPaths, types, and associated terminal names, that define the filtering performed by the mediation primitive.
    Note: Order is significant in the list of expressions. Expressions are evaluated in the order they appear in the table.
XPath element :
        An XPath 1.0 expression against which the message is tested. The expression is evaluated starting from the XPath expression /, which refers to the complete SMO.
Type :
        The qualified type to be matched.
Terminal name :
        The name of an output terminal. There is one terminal name for each pattern XPath type pair. The terminal name must be a valid connection endpoint, and it must not be fail or default. The default value is empty, which is invalid.

NOTE:
The Type Filter primitive matches on either the exact type of an element or its derived types. For example, if you try to match against xsd:int but the actual element is of type xsd:short, it will still match.

WPS: Mediation Routing Primitive : Message Filter

Message Filter : Routes messages down different paths, based on the message content.

• The Message Filter mediation primitive uses XPath expressions to allow you to direct messages, which meet certain criteria, down different paths of a flow. 
• The Message Filter mediation primitive has one input terminal (in), one fail terminal (fail), and multiple output terminals, (one of which is the default terminal). The in terminal is wired to accept a message and the other terminals are wired to propagate a message. 
• Each of the output terminals, apart from the default terminal, is associated with a simple, conditional expression. The contents of the input messageare compared with each expression in turn and, if the condition is met, the messageis propagated to the associated output terminal. The primitive can be configured either to use the first matching output terminal, or all matching output terminals. The default terminal is used if the messagemeets none of the conditions. 
• If an exception occurs during the filtering, the fail terminal propagates the original message, together with any exception information.

Usage of Message Filter:

You can use the Message Filter mediation primitive to check that the inbound message meets some criterion. For example, that a required field is set. If the criterion is not met you can raise a fault using the Fail mediation primitive, or send an error response.

The Message Filter mediation primitive lets different messages take different paths. For example, a message might need forwarding to different service providers based on the request details.

You can use the Message Filter mediation primitive to bypass unnecessary steps. You can test if certain data is in a message, and only perform a Database Lookup operation if the data is missing.

When used in combination with a Database Lookup primitive, the Message Filter can direct messages based on the contents of an independently administered lookup table. For example, you could route a message based on customer status even if the inbound message contained only the customer identifier.

By configuring the primitive to propagate messages to all matching terminals, you can trigger multiple events each requiring different conditions. For example, you could log requests relating to a particular account identifier and send requests relating to a particular product to be audited.

Properties of Message Filter:

Enabled :
    Defines whether the message is mediated by the Message Filter mediation primitive. By default the mediate action of the Message Filter mediation primitive is enabled. You can suspend the mediate action by clearing the checkbox. If you suspend the mediation, the message goes to the default terminal.

Filters :
    A list of expressions, and associated terminal names, that define the filtering performed by the mediation primitive.
    Note: Order is significant in the list of expressions. Expressions are evaluated in the order they appear in the table.

Pattern :
        An XPath 1.0 expression against which the message is tested. The expression is evaluated starting from the XPath expression /, which refers to the complete SMO.

Terminal name :
        The name of an output terminal. There is one terminal name for each pattern XPath expression. The terminal name must be a valid connection endpoint, and it must not be fail or default. The default value is empty, which is invalid.

Distribution mode :
    Determines the behavior of the mediation primitive when an inbound message matches multiple expressions. If the Distribution mode is set to First, the message is propagated to the first matching output terminal. If the Distribution mode is set to All, the message is propagated to all matching output terminals. If there is no matching output terminal, the default terminal is invoked.

WPS: Mediation primitives

WPS: Mediation primitives :

Mediation flow components operate on message flows between service components. The capabilities of a mediation component are implemented by mediation primitives, which implement standard service implementation types.

A mediation flow component has one or more flows. For example, one for request and one for reply.

WebSphere® Process Server supports a supplied set of mediation primitives, which implement standard mediation capabilities for mediation modules or modules deployed into WebSphere Process Server. If you need special mediation capabilities, you can develop your own custom mediation primitives.

A mediation primitive defines an "in" operation that processes or handles messages that are represented by service message objects (SMOs). A mediation primitive can also define "out" operations that send messages to another component or module.

You can use WebSphere Integration Developer to configure mediation primitives and set their properties. Some of these properties can be made visible to the runtime administrator by promoting them. Any mediation primitive property that can be promoted can also be a dynamic property. A dynamic property can be overridden, at run time, using a policy file.

WebSphere Integration Developer also allows you to graphically model and assemble mediation flow components from mediation primitives, and assemble mediation modules or modules from mediation flow components. The administrative console refers to mediation modules and modules as SCA modules.

WebSphere Integration Developer also allows the definition of subflows in modules or their dependent libraries. A subflow can contain any mediation primitive except for the Policy Resolution mediation primitive. A subflow is invoked from a request or response flow, or from another subflow using the Subflow mediation primitive. Properties promoted from mediation primitives in a subflow are exposed as properties on the Subflow mediation primitives. These may then be promoted again until they reach the module level at which point they can then be modified by the runtime administrator.