I had to develop a DataPower solution that would selectively accept or reject a message from a client application, on the basis of how large the submitted payload was. The payload could vary from 120 Bytes to a few Kilobytes. Due to the dynamic nature of their business, the customer did not want to impose a hard-coded limit on the transaction size. We came up with a solution to abstract out these policy details from the application integration logic.

To keep this blog posting concise, I shall explain how you can do this size enforcement by setting a Context variable (var://context/simplePolicy/allowedSize). Other methods of setting these limits (including a local XML file, a policy file in WSRR, etc) are also viable

Incoming data would arrive over HTTP and the payload would always be
JSON. I created a simple Multi-Protocol gateway that accepts data over HTTP protocol, does policy enforcement and forwards the requests to the backend HTTP Server. I could not use the size limits imposed by the XML manager for this solution due to the variation in the incoming payload size limits (120
bytes - 4 KB).
The Request and Response rules of the Multi-Protocol gateway are configured to process Non-XML (JSON) data

I use a Binary Transform action, followed by a Transform action. This is in order to measure the size of the incoming payload. Hence my policy looks as under

When I send JSON data to this gateway, that exceeds the allowed size of 120 bytes, the policy throws an exception as expected.

When I create a reusable rule of the Transform Binary and Transform actions,

I start to see the below error

Although, we have set at the gateway level that the request data is of
type Non-XML, the same has to be set at the Processing Rule level also.
From the left hand navigation panel, go to the Processing Rule that invokes the reusable rule. Select the radio button for Non-XML processing.

Failure to do so will result in an error being thrown. This is because DataPower implicitly tries to parse the payload being sent to a reusable rule as XML. By changing the Processing Rule to handle Non-XML data, we can configure DataPower not to implicitly parse all the data being sent to the reusable rule as XML

Once these changes are made, we can verify the proper working of the gateway that calls a reusable rule.

SIEBEL is a market leading CRM Solution. More and more organizations are embracing SIEBEL to give their clientele a better customer experience.

WebSphere Message Broker 7 being IBM's premier universal SOA/ESB transformation and integration engine ships with SIEBEL Adapters to Create/Retrieve/Update/Delete data from SIEBEL Systems.Users of WebSphere Business Integration Adapters might already be familiar with SIEBEL Adapters that they have previously used. This has now been incorporated within the Generally Available (GA) Message broker offering at no extra cost.

Customers can choose to run multiple Virtual Machine Images of SIEBEL Applications to provide redundancy and load balancing. SIEBEL Adapters that ship with the Message Broker can be configured to make use of this feature.

Special Thanks to all the brilliant people who work in IBM Support and IBM Product Development for providing invaluable guidance and assistance

The below steps illustrate how this can be setup on a WMB Server running an UNIX Environment.

Your run time version of the Message Broker must be at least at fixpack compatibility level of 7.0.0.2 to make use of this feature. As a pre-requisite, verify whether your run time is already at v7.0.0.2 using the below command

During development and testing, we are required to an iterative discovery using the adapters. This is needed so that our Business Objects and in turn our Message Sets are reflective of the Business Objects within SIEBEL. Thus the adapter files that we create have the hard-coded IP address:Port and user id and password that was used to connect to the Development Server.If you want to connect to a clustered SIEBEL Environment, then you would have to modify the .adapter file that is generated to include the keyword VirtualServer.

Create a siebel.properties file in the below fashion and place it in a directory that can be accessed by the broker user id (In my case eaiuser)

Note that this is a comma separated list to enable the JAVA Data bean API to do substitution for Virtual Server to one of the values configured in the list within the properties file using SIEBEL's native round-robin load balancing.

Create a configurable Service with the same name as the adapter name. (Note that my adapter is called Create_CustOrder.outadapter)

Security groups within most organizations mandate that passwords must be changed on a frequent basis to prevent malicious access to servers. WMB supports setting this at runtime such that operational staff can change it (Note that a reload of the execution group is necessary for this password change to take effect)

Recently, I had to implement a REST Proxy Gateway on DataPower. REST has been around for quite some time and is very well documented.

The solution requested by the customer was as follows

A HTTPS Connection originating from the internet would be terminated on the DMZ

DataPower to initiate a new connection to the secure network via clear text HTTP

A HTTP Authentication Check would be performed on the incoming HTTP Header before being permitted to the secure zone

The business logic for the handling and processing of the data would rest in the Payment Gateway and DataPower would have to pass through the request and response transactions without any manipulation of the data

Using DataPower as a REST proxy to provide a facade to back-end servers is a recommended design. It gives you the benefit to plug-in additional features - such as Authentication, Authorization and Audit in addition to Service Level Monitoring. This is accomplished without writing a single line of code. Configure-not-code is the phrase that we use in DataPower discussions.

Here's a screen capture of my Policy

Since I had to provide this solution to a remote team, connecting directly to the back end was out of the question. I was given a bunch of sample JSON files.

I have used soapUI for quite some time and I find that it is a brilliant tool for unit-testing web services based applications. After searching on the internet, I found out that soapUI can also be used for mocking REST based services very similar to mocking web service responses

For the front end testing, I use cURL - A fantastic command line utility that has lots of options that enables you to test Web Applications, Upload and download files from remote servers http://curl.haxx.se/docs/manpage.html

The command I use to test the proper working of my Mock Service is as under. I shall modify this later on to invoke the service on DataPower instead of localhost:8080 (Which is where my soapUI Mock service is running)curl --verbose --user fred:flintstone --data-ascii @balanceInquiry.json http://localhost:8080/balanceInquiry

Stored Procedures are an excellent way to abstract Database related operations from other participating entities in a business process.

The interfacing applications only need to invoke this stored procedure and not worry about the underlying functionality. For all practical purposes the Stored Procedure is a functional end point (Black Box)

During the course of a major integration project, there might be a requirement for the Enterprise Service Bus (In our architecture WebSphere Message Broker) to invoke a Stored Procedure.

Scenario

An Oracle Stored Procedure inserted values into an user table. After the INSERT into the table succeeded, an Oracle trigger logic was used to perform subsequent business logic in transactional mode before returning status of stored procedure back to WMB. This stored procedure had been running successfully in production for many years.

When the stored procedure was invoked from WMB, the below error was encountered, the transaction could not be completed.

[IBM][ODBC Oracle Wire Protocol driver][Oracle]ORA-01861: literal does not match format string ORA-06512: at "SCHEMA.TRIGGER", line 10 ORA-04088: error during execution of trigger ' SCHEMA.TRIGGER' ORA-06512: at "SCHEMA.TABLE", line 100 ORA-06512: at line 1

Error line 100 in the trigger corresponded to the below line of code, this was found to be the root cause of the error

When I tried to execute this stored procedure via SQLPlus client for Oracle, using the same data used by WMB, the transaction completed successfully.

Since the purpose of WMB integration was to automate this business process, the business users just wanted this functionality to be implemented. Google indicated that this could be related to the National Language Settings on Oracle

When we query the NLS Settings from the SQLPlus Oracle Client , the results obtained were as under

WebSphere Message Broker interacts with Databases using the ODBC Drivers supplied by DataDirect and are shipped with the product installation.

To verify the NLS Settings as seen from the within WMB, in conjunction with the DataDirect Drivers, i put together this simple flow.

I used a Trace node to print out the contents of the Environment Tree.

The ESQL code that is used within the Compute Node to assign the result of the NLS Settings to the Environment variables, has been shown below

PASSTHRU statement within ESQL is used for executing complex database queries/ Administrative Database Commands. Whatever query is passed within the PASSTHRU command is processed in its entirety by the Database Manager(In this case Oracle)

The trace node output reveals that there is a mismatch between the NLS Settings used by the WMB ODBC drivers and the NLS Settings that were used by SQLPlus Oracle Client application. This mismatch can be resolved by using an ALTER SESSION command to change the behavior of the client session(In this case WMB).

Hence, prior to invoking the stored procedure, the default NLS_DATE_FORMAT used by the WMB ODBC Drivers for Oracle would have to be over-ridden to prevent this error.

The following snippet of ESQL Code was executed prior to invoking the Stored Procedure within the Compute Node

This setting is not global in nature and is equivalent to setting a client session Level variable to Oracle and remains in effect till the execution of the current session is complete.

Note

This is not mandatory for all Oracle Stored Procedure Invocations from WMB7. Use this work around, only when you have encountered an issue with a legacy Stored Procedure. Well Coded Stored Procedures that use CASTS judiciously would not hit this problem.

Since there is an additional query being invoked, there is an overhead apart from just executing the stored procedure from WMB.