I need to implement a persistent store mechanism between a Natural client and a Java server. I’d like the Natural logic to be as simple as possible (for maintainability by a staff that isn’t Natural savvy).

Is there any reason I couldn’t/shouldn’t implement the RPCBMQBridge for use by the sending application, but ultimately process the UOW’s with ACI for Java?

Thanks in advance.

Hi Michael,

I see no reason not to use EntireX RPC BMQ Bridge for this purpose. With EntireX RPC BMQ Bridge you do not have to care about persistence and UOW. All this is encapsulated.

Thanks for your quick response Mogens!!

Hi Michael,

As already mentioned in another posting the intention of the BMQ Bridge is that both the sender and the receiver of the UOW is using the Bridge via RPC calls.

The reason for this is that the Bridge uses an internal marshalling of the different IDL data types. If you read a UOW message produced by the Bridge via ACI you might get some unexpected results. This depends on the data types you are using in your IDL file. Do you have an example of an IDL file (or Natural data area) you are planning to use ?

For this project we are just using it to send a single variable length text string (the same BMQString.idl file that came with EntireX).

LibStr
StrIn
PString (AV) IN
StrOut
PString (AV) OUT

My needs are simply:

1. Natural send multi-message persistent UOW.
2. Java forward UOW to MQ as a Message Group.

I don’t know if I’m headed down the right path or not, I like RPC on the Natural side (again, due to our programming staff), but I prefer ACI on the Java side. Also, the documentation seems to elude to the fact that Natural can open a conversation, send multiple messages, and then close the conversation (either committing the UOW or rolling it back). Is this true?

Sorry if this is elementary, I’m new to all of this and trying to learn AND get my project done on time…

As you have already noted the Bridge represents a variable length Alpha field with the length and a comma character. If your Java app takes care of this that should be fine.

Yes, that’s correct. Use the Natural OPEN CONVERSATION and CLOSE CONVERSION (backout/rollback). Call USR2032N before CLOSE CONVERSION to send a commit.