WPS : BO CROSS COPY IMPLEMENTATION ERROR.

Issue : When we running the application at xslt mapping stage application is failed and throwing an error like "BO CROSS COPY IMPLEMENTATION ERROR"
Solution : make sure while we using xslt mapping it's validate the data. so it's expecting differnet format data but our data contains other.
ex : like it expecting float type but we are sending int type.

WPS : MQ overview

As q wps Developer we need to have basic knowledge on MQ, so this post helps you littile bit on MQ Overview.


IBM WebSphere MQ allows different applications to communicate asynchronously through queues across different operating systems, different processors, and different application systems.
WebSphere MQ includes the Message Queue Interface (MQI), a common low-level application program interface (API). Applications use MQI to read and write messages to the queues.
A queue manager is a system program that provides queuing services, and owns and manages the set of resources that are used by WebSphere MQ. These resources include queues, channels, process definitions, and so on.
A queue is a data structure used to store messages.There are several types of queue objects available in WebSphere MQ:

·         Local queue object – identifies a local queue belonging to the queue manager to which the application is connected. All queues are local queues in that each queue belongs to a queue manager, and for that queue manager, the queue is a local queue.

·         Remote queue object – identifies a queue belonging to another queue manager that is a different queue manager from the one to which the application is connected. This queue must be defined as a local queue to the queue manager to which the remote queue object belongs.

·         Alias queue object – is not a queue, but an object pointer to a local or remote queue.

·         Model queue object – defines a set of queue attributes that is used as a template to create a dynamic queue.

All types of queue objects can be sent in messages, but messages can be read only from local queue objects.
In addition to the queue object types that are available in WebSphere MQ, there are some other concepts about queues as well:

·         Remote queue definitions – are definitions for queues that are owned by another queue manager, and not queues themselves.

Remote queue definitions enable an application to put a message to a remote queue without having to specify the name of the remote queue or the remote queue manager, or the name of the transmission queue.

·         Predefined queues – are created by an administrator using the appropriate MQ Series commands (MQSC) or WebSphere MQ programmable command format (PCF) commands. Predefined queues are permanent, existing independently of the applications that use them, and persisting through WebSphere MQ restarts.

·         Dynamic queues – are created when an application issues an MQOPEN request specifying the name of a model queue. The queue created is based on a template queue definition, which is called a model queue. The attributes of dynamic queues are inherited from the model queue from which they are created.

·         Cluster queue objects – are hosted by a cluster queue manager and are made available to other queue managers in the cluster.

A channel is a logical communication link between a WebSphere MQ client and a WebSphere MQ server, or between two WebSphere MQ servers. There are two categories of channel in WebSphere MQ:

·         Message channels – are one-way links that connect two queue managers via message channel agents.

·         MQI channels – connect a WebSphere MQ client to a queue manager on a server machine, and are established when you issue an MQCONN or MQCONNX call. An MQ channel is a two-way link used to transfer only MQI calls and responses.

There are two channel types for MQI channel definitions:

o        Client-connection channel – connects to the WebSphere MQ client.

o        Server-connection channel – connects to the server running the queue manager, which communicates with the WebSphere MQ application that is running in an WebSphere MQ client environment.

The MQ channel supports the industry-standard Secure Sockets Layer (SSL) protocol. See your WebSphere MQ documentation from IBM for information on whether SSL is available on your platform in version 5.3 or 6.0 of MQ.
A process definition defines a process that executes when incoming messages cause a trigger event.
A WebSphere MQ message consist of two parts:

·         Message header – message control information that contains a fixed-sized portion and a variable-sized portion.

·         Message body – application data that contains any type of data (text or binary).

When you use rfhCommand to publish a publication, if the message payload returned by msgrecv is set to:

o        MQRHRF – the RF header is included in the message body.

o        MQRHRH – the RF header is not included.

You can obtain the name-value pairs in the RF header by querying @@msgproperties.

If the message body contains characters, code-set conversions are available either through MQ native services, or through user exit handlers. The format of the message body is defined by a field in the message header. MQ does not enumerate all possible message body formats, although some formats are provided in samples. Applications can enter any name of the format. For instance, “MQSTR” contains string data and “MQRHRF” contains topics for MQ pub/sub.

WebSphere MQ message types include:

·         Datagram – no reply is expected.

·         Request – a reply is expected.

·         Reply – reply to a request message.

·         Report – contains status information from the queue manager or another application.

