Determine Sender and Receiver in adapter module?

[Former Member]

All,

Non-XML messages from different senders are received via the same JMS queue. In the text payload, the ID of the sender and receiver is contained.

Would it be technically possible to develop a JMS adapter module that sets the Sender Party, Sender Service, Receiver Party and Receiver Service based on the content of the message payload? Is it possible to influence sender and receiver in an adapter module?

Kind regards, Guy Crets

[Steven_UM · Accepted solution]

Hi Guy,

Out of my head I believe it should be possible ... You should check the JAVA API and look at the class XIMessage and others within the package ...

If I recall well there are some classes there that allow you to manipulate content and header ...

Regards,

Steven

[Former Member · Accepted solution]

Steven,

I checked the API. I don't see any direct way to set the ToParty or ToService in a module.

The 'process' method of the Module interface has 2 arguments: ModuleContext and ModuleData. The ModuleData most probably points to a 'Message' interface. On this 'Message' interface, there is unfortunately no setToParty() or setToService() method.

Kind regards, Guy Crets

FYI: I work together with Frank Bakermans

[Former Member · Accepted solution]

All,

Maybe it is possible and allowed (?) to

1st oldMessage = ModuleData.getPrincipalData()

2nd create new Message

copy data from oldMessage to newMessage

3rd ModuleData.setPrincipalData(newMessage)

Kind regards, Guy Crets

[Steven_UM · Accepted solution]

Hi Guy,

You are right about the API .. I checked it now and there are a lot of methods of getting the header fields but actually none for changing them ...

Seems like your idea is the best way forward ... Use the messagefactory class to instantiate a new message and copy the actual payload within in ... Only issue might be the unique message id ... Not sure you can get away by either creating a new one and convince XI to pick up your new message or either duplicate the existing message id ...

Looks challenging ... let us know how it goes ...

Regards,

Steven

PS: Say hi to Frank from me !

[Former Member · Accepted solution]

Hi Steven,

It seems like you can not convince XI to pick up a new message. The code below works when you use "inputModuleData.setPrincipalData(msg);" but not with "inputModuleData.setPrincipalData(msgnew);".

The error in the Runtime Workbench is: "Catching exception calling messaging system' found, cause: javax.transaction.InvalidTransactionException: Cannot invoke call from within a transactional context.".

I tried to set the RefToMessageId on the new message, but this does not work either.

Does anybody know why the InvalidTransactionException is thrown?

Here is the example code:

public ModuleData process(ModuleContext moduleContext, ModuleData inputModuleData) throws ModuleException

{

try {

Message msg = (Message) inputModuleData.getPrincipalData();

Context ctx = new InitialContext();

ConnectionFactory cf = (ConnectionFactory) ctx.lookup(

com.sap.aii.af.ra.ms.api.ConnectionFactory.JNDI_NAME);

MessageFactory factory = cf.createMessageFactory("XI");

Message msgnew = factory.createMessage(

msg.getFromParty(),msg.getToParty(),

msg.getFromService(),msg.getToService(), msg.getAction());

msgnew.setConversationId(msg.getConversationId());

msgnew.setDocument(msg.getDocument());

inputModuleData.setPrincipalData(msgnew);

}

catch (Throwable t)

{

ModuleException me = new ModuleException("MyException");

throw me;

}

return inputModuleData;

}

Best regards,

Simon

[Former Member · Accepted solution]

Hi Simon,

The reason for your error is not the new message, but rather that you are invoking the synchronous sending method call(...) instead of the asynchronous sending method send(...) from within a transactional context.

The problem with this is that there are operations that will need to take place in the call method that will then need to wait for a commit/rollback so that it can proceed with message sending. Since it's a synchronous call you run into a circular wait condition where the subsystem is waiting for you to commit so that it can proceed and you are waiting for it to return so that you can commit.

Therefore, invoking the synchronous call from within a transactional context has been disallowed. There's really no reason for it anyway, so you basically have two options. 1. Turn of the transaction (either through .suspend() or changing the container settings), or 2. use an asynchronous send.

Hopefully that helps.

Cheers,

Steve

-

---

If you find a post useful, please help keep the community going by setting a good example and rewarding the poster with points.

[Former Member · Accepted solution]

Success!!

In a Java module of the J2EE File adapter, we were able to set the Sender and Receiver. The only thing we still need to configure is the Parties, Services, Communication Channels and Receiver Agreement in the Integration Directory. But no more receiver determination or interface determination needed.

Questions remain:

- Are we correctly using or are we mis-using the possibilities of the adapter modules?

- How to do this in non-J2EE adapter, in particular the HTTP adapter>

PS: see posts above for functional background

Kind regards, Guy Crets

PS: thanks Steve Winkler and in particular Simon Bulthuis