1. Wmethods is throwing a ‘filename not found at writeToFile’.
2. It will generate a 997 with control characters in it
3. It does not process the file/load the file into the database

When I redrop the file for processing it runs just fine. Several trading partners use the same flow service it appears they are bumping into one another. I am currently using 6.1

C hill

My apologies… I looked for a previous post and could not find one. Then I started searching every thing and found a post that explains this is an issue with Maximum Number of Invocation Threads. I have changed this to serialize and assume it will solve my problem.

The number of threads did not fix my problem. When the file is dropped/polled it errors with a filename not found. What is really strange is I can redrop the same file and it works every time.

any ideas?

C hill

Can you describe the specifics of the “writeToFile”? What is the filename? Is it hard-coded? Does it use a timestamp retrieved from the system in part of the name? How does your writeToFile function? Does it create the file or does it expect it to already exist?

I did include the java writeToFile… however I do not think this is the problem because
Our trading partner is sending hex 205 (a non printable character) as the delimiter
Web Methods doesn’t seem to handle it.
This file is ftp’d over from another system.
The hex 205 is replaced with a carriage return and a copy is put in our file system.
that is why it always works when I redrop the file.

Is there some way for webMethods to handle the hex 205

Thanks in advance
C Hill
===========writeToFile==============================
IDataCursor pipelineCursor = null;

try
{
pipelineCursor = pipeline.getCursor();
String directory = IDataUtil.getString( pipelineCursor, “directory” );
String filename = IDataUtil.getString( pipelineCursor, “filename” );
String content = IDataUtil.getString( pipelineCursor, “content” );

if(directory == null)
{
throw new ServiceException("Input parameter \'directory\' not found");
}

if(filename == null)
{
throw new ServiceException("Input parameter \'filename\' not found");
}

if(content == null)
{
throw new ServiceException("Input parameter \'content\' not found");
}

String sep = System.getProperty("file.separator");

BufferedWriter out = new BufferedWriter(new FileWriter(directory + sep + filename));
out.write(content);
out.close();

}
catch(IOException ioex)
{
throw new ServiceException(ioex.toString());
}
catch(Exception e)
{
throw new ServiceException(e.toString());
}
finally
{
pipelineCursor.destroy();
}

Can you be a bit more explicit on “Web Methods doesn’t seem to handle it?” What error are you seeing? My guess is that it is your code, not “Web Methods” that is mishandling the hex char.

The use of BufferedWriter/FileWriter seems suspect. First, they are character-oriented which you probably don’t need to use just to write some bytes. Second, they use the default encoding of the host environment, which may be contributing to the problem. Chars above 128 are often represented in mutiples bytes, depending on the encoding used when converting from char/string to bytes (like what BufferedWriter/FileWriter do).

Use classes other than BufferedWriter/FileWriter which will allow you to specify the encoding. ISO-8859-1 is likely the encoding that should be used instead of the default UTF-8.

Can you be a bit more explicit on “Web Methods doesn’t seem to handle it?”

Each partner that sends us an 810 has there own processing rule that executes the same service EDI810_v4010.
All of these files are processed with out fail.
Except the partner that sends Hex 205 as the record delimiter.
when I drop the file w/o Hex 205 it works… as it should

writeToFile was not authored by me… Is there a webMethods service that could be used instead of this homemade version?

You say ‘Use classes other than BufferedWriter/FileWriter which will allow you to specify the encoding’. There is power in each word you write but I am not getting this.

I understand why you are saying writeToFile is suspect. ‘filename’ not found at RmCommon.File.writeToFile is the error I get every day’

if u dont want to use character straems - BufferedWriter/FileWriter, then u can try FileOutputStream which is a byte stream. the code below is for append to file, but can be modified for writeFile.

IDataHashCursor pipelineCursor = pipeline.getHashCursor();
pipelineCursor.first( “fileName” );
String fileName = (String) pipelineCursor.getValue();
pipelineCursor.first( “dataToWrite” );
String dataToWrite = (String) pipelineCursor.getValue();
pipelineCursor.destroy();
try
{
FileOutputStream fout = new FileOutputStream( fileName, true ) ;
synchronized (fout)
{
fout.write( dataToWrite.getBytes() ) ;
fout.flush() ;
fout.close() ;
}
}
catch ( IOException e ) {
}

