WPS: Service Message Objects : SMO

The primary function of a mediation flow is to operate on a message between endpoints, where a service requestor and a service provider are those endpoints. However, this presents a problem. The first point is that a message can take on many different forms because the protocol used to send a message, whether JMS or Web services, can vary. Also, each message is different depending upon the interface and operation associated with the message and whether this is the request side or response side of the interaction between the requestor and provider.

The next point to understand is that within the mediation flow, mediation primitives are used to operate on the message. Mediation primitives examine and update the message contents and therefore must understand what is contained in the message. The solution is to provide mediation primitives with some kind of a common representation of a message, and that is what a Service Message Object does. SMOs provide a common representation of a message that accounts for differing protocols and differing interfaces, operations, and parameters that the message represents. SMOs are built using Service Data Object (SDO) technology. SDO uses a schema that describes the basic structure of an SMO which is composed of three major sections.

The body of the message represents the specific interface, operation, and parameters relevant to this message. The headers section of the message represents information about the protocol over which the message was sent. The context section represents data that is important to the internal logic of the flow itself. Each of these major sections of the SMO is examined in more detail in subsequent slides. The data within an SMO is accessed using SDO, specifically the SDO DataObject, which enables access using XPath, the generic DataObject APIs, and some SMO-specific APIs that are aware of the SMO schema.

The service requestor and service provider interact with the bus through the bindings for the exports and imports of the mediation service module. The data representing the message depends on the binding used for exports and imports. If the primitives in the mediation flow component had to support the data representation for all the various bindings, it would be difficult to implement primitives. For this reason, the first thing the runtime does is that it converts the binding-specific data into common data structure, called Service Message Objects (SMO).

The SMO interface extends the DataObject interface, which is defined by the Service Data Object (SDO), similar to other business objects used in WebSphere Process Server. SMO includes the message headers, message data (payload) and context information and provides an interface to access and modify the SMO data, including headers, payload, and context information. In addition, the SDO data can be accessed using the XPath reference mechanism. The mediation module input contains binding-specific data representation. The mediation module output import binding dictates the data representation that must be sent to the output message. As a result, there is a lack of consistency in data representation and if the mediation flow primitives had to handle all the different data representation, it would become a huge challenge. To solve this problem, the data from binding-specific interaction is converted to a common data structure called the Service Message Object (SMO).

If the mediation primitives in a message flow require a temporary area to save data for other primitives down the message flow or need data set in the request flow to be available during the response flow, context information is used as a scratch pad.
There are two types of context information:

Transient context, as the name suggests, is temporary and available only on the specific request flow or the response flow but is not carried from the request to the response flow, and is therefore stored in memory.

Correlation context is the second type of context data that is available for the duration of the complete request/response flow. Data set in the request flow is available for all the primitives in the response flow. Any primitive can modify the context information and downstream primitives in the message flow will have access to that information.

The context data are represented as data objects and the structure is inserted in the SMO structure at the start of the mediation flow.

WPS: Mediation flow and it's Primitives

Mediation services can inspect, modify, augment and transform a message as it flows from requestor to provider.

The heart of a mediation module is the mediation flow component, which provides the mediation logic applied to a message as it flows from a service consumer to a provider. The mediation flow component is a type of SCA component that is typically used, but not limited to a mediation module. A mediation flow component contains a source interface and target references similar to other SCA components. The source interface is described using WSDL interface and must match the WSDL definition of the export to which it is wired. The target references are described using WSDL and must match the WSDL definitions of the imports or Java components to which they are wired. The mediation flow component handles most of the ESB functions including:

• Message filtering which is the capability to filter messages based on the content of the incoming message.
• Dynamic routing and selection of service provider, which is the capability to route incoming messages to the appropriate target at runtime based on predefined policies and rules.
• Message transformation, which is the capability to transform messages between source and target interfaces. This transformation can be defined using XSL stylesheets or business object maps.
• Message manipulation/enrichment, which is the capability to manipulate or enrich incoming message fields before they are sent to the target. This capability also allows you to do database lookups as needed.
• If the previous functionalities do not fit your requirements, you have the capability of defining a custom mediation behavior in JAVA.

Mediation primitives

What are the various mediation primitives available in WESB?
Mediation primitives are the core building blocks used to process the request and response messages in a mediation flow.

