cancel
Showing results for 
Search instead for 
Did you mean: 

OTMA message via JMS Adapter - passing hex data

Former Member
0 Kudos

I have a rfc->PI->jms scenario. PI 7.1.1. The jms adapter calls MQ, which is an otma-based message (meaning that MQ upon receiving the msg, puts it onto an IMS queue, whereby the iih header is evaluated, and then hopefully triggers the appropriate IMS transaction). In PI, I thus construct the otma iih header, and it needs to contain hex values, as well as string values.

The issue I have is the IMS side does not recognize the hex values.

I set these values in PI (mapping), then in the jms adapter module, the data gets changed from xml data to structured (see below). What settings need to be set in order to have the MQ/IMS side be able to understand the data coming over? Currently, the hex data is not recognized and thus the IMS side kicks the message into error - it therefore never reaches the actual IMS transaction. Here is my jms module conversion set-up, which is where I assume my problem resides:

...

Transform.Class ; com.sap.aii.messaging.adapter.Conversion

Transform.ContentType ; text/plain;charset=utf-8

xml.iih_rqst.fieldFixedLengths 4,2,4,4,4,8,4,8,8,8,8,16,1,1,1,1

...

I.e. the first field is 4 chars, but the next two fields are hex. The IMS side does not recognize the values in these two hex-based fields (or it recognizes them but they are wrong) - the first hex field value is 0522, but it comes across as string and is truncated, thus shows as 05 in IMS.

I assume the utf-8 is wrong, but what should it be? Anything else wrong that anyone sees - should these hex fields be defined as hexBinary on the design side? Has anyone out there done otma-based messaging via jms?

Keith

Accepted Solutions (0)

Answers (2)

Answers (2)

lsubatin
Active Contributor
0 Kudos

Hi, Keith, have you been able to solve this? If so, could you please explain how? I am having the same problem.

Thank you very much in advance.

Lucía.

stefan_grube
Active Contributor
0 Kudos

First of all you have assigned the string 0522 to the XML.

You have to do a conversion inside an UDF to create characters from the hex representation.

Second you cannot have control characters in an XML, that means ascii values < 32

Maybe you try it, but I am not sure if that works.

Former Member
0 Kudos

Thanks Stefan. Do you have an example of example udf code? If a field named 'version', value of 1, needs to show on mf as 0000 0001 (another example is field 'fieldb' needing to be value 84, i.e. appear on mainframe side as 0000 0054, i.e. hex value)? What should these fields be declared as within PI... xsd:hexBinary?

Any thoughts appreciated.

stefan_grube
Active Contributor
0 Kudos

> If a field named 'version', value of 1, needs to show on mf as 0000 0001

When this does mean, that you need byte values 0 0 0 1, then you cannot do this with FCC at all.

You need to write an ABAP/Java mapping or an adapter module.

Former Member
0 Kudos

I may not have explained this very well.

Currently (pre-PI), the data shows in the mainframe MQ queue as (showing one row of 8 bytes):

(hex values) (equivalent ebcdic values)

C9C9 C840 0000 0001 'IIH ....'

I.e. the values I, I, H, (space), then nul, nul, nul, soh.

So, I need PI to do the same (via the jms adapter, and also because the mainframe does not know xml, additionally use adapter module config. to convert the PI xml to one big string).

But, when I try this in PI, I get something like:

(hex values) (equivalent ebcdic values)

C9C9 C840 F0F0 F0F1 'IIH 0001'

This is based on the following table:

http://ascii-table.com/ebcdic-table.php

Keith

stefan_grube
Active Contributor
0 Kudos

There is no standard way to add control characters to the message.

FCC works character oriented, you could add control charcters as delimiters (like tab), but that won't help you.

I think the best approach would be: use FCC for the characters and use a self-written adapter module to add the control sequences.

Another approach would be changing the message on receiver side.