I appreciate the posts. I have disabled the writeToFile and it appears to be working. I will see what happens tomorrow when the file is brought in with the hex 205 characters if webMethods handles it I will be in good shape.

Sincerely

CHill

“Except the partner that sends Hex 205 as the record delimiter.
when I drop the file w/o Hex 205 it works… as it should”

What…is…the…error?

Well… no error this morning but the data did not load.

I am guessing here… but it appears that my database rejects the inserts because either --no data loaded via the webMethods flow-- or --the data loaded but is NOT readable-- I checked with the DBAdmin and they have no error on thier side. webMethods did not throw an error.

I will say this TN has processed this file. I will also say that my 997 is garbage and will not be passed on via the VAN due to the hex 205 characters inbedded in the 997 document.

My delimeters for the 997 are
\u000a for record

•        for field
  

“will not be passed on via the VAN due to the hex 205 characters inbedded in the 997 document.”

Are you sure? Delimiters are allowed to be any byte value, from 0 to 255.

Can you be more precise about the 997 issue? Are the delimiters appearing as multiple bytes or does the single char just look “funny?”

The typical approach on 997 generation is to use the delimiters from the source file that the 997 is being created for. So if the source file is using decimal 205 (0xcd) for a delimiter, that’s what the 997 will use. I haven’t looked in the docs so I’m not sure if that behavior can be overridden or not. But the 997 probably isn’t your main issue–its the original transaction sets.

Where exactly in your process is it failing? Are you using TN? If so, do you see the transaction sets in the transaction analysis (assuming your split level is set to transaction set)? Please be more specific about the issues/errors you see. Phrases like “it’s garbage” or “webMethods can’t handle it” aren’t helpful (and are making possibly erroneous assumptions about where the fault lies).

Can you be more precise about the 997 issue?
When I look at the 997 in TN I see a square at the end of each segment. so… the single character just looks funny.

Where exactly in your process is it failing?
The load into the database fails the insert using jdbc Services. I have …no… webMethods error. I can not find a dbase error.

Are you using TN?
I am using TN. I see the X12Envelope, X12 Group, and X12 4010 810 transactions. They call the proper services and act as if all is well. I can not find ANY of the transactions in my database tables but…TN generates the 997 and it sits at the VAN as a file that can not be passed on. They (the VAN) tells me there are extra characters in the file and it can not be processed.

My activity log in TN reads
Inserted to EDI Tracking entries
Routin rule RmInbound810_invoicesV4010_Vict
Document persisted
Service invoke RmInEDI810_v4010.Control.process
Status changed
Processing complete

I wish I could be more specific but I really don’t have a lot of clues here. The best clue I had was filename not found and now that it is resolved I am just stuck basically with no clues.

In HEX notiation that lit square is 0d0d0a (you can check this also in ultraeditor)

HTH,
RMG

efbf

in hex

More specifically
ST9970001\357\277\275AK1IN1529\357\277\275AK9A8
88\357\277\275SE40001\357\277\275GE11529\357\277\275IEA1000001529\357\27
7\275

that is the data being sent to the VAN less the ISA and GS

That’s all great information.

Given that TN is successfully processing the interchange and deenveloping it to create the group and transaction sets means that the delimiters (the “hex 205” or whatever value it really is) is just fine.

I still suspect this is an encoding issue. The fix may be to change the EDI properties. Click the “EDI…” link in Administrator then click the “Configure Properties” link and finally the “Edit Properties Settings” link. Edit the keys and setting to the following:

EDIencoding=ISO-8859-1

To chase the DB insert error, use savePipeline and restorePipeline so you can step through the service to verify the service logic and the values that are supposed to be inserted to the DB.

I am going to take your suggestions and I appreciate the time you’ve all spent trying to get me thru this. I am also going to ask my trading partner to change their delimiter.

It’s evil

Thanks again.

C Hill