Loosing Pipeline during EDI File Polling

Hi,

I have created a file Polling service which polls for an EDI file. The content type is specified as application/EDIstream and the variable in the input/output tab of the processing service is called edidata. This is similar to the way file polling for Flat file is specified the difference being content-type application/wmflatfile and variable name being ffdata. I have specified the package name as the package containing the processing service. When i put the file in the monitoring directory the tracePipeline in the processing service does not show the edidata variable in the pipeline populated. After reading through the previous threads for this topic, i changed the package name to WmEDI but i am still getting the same result. Please let me know if anybody experienced the same problem and whether u could find any resolution for the same.

Thanks
Gaurav

What is the data type of your edidata input variable? This is, I believe, an input stream so your variable should be an ‘object’. I just checked this with both tracePipeline and savePipelineToFile and it seemed to work ok. Thanks,

Tim

It looks like it’s actually a byte array rather than a stream, but using the object data type will still work. Thanks,

Tim

Use contentStream(object datatype)in the service input instead of edidata for file polling EDI documents

It should work.

HTH,
RMG

put the savePipeline after you convert the streamToString otherwise the contents still won’t be in the pipeline

Chris is correct, but I do think the object-type variable does have to be named ‘edidata’ if the port specifies application/EDIstream as the content type. Thanks,

Tim

Gaurav,

Once you set the service input use streamTobytes and bytesToString flows and savepipeline,you should see the edi string in the pipeline.

HTH,
RMG

Thanks to all the people who have responded to this thread,

Note: Apologize for the long text, but i have tried to explain the error in detail.

The error is still not resolved. Rather i am seeing some strange WM behaviour after trying to implement some of the suggestions given.

Option1:- The edidata is an object datatype. I do a tracePipeline as the first step in the service. I can see the edidata in the server log after running the FTP service. It is shown as ‘java.io.BufferedInputStream@3faef5’. The next step after streamToBytes is bytestoString and after that i have wm.b2b.edi:convertToValues which returns an error saying “Cannot have null node definition”. The input to convertToValues has a string mapping to edidata object variable and i have also specified the complete namespace of the EDI schema for the EDIffschema variable. The EDI string is visible in the server log.

To debug the service, I do a savePipelineToFile, run the FilePolling service. After this i disable the savePipelineToFile and enable the restorePipelineFromFile. After stepping through i dont see the edidata in the results Panel which is very surprising, (the filename is same in both the services).
So instead of using savePipelineToFile i use just the savePipeline service giving some $name value. Run FilePolling, disable service and enable restorePipeline service and now after stepping thru i see the edidata variable populated as ‘java.io.BufferedInputStream’. Notice the missing address info in edidata. So the step streamToBytes fails saying ClassCastException, this is because it is expecting a Stream but restorePipeline returns a string edidata instead of an object edidata.

This looks to me like a very serious WM bug, i will be really grateful if somebody can respond to this or can log a service request with webMethods.

Option2:- RMG had suggested to use contentStream as the input variable, but that doesnt work. I dont see this variable getting populated in the pipeline.

Please let me know if you are seeing the same error at your end and if you have a resolution to the same.

Thanks,
Gaurav

Gaurav,

I followed the procedure you describe in Option 1 exactly and it worked OK. I did a quick search on Advantage for the error you were getting and found two users reporting a similar problem. In both cases webMethods said that the problem was solved by increasing memory on the IS and restarting. I assume they meant physical memory on the machine, but they weren’t specific.

One thing you need to be careful with is doing anything with the stream before your main processing. You mention an FTP service after doing a tracePipeline, so I’m not sure what may be happening in your Flow. Similarly, your debugging with save and restore pipeline will not work with a stream. You can do a search in this forum for workaround for this.

If none of this helps, try contacting wM support about it. HTH,

Tim

contentStream also works. It’s a string type.
You can then do a streamToString
After that you can use the save/restore pipelines for debugging.
We do this all the time.
I think you need to start over and go slowly. You have been trying a number of things and may have gotten them crossed. Been there myself so I know.

Gaurav,

Use pub.flow:getTransportInfo service and under this use savepipeline for debugging and see what is coming in the pipeline,this service will give you the enough information.

HTH,
RMG

Hello,

Yemi Bedu

Hello Everyone,

Just want to let you know that i resolved the problem. One thing is for sure, EDI is not as straight forward as FlatFile but its more fun to work with. Have a look at the EDISamples package and look at the service Tutorial.EDItoXML:processEDI850_4010. Although i was using EDI830 with transaction set version 3020, this service was very helpful in making me understand the nuances of EDI. ConvertToValues cannot be used directly on the EDI string read from the file. This is where i was getting the error.

The bug with restorePipeline still remains. If Mark or somebody see the same error in their own environments please forward the same to Advantage.

Mark, another qustion i have is : Is it possible for wmusers to have access to Advantage to raise Service Requests or can some of the senior members do the same if they see that the bug is really genuine. I believe webMethods will appreciate a “free” QA from its users.

Thanks
Gaurav