• Built-in primitives, which perform some predefined function that is configurable through the use of properties.
• Custom mediation primitives, which allow you to implement the function in Java.
• Mediation primitives have input and output terminals, through which the message flows. Almost all primitives have only one input terminal, but multiple input terminals are possible for custom mediation primitives.
• Primitives can have zero, one, or more output terminals.
• There is also a special terminal called the fail terminal through which the message is propagated when the processing of a primitive results in an exception.

The different types of mediation primitives that are available in a mediation flow :


Service invocation:

Service Invoke: Invoke external service, message modified with result

Routing primitives:

Message Filter: Selectively forward messages based on element values
Type Filter : Selectively forward messages based on element types

Endpoint Lookup : Find potential endpoint from a registry query
Fan Out : Starts iterative or split flow for aggregation
Fan In : Check completion of a split or aggregated flow
Policy Resolution: Set policy constrains from a registry query
Flow Order : Executes or fires the output terminal in a defined order
SLA Check : Verifies if the message complies with the SLA
Gateway Endpoint Lookup: Finds potential endpoint in special cases from a registry
UDDI Endpoint Lookup: Finds potential endpoints from a UDDI registry query

Transformation primitives:

XSL Transformation : Update and modify messages using XSLT
Business Object Map : Update and modify messages using business object maps
Message element setter : Set, update, copy, and delete message elements
Set message type : Set elements to a more specific type
Database Lookup : Set elements from contents within a database
Data Handler : Update and modify messages using a data handler
Custom Mediation : Read, update, and modify messages using Java code
SOAP header setter : Read, update, copy, and delete SOAP header elements
HTTP header setter : Read, update, copy, and delete HTTP header elements
JMS header setter : Read, update, copy, and delete JMS header elements
MQ header setter : Read, update, copy, and delete MQ header elements

Tracing primitives:

Message logger : Write a log message to a database or a custom destination
Event emitter : Raise a common base event to CEI
Trace : Send a trace message to a file or system out for debugging

Error handling primitives:

Stop : Stop a single path in flow without an exception
Fail : Stop the entire flow and raise an exception
Message Validator : Validate a message against a schema and assertions

Mediation subflow primitive:

Subflow : Represents a user-defined subflow

WPS: Websphere Integration Developer Component : Selector

Selector Introduction :
A selector is a dispatch pattern you use to dynamically determine which implementation of a component to invoke at runtime. Like a rule group, a selector has date range entries, selection criteria, and a default destination. You select a destination in a selector the same as your would for a rule group. That is, when a selector is invoked, it selects a destination using the selection criteria and date range entries. A destination could be any service-oriented component.

You can call a selector from any of your service-oriented components. The selector job is to use dynamic information to determine which component should be called to do the work. The set of destination components is also configurable, allowing you to provide additional destinations at runtime. For example, imagine that at the start of the new year you want to switch your application over to a new subsystem for inventory management. A selector allows you to provide two destinations and indicate that the new one takes effect on January 1. 


Difference between "Rule Group" and "Selector" :

One major difference between a selector and a rule group is that the destination of a selector can be any service component, while a destination in a rule group can be only a rule set or decision table. In other words, a selector can dynamically re-route a service call to any other component at runtime.



Important point need to concentrate on selectors:

The interface operations of the selector must match all of the interface operations of the destinations. In other words, you may not select a destination that has an interface with a different operation name, input, or output than the selector itself. If you try to use a selector where the operation name does not match, then you get a ServiceRuntimeException saying the operation name cannot be resolved. If the input or output does not match (for example, if the destination interface has a different input name or a different input type), then you get a SelectorException saying the component does not support the operation.


For matching the operation of interface we need to use interface maps. To convert from one interface to another by using the interface map as a destination in the selector. Then the selector can invoke the interface map that, in turn, calls the actual service implementation.


Altering existing destinations or adding new destinations:

We can update or modify the destinations of a selector and their corresponding date ranges at runtime without redeploying the original application. Using the WebSphere Process Server administrative console, you can replace an existing service implementation with another one, add a new destination with complete date range information, or remove a destination.

We have three selection criteria to use:

• Current date
• XPath expression
• Visual snippet or Java expression.