When messages are sent, various message header properties can be set, such as expiration, persistence, priority, correlation ID, and reply queue.
Message grouping enables you to organize a group of messages into a logically named group. Within a group, each logical message can further be divided into segments. A group is identified by a name, each logical message within a group is identified by a sequence number (starting with 1), and each segment of a logical message is identified by the offset of the message data with respect to the logical message. Segmented messages are not supported by MQ pub/sub, and an attempt to send a segmented message results in an error.
In a queue, messages appear in the physical order in which they were sent to the queue. This means that messages of different groups may be interspersed, and, within a group, the sequence numbers of the messages may be out of order (the latter can occur if two applications are sending messages with the same group ID and partitioned sequence numbers).
When messages are received, the read mode can be either:

·         Destructive – message is removed, or

·         Nondestructive – the message is retained. This is known as “browsing,” and allows applications to peruse one or more messages before deciding to remove a particular message from the queue.

Receivers can select particular messages by specifying message header properties such as correlation ID or message ID.
When messages are read—as either destructive or nondestructive—the order in which they are returned can be physical or logical. The order is defined by the queue definition. The queue can be defined as being in priority order or first-in, first-out order.

WPS : Listner Port stoping in WPS V 7.5 Issue

Issue : When ever we get a unsupported format file for out application our application did not able to process that application. At that situvation out application will go to stop state automatically if it is adapters( Flat File). it will stop it's listner when it is dealing with MQ.

Solution : From WID V7.5 onwards we don't have listner properties. We have Activation Specification for system created for Faltfile adapter and for MQ we only create Activation Specification.
In Activation Specification we need to follow these steps.
Step 1 : open admin console
Step 2 : Resource --> JMS --> Activation Specification

 Step 3: Click on our activation specification

 Step 4: Click on Advanced Properties in Additional Properties.

 

 Step 5: In Advanced properties --> check additional properties : in that uncheck "Stop endpoint if message delivery fails" properties.

Step 6: Click on ok. save the changes. for effecting these changes we may need to restart the server.

WPS : Data Base Lookup Mediation Primitive Functionality

Introduction :  Database Lookuo Mediation primitive allows us to get the values from existing database by using key element and then update the message with values obtained from selected fields.

 

Terminals :  Database lookup primitive have 1 input terminal, 2 output terminals, 1fail terminal.

Input terminal :  which accepts the smo message which contains the key element.

Output Terminals :

Out terminal :  This propagates when the database lookup successful. The updated message is propagated from this terminal.

KeyNotFound: Database record not found with the specified key element, the unchanged message is propagated from this terminal.

Fail Terminal :  Which propegate the original message along with fail information in context

NOTE : Database Lookup primitive does not modify the message body structure, it modifies the message body contents.

Database Lookup mediation primitive properties :



Data Source :  The JNDI name of the datasource.
Table : Need to give fully qualified name. The name of the database table, including the schema name; for example, myschema.mytable.
Search Column : The name of the database's primary key column. The specified Search column must contain a unique value; multi-column database keys are not supported. In addition, the unique value must be of the same element type as the value located in the message using the Search location.
Search Location :  Where, in the input message, to find the database key. Specified as an XPath 1.0 expression; the value returned from the XPath expression is used as the key into the database.
Validate Input :  If you select the check box, the input message is validated before the mediation is performed.
Data Elements :  
 Column : The name of the database column from which to copy information. The valid type is String. 
 Type : The information type: the only supported String types are a simple XML schema type, or an XML schema type that extends a simple XML schema type. At run time, the value obtained from the database is converted to the type defined by the Type property.

Java primitive types or string are supported only for compatibility with old mediation flows.

 Target Location : Where, in the message, to store the information obtained from the database. The valid type is String. Specified as an XPath 1.0 expression describing the location of a message element. The XPath expression must evaluate to a single element in the message.

 Considerations :  Consider the following when using the Database Lookup mediation primitive:

• You must set up a database, datasource and any server authentication settings for the Database Lookup mediation primitive to use. You can do this using the runtime administrative console.
• The list of supported databases is provided on the systems requirements Web page for the runtime product.
• The Database Lookup mediation primitive can read only from one table.
• You can route a message to the same location whether or not the key is found in the database. To do this you wire both the out terminal and the keyNotFound terminal to the same output location.
• You can able to get single record by unique key element.

WPS BPEL : Can we change Microflow to Long Running & Long Running process to Microflow

Introduction : Business process in websphere integration developer can able to create in two different ways based on requirement. We can decide the process type based on people involvement required in process. After creating the business process (BPEL) we can able to change the type of he process by simple way.

Business Process Types :
1. Long Running Process (Macro flow) : want to run the flow with in period of time and involvement of people in the process.
2. Microflow : process run automatically from start to finish. It can not involve people.

Changing the Process Flow Type :

Step 1 : Open the BPEL Process.
Step 2 : Click on BPEL flow anywhere.
 


 Step 3 : Go to Properties --> Details --> you will find Refactor to-------- (1 in above image) --> click on that.





Step 4 : Click on Refactor. It will change the process type.