Dynamic configuration in Sync/Async bridge in JMS

[abhijitbolakhe]

Hi

Scenario:

Portal sending request to JMS MQ and getting Response using sync/Async Bridge.

I have to written a UDF which will capture the value for cust_uid from request mapping and store it in dynamic configuration

And when the response comes from JMS MQu2026.this value gets populated in response mapping.

I have tested the UDF in a dummy Soap2rfc scenario and its working fine.

But when used in Sync/Async Bridge, the dynamic configuration fails.

For Sync/Async Bridge, there are 2 channels 1) Sender JMS 2) receiver JMS.

The synchronous request is converted to an asynchronous request in the module processor and sent.

The asynchronous system sends a response to a sender adapter. In the module processor of the sender adapter, this response is forwarded to the module processor of the original receiver adapter, where it is sent as a synchronous response of the waiting synchronous request.

Please suggest

Regards

Abhijit

[Former Member]

Hi,

The reason this does not work for asynch scenarios (the synch/asynch bridge actually consists of asynch interfaces) is because the mappings are stateless. Persistency of data cannot be carried across stateless objects.

I can think of 3 possible alternatives for your situation:

1. Use ccBPM.

2. Store the Cust_Id in a database table using unique keys such that you can correlate the request to the response.

3. Store the Cust_Id in a global public class (or EJB) instead of database table. The content of this class will be initialized upon server restarts, thereby, loosing whatever is in there.

Regards,

Bill

[abhijitbolakhe]

Hi Bill

Sorry for late reply.

The options suggested by you...options 1 & 2 are outof scope for me....

option 3 : Does it mean to use global container....but i assume that global container can be used in the same mapping.

But i am having Request & Response mapping.

Please suggest.

Regards

Abhijit

[Former Member]

Hi Abhijit,

Mapping is stateless but is it relevant?

You have four messages per call: two asynchronous messages and two corresponding synchronous messages that form a request-response pair. They all share the same module processing context. So I think you can technically transfer data from one message to another using the module's data context. Once the data is included in the message, your mapping can see it.

In order to be more precise and concrete, you should describe your scenario more precisely. Which data must be extracted from which message and to which message, this data must be transfered?

Regards, Yza

[abhijitbolakhe]

Hi Yza

Scenario is Portal(sync) to JMS MQ(Sync/Async bridge).

I have a field cust_id in source message.

there is no mapping for field cust_id in request mapping.

But i need the cust_id value in the response .

So i have created 2 udf's with dynamic configuration...

1) first udf will take the cust_id value from source message payload and store in dynamic config.

This udf is mapped in between source field & body node in request mapping.

2) Second udf will take the stored cust_id value from dynamic config & populate it in the response field.

This udf is mapped to the target field in response mapping.

I have tested the udf without sync/async bridge interface and its working absolutly fine.

But it is not working in case of JMS (Sync/Async Bridge).

Is there any other way of doing this...?

Regards

Abhijit

[Former Member]

Hi Abhijit,

Okay, so your data extraction/insertion is working fine for a simple synchronous request responser call.

I suppose this is working fine because your receiver adapter copies some part of the request message (at least the dc header) to the response message. (But I don't think this always works for all the adapter types). It is not working for the sync-async bridge because there are two unrelated messages in this case.

In order to copy the dc header from the first message to the second message, I think you can use the DynamicConfiguraitionBean module to store the dc header value in the module data and use this module again to recover it and set it to the second message. The whole process is somewhat complicated, but I will sketch the approach below.

First, let's call the first use of DCB the store step and the second the recover step. These store and recover steps must take place in the same module sequence so that they can use the module data to pass data from the first message to the second message. Furthermore, the store step must occur after the cust_id value is extracted into the dc header. So, your configuration must be placed in the receiver adapter side. Assuming the request message with the filled dc header coming into the module sequence, the first DCB module can be placed before the ROB module to store the dc header value in the module data. And the second DCB module can be placed after the WRB module to recover the dc header value from the module data and set it the dc header of the response message.

I hope this will work.

Regards, Yza