If you choose the current date criteria, then the selector selects a destination when the current date falls within the start date and end date of the destination. If you choose the XPath criteria, then you need to further specify the XPath expression that returns a date from the input variable. If you choose the Java expression criteria, you need to provide the Java code, which can be a visual snippet, that returns a Date object from the input variable.

Altering and adding destinations in Admin console:
Suppose that your business environment has evolved and you need to change the default destination for Selector. You use the administrative console to alter the default destination of the selector. After you commit the change, you test the Process again.
Modify the existing destination

1. You can change selector criteria using the administrative console. In the Servers view, right-click the server and select Run administrative console.
2. In the Log in page, you have to specify a user name to change anything in the selector, even if you have not enabled security. Type any user name and log in.
3. In the navigation section, expand Servers, click Application servers, and then click server1.
4. In the server1 editor page, scroll down to the Business Integration section and click the Selectors link
5. In the Selectors page, you see all the selectors currently in the system. Click  your <Selector>, which is the one that you created earlier: 
6. Click the <your selector> link. You see the date entry for this selector. 
7. To modify the selector, click<need to change selector> the  link. 
8. To commit the change, select the check box next to the default selector, and then click Commit. You see a message at the top of the administrative console reminding you to select commit to make the changes take effect. 

We are also able to add new destination. After adding new destination we need to deploy that application (contained the target service component) into the server.

WPS: Decription about Business Rules : Rule Set and Decision Table

Business rules

A business rule is a condition that must be satisfied when a business activity is being performed. A rule can enforce a business policy, make a decision, or infer new data from existing data.

An example of a business rule

A vendor establishes the preferred status of each customer and creates a business rule to determine how much each customer is charged for the same object. Here are some basic terms that define the building blocks of each and every business rule:

Conditions

A condition describes a situation or state that must be in place in order for a specific action to occur. In this example, the condition is the customer's status.

Actions

An action is the event that results from the evaluation of the condition. Each action is uniquely bound to the condition that precedes it. In this example, the action is the quotation of the price; it is different for each of the conditions that is encountered.

When to use business rules

A business rule is anything that captures and implements business policies and practices. A rule can enforce business policy, make a decision, or infer new data from existing data.

The WebSphere® Integration Developer tools have been designed so that users can easily compose integrative business solutions without programming skills. To this end, you can easily create and develop business rules in an intuitive graphical programming environment.

In general, you should use business rules to make a decision when any of the following conditions are met:

• you want to change the results at runtime, on a running server instead of hard-coded logic in your solution.
• the decision itself naturally takes on the form of a table
• the decision itself naturally takes on the form of a series of textual if-then statements.

If you want to modify the business rule dynamically you must base your rule on a template. Basing rules on templates gives you more dynamicity at runtime and allows you to modify settings without involving an integration developer.

If your decision logic analyzes a collection of data or loops over a set of data, you should probably structure the decision in a sequential process, and call out to a rule set whenever there is configurable data.

Building business rules: task roadmap

A high-level view of the development of a business rule is presented.

You are in the process of planning your business process.

1. Decide if a business rule is an appropriate solution for your business process. A business rule is an ideal solution when you want to have flexibility to change your business process at runtime.
2. Create a rule group. The rule group is the primary element of a business rule, it provides the interface between the business process and the rule logic. The rule group also defines date ranges during which specific rule logic applies.
3. Decide which rule logic to use. Some business rules are better suited to a decision table, some to a rule set.
4. Create your chosen rule logic. The rule logic is either a rule set or a decision table.
5. Create templates for your rule logic. By creating a template for your rule set or decision table you can build up a library of rule logics that you can reuse in the future. The template also allows you to stipulate which parameters of the rule logic can be modified by the business analyst using the Business Rule Manager. Additionally constraints can be applied to these parameters so that the changes made with the Business Rule Manager are within acceptable ranges.
6. Assemble your rule group into a business process, test and deploy.

Choosing between a rule set and a decision table

You can capture business rule logic using either a rule set or a decision table. Here are some suggestions for how to decide which format to use.

Begin by sketching out a plan for your rules on a white board or a notepad. Use structure and terminology that is natural to the business environment in which these rules will be used. Then, look for the following trends in the finished product:

1. If your rules seem to take the form of a large number of unstructured sentences, then you should probably use a rule set to capture their business logic. A rule set is more flexible than the more structured decision table.
2. If you notice that every rule seems to use the same decision criteria, then it would be a good idea to use a decision table. In this case, the decision criteria that all the rules share in common can be captured once, and then you can define the parameters for each criteria.
3. If your rules naturally take the form of a table, then you should probably use a decision table.
4. However, if this table has a large number of holes, where some decision criteria are not applicable, or where the output values are undefined, then you should use a rule set. The structure of the decision table works well for regularity, but not for exception cases.

Creating a rule group

Create a rule group as a container for your business rules.

Create a new rule group by performing the following steps.

1. In the workbench, switch to the business integration perspective.
2. From the main menu, click File > New > Rule Group.
3. In the New Rule Group window, specify a module (or create one if necessary by clicking New), a folder and a name for the new rule group, and click Next.
4. In the select an interface window, browse to an existing interface or click New to create one. If you create a new interface here, you will have to create an operation using the interface editor before you can use it in the rule group.

This creates a rule group, and launches it in a new editor. Click any of the topics listed below to configure your new rule group.

Creating a rule set

This topic provides instructions on how to create a new rule set.

1. In the workbench, switch to the business integration perspective.
2. From the main menu, click File > New > Rule Set.
3. In the New Rule Set window, specify a module (or create one if necessary by clicking New), a folder and a name for the new rule set, and click Next.
4. In the select an interface and operation window, browse to an existing rule group, or click New to create one. If necessary, use the drop down lists to select a different interface and operation.
5. Click Finish.

This creates a rule set, and launches it in a new editor. Click any of the topics listed below to configure your new rule set.

Creating a decision table

This topic provides instructions on how to create a new decision table.

1. In the workbench, switch to the business integration perspective.
2. From the main menu, click File > New > Decision Table.
3. In the New Decision Table window, specify a module (or create one if necessary by clicking New), a folder and a name for the new decision table, and click Next.
4. In the select an interface and operation window, browse to an existing rule group, or click New to create one. If necessary, use the drop down lists to select a different interface and operation.
5. If you want to configure the layout of the decision table, click Next.
6. In the Decision Table layout window, use the settings to determine how the decision table will appear in the editor. The preview shows what the table will look like.
7. Click Finish.

This creates a decision table, and launches it in a new editor. Click any of the topics listed below to configure your new decision table.

Weak type support with business rules

Business object definitions can have XSD wildcards that can be used in business rules logic.

Such wildcards can represent a placeholder for any of the following:

• an arbitrary simple type (xs:anySimpleType)
• an arbitrary complexType (xs:anyComplexType)
• an arbitrary type (simple or complex, called 'xs:anyType')
• an arbitrary element (xs:any)

For more advanced mapping and expressions involving weak types or attributes use other components such as interfaces or business objects maps.

Restrictions:

• No local variables in a rule set can be of weak type.
• You cannot use weak types in computations or comparisons.

Choosing the correct template parameter values

To make sure that you don't have any syntax inconsistencies with template parameters in the runtime environment, please understand the following.

WebSphere® Integration Developer and WebSphere Process Server use a different syntax for template parameter values. This inconsistency does not affect rule set or decision table processing, but will make it more awkward to edit some business rules in the business rules manager.

In WebSphere Integration Developer, the value for a float template parameter must take the form '9.99f', where 9 is any number, and 'f' is a float delimiter. If the 'f' delimiter is not used in WebSphere Integration Developer, a validation error is added to the rule set. If the float value is syntactically correct, the rule can be deployed to the WebSphere Process Server server, and executed without error.

In the business rules manager, a value for a float template parameter must take the form '99.9'. If you view or edit the rule set or decision table in the Web client, a validation error will be added for any float value which includes the 'f' delimiter.

This inconsistency is only a problem if you want to modify the rules and save the new version to the WebSphere Process Server server. In this case, you must manually remove the 'f' delimiter from all float values in the Web client before you can save the new version

Refactoring business rules

When you refactor parts of your business rules, dependencies on those parts are automatically and universally updated throughout the product as a whole.

To refactor parts of your business rules, proceed as follows:

1. In the Business Integration view, right-click the business rule.
2. From the drop-down menu, hover over Refactor and then choose from one of the following three options:

