cancel
Showing results for 
Search instead for 
Did you mean: 

Extra . Character in the end of records after JMS content conversion

vinaymittal
Contributor
0 Kudos

We have a scenario ECC-->PI-->(MQ)WMS

we are using JMS adapters content conversion here on the receiver side sender is idoc.

till yesterday everything was fine but today some messages got failed at WMS End because of a extra character

the incorrect flat file received at there end is

I HAVE MASKED THE REAL NODE BY NODE1X , 2X ETC MAKING SURE THE LENGTH REMAINS SAME

NODE1X00384XEXC

OutXXXnd DeXXXXX

y Replication XX

2066201404261747

08.WHDEST8001003

83600101031    

.NODE2X800100383

THE PROBLEM HERE IS THIS (.) DOT SYMBOL

this should be 29 in length and it is "

"WHDEST8001003

83600101031     "

but the . just before NODE2X is the reason it is failing as length now bcomes 30 for this node and WMS doesnt accept it, the same idoc was triggered this morning it got passed without any issues instead of being happy they are are worried and want to know the reason why it failed the first time.

now they are not receiving any . symbol no change has been made in PI channel or mapping i checked mapping ran the payload there was no (.) generated from PI we are adding a linefeed at the end of each record as a separator but it is there from past one year and never that line feed got replaced by something like a (line feed + .) as in this case it seems to be.....where could have this . symbol come from please guide.

Accepted Solutions (0)

Answers (1)

Answers (1)

vinaymittal
Contributor
0 Kudos

channels were not restarted, at PI end

another mystry ..data was NEVER resent from PI or ECC how come it got reprocessed at the MQ at WMS end when they dont have such a functionality....

if this . was placed in the flat file that was converted from xml by PI after mapping and nothing has been sent from PI again that means that the . symbol must be still there in the payloads at JMS , then why is it not creating a problem today ...does it mean that yesterday the MQ wrongly interpreted the flat file sent from PI