I had business requirement to move the FTP polling job to OSB instead of using the FTP Adapter directly from BPEL. Earlier implementation was FTPAdapter will get the DAT file from remote location, translate the file content based on the native schema defined and then initiate the RequesterABCS component.
As part of the new requirement I used OSB FTP Protocol approach to get the file from ftp server and then from OSB the file content to a JMS Queue.
Then a JMSAdapter will consume the message from the queue and it will initiate the same requester component.
The new approach was working fine for some payloads. But for some payloads it was throwing "TF_GENERAL_TRANSLATION_FAILURE,Please correct the NXSD schema". The same payload were working fine with the initial approach.
I compared the DAT file content and the message posted in the queue by OSB. The message size in the queue were slightly higher than the original DAT file. This lead me to think that OSB file transfer might be adding some characters like carriage return or line feed, which might be the cause of this increase size of the message.
In the OSB proxy service, the transfer mode was ASCII, I changed this to Binary. Retested, the original file size and the message size matched . Also the JMSAdapter started processing the messages without any errors.
As part of the new requirement I used OSB FTP Protocol approach to get the file from ftp server and then from OSB the file content to a JMS Queue.
Then a JMSAdapter will consume the message from the queue and it will initiate the same requester component.
The new approach was working fine for some payloads. But for some payloads it was throwing "TF_GENERAL_TRANSLATION_FAILURE,Please correct the NXSD schema". The same payload were working fine with the initial approach.
I compared the DAT file content and the message posted in the queue by OSB. The message size in the queue were slightly higher than the original DAT file. This lead me to think that OSB file transfer might be adding some characters like carriage return or line feed, which might be the cause of this increase size of the message.
In the OSB proxy service, the transfer mode was ASCII, I changed this to Binary. Retested, the original file size and the message size matched . Also the JMSAdapter started processing the messages without any errors.
No comments:
Post a Comment