Option	Description
Rename	Use this option to change the name assigned to the rule.
Move	Use this option to move your rule to a new folder or module.
Change Namespace	Use this option to assign a new namespace to your rule.

Generating documentation for your rules

If you need a high level synopsis of your business rules, including how they interact with other resources within the same project, you can create a customized report using the documentation generator.

A generated document can very quickly provide you with the following:

• a quick understanding of a project or resource
• an overview report about a complex project
• the visualization of the relationships and cross references of resources within a project
• a detailed report that can be printed out for certifications

To create a report for your business rules, proceed as follows:

1. In the Business Integration view, right-click either your rule group, rule set, or decision table and select Generate Documentation.
2. Configure the Documentation Generation wizard according to the instructions in the Generating documentation topic.

Launching the Business Rules Manager

The Business Rules Manager is a Web client that allows dynamic control of parameter values in template based rules that are deployed to the Websphere Process Server.

Before you begin

Make sure that both the server and client are configured correctly. See Considerations for installing the business rules manager for more information.

The default URLs for accessing the business rules manager are:

• https://hostname:9443/br (if security is enabled)
• http://hostname:9080/br (if security is not enabled)

where hostname is the name of the host.

WPS: Module Vs Mediation Module

Module Vs Mediation Module

The philosophy is that there are two sets of functions. ESB (Enterprise Service Bus) and Process Choreography (BPEL and Human Tasks). The ESB functions are also known as "mediations".

The Mediation Module can be used to hold ESB functions while the (Process) Module can hold Process Choreography functions. When WPS first came out, there was no ESB function so they grabbed the term "Module" to refer to an SCA solution. What you build with the assembly diagram editor in WID becomes the "Module". When WESB came along, a second type of Module was created so they called that a "Mediation Module". My guess is that if we could roll back time IBM would have called the "Module" the "Process Module" and not just "Module" for WPS.

The similarity between the two is that both are SCA assemblies. The difference between the two is the types of SCA components that can be added to each.

In a Mediation Module, you can have Imports, Exports, Java Components and Mediation Flow Componens.

In a (Process) Module, you can have Imports, Exports, Java Components, BPEL components, Human Task components, Selector Components, Interface Map components, State machine components, Selector components.

WPS: when do you choose long running or micro flows?

    Long-running processes involve services that do not respond immediately, run over a period of time and can involve people.

WPS: Difference between Inline and stand-alone human tasks?

Difference between Inline and stand-alone human tasks:

You can implement a human task as part of the logic of a business process, or independently of other processes.

If the task is implemented within a business process, it is called an inline task. Otherwise, it is referred to as a stand-alone task.

Inline task:

An inline task is defined within an implementation of a business process. It can either be implemented directly in the process using a human task activity, or as a property of an invoke, pick, receive, event handler, or on message activity.

When you are first planning your human task, you should model it as an inline task if any of the following conditions are present:

You need information from the process logic to run human interaction. Although information from the process can also be modeled into the input for a human task, the main reason to use an inline human tasks is because they have direct access to the process context without the need to explicitly model the required information into the input message.

You want to define authorization rights on specific activities

The standard method of creating an inline task is to drop a human task activity on to the canvas in the business process editor.

Stand-alone task:

A stand-alone task exists independently of a business process, and implements human interaction as a service that can be wired to any other component of the WebSphere® Integration Developer family of tools.

When you are first planning your human task, you should model it as a stand-alone task if any of the following conditions are present:

• The task provides just another service
• You intend to replace the stand-alone task later on and don't want to change the component to which it is wired.
• Create a stand-alone task using the New human task wizard and then wiring the task to a business process using the assembly editor.
  Changing a stand-alone task to an inline task :
• If you would like to take an existing stand-alone task that is invoked by an invoke activity in a business process, and transform it into an inline task that is implemented by a human task activity, proceed as follows:
• In the assembly editor, delete the existing interface between the human task component and the business process.
• Delete the component as well.
• In the business process component, right-click the invoke activity that originally connected to the human task component, and select Change type > Human task.
• In the Details tab of the human task, select New.
• Select the interface that was used between the original business process component and the human task component.
• Define the settings for the human task. From the main menu, click Project > Clean.