| Author |
Message
|
| jbanoop |
 Posted: Wed Feb 08, 2012 4:37 pm Post subject: MRM failing in AIX but successful in Linux -MB v7.0.0.1 |
 |
|
Chevalier
Joined: 17 Sep 2005
Posts: 401
Location: SC
|
All,
Our environment is MB 7.0.0.1.
ECC code page is 4110 (UTF 
We have an SAPInput node based flow receiving data from ECC using the generic IDOC pattern.
This message is processed in a subsequent flow which retrieves the IDOC stream data, casts it to BLOB and then reparses that blob against the MRM file IDOC message set.
Code snippet that does it is:
| Code: |
DECLARE parseOptions INTEGER BITOR(ValidateValue, ValidateContent,ValidateException, ValidateComplete, ValidateFullConstraints);
CREATE LASTCHILD OF Environment.Variables DOMAIN 'MRM' PARSE(CAST(InputRoot.XMLNSC.ns:SapGenericIDocObject.IDocStreamData AS BLOB CCSID 1208) OPTIONS parseOptions SET 'GENERIC_FILE_IDOC_MS' TYPE 'File_IDoc' FORMAT 'R3Link');
|
I have also tried:
| Code: |
DECLARE parseOptions INTEGER BITOR(ValidateValue, ValidateContent,ValidateException, ValidateComplete, ValidateFullConstraints);
CREATE LASTCHILD OF Environment.Variables DOMAIN 'MRM' PARSE(CAST(InputRoot.XMLNSC.ns:SapGenericIDocObject.IDocStreamData AS BLOB CCSID 1208) CCSID 1208 OPTIONS parseOptions SET 'GENERIC_FILE_IDOC_MS' TYPE 'File_IDoc' FORMAT 'R3Link');
|
and
| Code: |
DECLARE parseOptions INTEGER BITOR(ValidateValue, ValidateContent,ValidateException, ValidateComplete, ValidateFullConstraints);
CREATE LASTCHILD OF Environment.Variables DOMAIN 'MRM' PARSE(CAST(InputRoot.XMLNSC.ns:SapGenericIDocObject.IDocStreamData AS BLOB) OPTIONS parseOptions SET 'GENERIC_FILE_IDOC_MS' TYPE 'File_IDoc' FORMAT 'R3Link');
|
AIX
-----
CCSID of broker : 819
When certain UTF 8 characters come from ECC, the parsing of the BLOB goes awry because some utf 8 characters need multi byte representation not supported in 819.
All above snippets result in MRM parsing errors because it is intepreted as multiple characters.
Linux
-------
CCSID of broker : 1208
The message is successfully parsed with the right representation without any issues.
Is this because the create parse is trying to parse it using the OS/Broker CCSID id or is it something that I have missed out ?
I understand that the solution to the problem lies in getting the broker code to parse this as UTF 8.
Any help would be really appreciated. |
|
| Back to top |
|
 |
| fjb_saper |
| Posted: Wed Feb 08, 2012 7:23 pm Post subject: |
|
|
Grand High Poobah
Joined: 18 Nov 2003
Posts: 20696
Location: LI,NY
|
Check the endianness set during the import of the SAP definitions... 
_________________
MQ & Broker admin |
|
| Back to top |
|
|
| jbanoop |
| Posted: Wed Feb 08, 2012 7:48 pm Post subject: |
|
|
Chevalier
Joined: 17 Sep 2005
Posts: 401
Location: SC
|
We are trying to parse the input idoc stream using the ibm given message set.
I did not quite get what you meant i guess.
Can you elaborate a bit more ? |
|
| Back to top |
|
|
| kimbert |
| Posted: Thu Feb 09, 2012 2:32 am Post subject: |
|
|
Jedi Council
Joined: 29 Jul 2003
Posts: 5542
Location: Southampton
|
Your code:
| Code: |
DECLARE parseOptions INTEGER BITOR(ValidateValue, ValidateContent,ValidateException, ValidateComplete, ValidateFullConstraints);
CREATE LASTCHILD OF Environment.Variables DOMAIN 'MRM' PARSE(CAST(InputRoot.XMLNSC.ns:SapGenericIDocObject.IDocStreamData AS BLOB CCSID 1208) OPTIONS parseOptions SET 'GENERIC_FILE_IDOC_MS' TYPE 'File_IDoc' FORMAT 'R3Link'); |
is equivalent to
| Code: |
DECLARE parseOptions INTEGER BITOR(ValidateValue, ValidateContent,ValidateException, ValidateComplete, ValidateFullConstraints);
DECLARE IDocData BLOB;
# Create a stream of characters in CCSID 1208
SET IDocData = CAST(InputRoot.XMLNSC.ns:SapGenericIDocObject.IDocStreamData AS BLOB CCSID 1208);
# Now do the parsing
CREATE LASTCHILD OF Environment.Variables
DOMAIN 'MRM'
PARSE( IDocData
OPTIONS parseOptions
SET 'GENERIC_FILE_IDOC_MS'
TYPE 'File_IDoc'
FORMAT 'R3Link'); |
So...at what point are you telling the MRM parser to use CCSID 1208? |
|
| Back to top |
|
|
| jbanoop |
| Posted: Thu Feb 09, 2012 5:04 am Post subject: |
|
|
Chevalier
Joined: 17 Sep 2005
Posts: 401
Location: SC
|
Kimbert,
Thanks for replying. I was hoping you'd look at this.
In code snippet 2 in my first post i am giving CCSID 1208 in the parse statement as well (in addition to the cast).
Am i missing something ? |
|
| Back to top |
|
|
| lancelotlinc |
| Posted: Thu Feb 09, 2012 5:36 am Post subject: |
|
|
Jedi Knight
Joined: 22 Mar 2010
Posts: 4941
Location: Bloomington, IL USA
|
| jbanoop wrote: |
| Am i missing something ? |
Update your runtime to a modern fix pak. 7.0.0.3 Ifix 2 is out.
It may not solve your problem, but why run on an old fix pak?
_________________
http://leanpub.com/IIB_Tips_and_Tricks
Save $20: Coupon Code: MQSERIES_READER |
|
| Back to top |
|
|
| jbanoop |
| Posted: Thu Feb 09, 2012 5:39 am Post subject: |
|
|
Chevalier
Joined: 17 Sep 2005
Posts: 401
Location: SC
|
We plan on doing that but it takes time and this is a current prod problem.
We need to address this now but upgrading is a longer term plan. |
|
| Back to top |
|
|
| mqjeff |
| Posted: Thu Feb 09, 2012 5:42 am Post subject: |
|
|
Grand Master
Joined: 25 Jun 2008
Posts: 17447
|
Have you eliminated the possibility that the input blob is not already in 819?
Have you eliminated the possibility that the XML message that contains it has treated the data as character data and not a blob, and thus done conversion? |
|
| Back to top |
|
|
| smdavies99 |
| Posted: Thu Feb 09, 2012 5:48 am Post subject: |
|
|
Jedi Council
Joined: 10 Feb 2003
Posts: 6076
Location: Somewhere over the Rainbow this side of Never-never land.
|
| mqjeff wrote: |
Have you eliminated the possibility that the input blob is not already in 819?
Have you eliminated the possibility that the XML message that contains it has treated the data as character data and not a blob, and thus done conversion? |
As the SAP ECC6 is going to output UTF messages by default, is there a show stopping 'real business' reason why the two systems have different Queue Manager CCSID's?
_________________
WMQ User since 1999
MQSI/WBI/WMB/'Thingy' User since 2002
Linux user since 1995
Every time you reinvent the wheel the more square it gets (anon). If in doubt think and investigate before you ask silly questions. |
|
| Back to top |
|
|
| jbanoop |
| Posted: Thu Feb 09, 2012 5:49 am Post subject: |
|
|
Chevalier
Joined: 17 Sep 2005
Posts: 401
Location: SC
|
We took the mq message from aix (from the sap receiver flow) via rfhutil and put it into the same flow deployed on linux and it worked.
Theccsid of that msg ( generic idoc data obj msg) was 819.
However it worked perfectly in linux.
So i was assuming that this had something to do with the create-parse statement and the ccsid it was trying to parse using.
If it was treated as char data then it would also have failed in linux was my thought.. |
|
| Back to top |
|
|
| lancelotlinc |
| Posted: Thu Feb 09, 2012 5:53 am Post subject: |
|
|
Jedi Knight
Joined: 22 Mar 2010
Posts: 4941
Location: Bloomington, IL USA
|
SAP adapter does not currently support flatfile IDocs. I'm not sure if by re-casting to BLOB, you may be somehow running across that issue. Enterprise Metadata Discovery has a setting that helps WMB determine the details of business objects. If the IDoc version being processed is not the same as when the EMD routines first encoded the data definition, you may end up with extraneous data or malformed tree. The correction is to re-run EMD to update the data format definition. Several bug fixes related to this function went into 7.0.0.3. If you insist on running on 7.0.0.1, you may be at your own mercy since the code fixes are already in the fix pak.
In any event, open a PMR if its a production problem.
_________________
http://leanpub.com/IIB_Tips_and_Tricks
Save $20: Coupon Code: MQSERIES_READER |
|
| Back to top |
|
|
| kimbert |
| Posted: Thu Feb 09, 2012 6:02 am Post subject: |
|
|
Jedi Council
Joined: 29 Jul 2003
Posts: 5542
Location: Southampton
|
| I don't think the problem is related to the CREATE...PARSE statement in your ESQL. You need to go back to basics and check that the string in InputRoot.XMLNSC.ns:SapGenericIDocObject.IDocStreamData is being parsed correctly. If not, check that the input CCSID is correct - maybe the sender is encoding the input data wrongly. |
|
| Back to top |
|
|
| jbanoop |
| Posted: Thu Feb 09, 2012 6:27 am Post subject: |
|
|
Chevalier
Joined: 17 Sep 2005
Posts: 401
Location: SC
|
Kimert,
I will do that and update with the details of my findings.
The puzzling thing is that the same message when run thru the same flow works in linux but breaks in AIX.
I will do more research and post my findings. |
|
| Back to top |
|
|
| lancelotlinc |
| Posted: Thu Feb 09, 2012 6:31 am Post subject: |
|
|
Jedi Knight
Joined: 22 Mar 2010
Posts: 4941
Location: Bloomington, IL USA
|
| jbanoop wrote: |
| works in linux but breaks in AIX. |
Sounds like platform environment issue. Another place to check is whether or not the CONVERT flag is ON for your MQ channel negotiations.
_________________
http://leanpub.com/IIB_Tips_and_Tricks
Save $20: Coupon Code: MQSERIES_READER |
|
| Back to top |
|
|
| jbanoop |
| Posted: Thu Feb 09, 2012 4:37 pm Post subject: |
|
|
Chevalier
Joined: 17 Sep 2005
Posts: 401
Location: SC
|
I belive the issue might be because like mqjeff sid, the hex coming out of the adapter flow is literally interpreted as character.
This leads me to the next question:
is there a way we can convert that charecter ized blob to a real blob ?
| Code: |
4544495F44433430202032303030303030303030303131343031383
531373031203330313220204D41544D41533035202020202020202020202
020202020202020202020205A4D4D41544D415330352020202020202020
2020202020202020202020204D41544D4153202020202020202020202020
2020202020202020202020 |
Assuming that the above is the character string representation of the actual blob, how can I get this converted to the real blob ?
Hope I have not been confusing.. Any help would be really appreciated.. |
|
| Back to top |
|
|
|
|
