Well, I have to say it is kind of funny when I meet this situation:
I am inbounding HIPPA 837 files and I am suppose to create 999 ACK files once received the 837 file. BizTalk will generate the 999 message if I setup the trading partner agreement to do so. And it works fine so far.
Today, I received a 837 file with some structure error: there are some leading space character in an element. Then the 999 was created, but when my send port subscribe this 999 message try to save it as a file, I got an validation error complains the 999 message itself is invalid cause its element have leading space characters.....
Error: 3 (Field level error)
SegmentID: IK4
Position in TS: 18
Data Element ID: IK44
Position in Segment: 4
Data Value:
6: Leading or trailing space found
It looks for me like a catch 22: your 999 files are suppose to report structure error of the inbound file,it will include the wrong element value as part of the report (in my case, it's in IK4 segment) , but the wrong element value itself make the 999 file invalid too.
I just want to know if anyone have meet the same situation? And what's your suggestion on this issue?
I have not seen this, and really, I'm a bit surprised it hasn't come up before, if it's a real catch-22 :)
Try this, in the You->Them tab of the Agreement, set the Default row in the Validation section to have Leading and trailing spaces = Allowed.
You may have to explicitly set all other tx to Not Allowed since the 999 is not on the Transaction Type list.
I would try #Johns-305's suggestion, but I know I've had issues with using the allow leading/trailing spaces before in the agreement (some fields just seem to blow up on this for me even with it on).
I would try capturing the 999 message before it gets to the EDI send and using normalize-space() (in XSLT) or .Trim() (in C#) on the node(s) in question. You can do this by creating a send port that filters on the 999 BTS.MessageType.
This may not fully satisfy your trading partner's expectations though, because the segment might be valid without a space (leading to confusion about why a perhaps otherwise valid segment was rejected).
You also might take this up with Microsoft, although it might be a limitation of using XML (where leading whitespace may be treated as insignificant) to represent EDI (where leading whitespace is bad news).
Related
I wanted to verify a text in a webpage exist for 2 times or ‘n’ times. I have used “Page Should Contain” keyword but it says “Pass” when it identifies single occurrence. I don’t want to verify using locator.
Ex: I want to verify the text "Success" is available in a current webpage for 3 times using robot framework
Any inputs/suggesstions would be helpful.
Too bad you don't want to use a locator, as robotframework has a keyword just for that:
Xpath Should Match X Times //*[contains(., "Success")] 2
The caveat is the locator should not be prepended with xpath= - just straight expression.
The library keyword Page Should Contain does pretty much exactly that, by the way.
And if you want to find how many times the string is present in the page - easy:
${count}= Get Matching Xpath Count //*[contains(., "Success")]
And then do any kind of checks on the result, e.g.
Should Be Equal ${count} 2
I thought the problem of not using locator sounds fun (the rationale behind the requirement still unclear, yet), so another solution - look in the source yourself:
${source}= Page Source # you have the whole html of the page here
${matches}= Get Regexp Matches ${source} >.*\b(Success)\b.*<
${count}= Get Length ${matches}
The first one gets the source, the second gets all non-overlapping (separate) occurrences of the target string, when it is (hopefully) inside a tag. The third line returns the count.
Disclaimer - please don't actually do that, unless you're 100% sure of the source and the structure. Use a locator.
I am using HttpsURLConnection call to get the response from HTTP servlet with message and error code. Following is some code snippet from my code:-
connection = (HttpsURLConnection) url.openConnection();
connection.setDoInput(true);
connection.setDoOutput(true);
connection.setUseCaches(false);
// Headers
connection.setRequestMethod("POST");
connection.setRequestProperty("Content-type", "text/xml");
connection.setRequestProperty("Accept", "text/plain");
connection.setRequestProperty("Connection", "Keep-Alive");
connection.setRequestProperty("Authorization", authorization);
connection.connect();
From HTTPServlet side, i am setting statuscode and description:-
response.setStatus(code);
response.getWriter().write(returnDescription);
All the above code is existing code and it is working fine except. It should return status code as response code. But few codes are not working like 1001,1002 or 1003. i.e if i set response.setStatus(1001) it returns -1 as responseCode() at client side with "java.io.IOException: Invalid Http response". For any other integer value like 1101,1102, 1232 etc it works fine. I debugged the code and found servlet is setting correct values but client is not able to parse response. And as you change status code with some other numeric value, it get started working correctly! I am getting same behavior in HTTP as well as with HTTPS.
It seems like these non working codes are predefined codes with specific objective and can not be used as status code but i didnt find anything on web. Did anyone experienced the same and what could be the reason.
Thanks in advance! :)
Short version: OpenJDK and others have a parseHttpHeader method that parses exactly three chars of the HTTP status code number, and anything starting with the string '100' is treated as an HTTP continue. The non-continued nature of this servlet conversation confused the client, so it couldn't open the output stream and gave up.
WAAAAY long version:
This one kinda bugged me, because only 100-599 (ish, actually fewer than this) status codes should really work at all. RFC2616 says codes must be three digits and (paraphrasing) you need necessarily only understand the class of the first digit (to allow for extensions).
OpenJDK 6's HttpURLConnection implementation was the first I checked (since you didn't specify) and the code basically does:
grab the first line of the response.
look for HTTP/1. (Doesn't care about 0.9 apparently, and ignores the second digit).
look for everything at the end for the text reason.
try to parse whatever int is in the middle.
GNU Classpath does pretty much the same.
Notably, OpenJDK doesn't particularly vet that against the RFC rules. You could put a billion in there and it would be more-or-less OK with that (at least as far as getResponseCode() cares, anyway...it looks like getInputStream() will barf on any code >=400 in the concrete implementation in sun.net.www.protocol...).
In any case, that didn't answer why you were seeing this oddball behavior for only 100x. OpenJDK looks like it should have thrown IOException of the form "Server returned HTTP 1234...
...or so I thought. HttpURLConnection is abstract, and so a concrete implementation must override at least the abstract methods. Well, the concrete implementation of HttpURLConnection, the abstract's version of getResponseCode() is sorta ignored. Kinda. This implementation calls sun.net.www.http.HttpClient's parseHTTP as part of opening the input stream, which parses out the HTTP/1. and then exactly THREE characters of the code (and then does convoluted things to massage the input stream to having all that stuff retroactively shoved back in in something called an HttpCapture. Yuck.). And if that three chars happens to come out to 100, then the client thinks it has to continue the conversation to get a working InputStream.
Since your servlet is actually done with the transaction already and it's not continuing, the client is getting confused about WTF your servlet is doing and is therefore returning an error (as it should per RFC).
So mystery solved I think. You could put pretty much anything beginning with "100" and get the same behavior (even "100xyz" if your servlet API lets you).
(Android, btw, also does this three-char parse.)
This all technically violates RFC (though, honestly, it's kind of a silly bug). Strictly speaking, only 2xx codes should be treated as totally OK to pass unmolested, but probably you could use a "000" status and pass OK (again, assuming your API lets you put an arbitrary string in there).
Hope that answers your question!
When I was inbounding trading partner's X12 file using biztalk. I am required to store the ISA segment of the file in a db table.
I am using the promoted property EDI.ISA_Segment to get the ISA string.
Recently, I noticed for one trading partner. There're extra chars found in the ISA segment:
The ISA segment shall look like this:
ISA*00* *00* *ZZ*######## *ZZ*##### *150105*0606*^*00501*000000936*1*P*>~
But the ISA_segment using the promoted property was:
ISA*00* *00* *ZZ*######## *ZZ*##### *150105*0606*^*00501*000000936*1*P*>~
G
There's extra < LF >+G in the ISA segment.
The trading partner do send the X12 file with segment suffix and it was also configed in the BizTalk Agreement correctly.
It looks BizTalk takes 2 extra chars to the ISA_segment after reached the "~", I am wondering if this is a bug or it is caused some mis-configuation?
You need to look at the original EDI using a good text editor such as Notepad++ so you can see exactly what those characters are.
The X12 spec allows the use of CR and/or LF as part of the Segment Terminator so it might be a side effect of changing encodings from EDI to the database.
I've tried to find the answer in other questions, and none of the "standard" answers are working, so I'm hoping someone can either point me to where this has already been answered, or can tell me how to do this.
I have a large file with multiple documents within it. For a sample, assume something like this
DOCUMENT_IDENTIFIER 123400000000000000000123457 OTHER STUFF HERE
LINE WITH STUFF HERE
LINE WITH STUFF HERE
DOCUMENT_IDENTIFIER 123500000000000000000127456 OTHER STUFF HERE
LINE WITH STUFF HERE
LINE WITH STUFF HERE
Now, I'll need to preserve everything in the DOCUMENT_IDENTIFIER Line starting with the first 0 through the 123 (or 127 in the second Document) That header line, plus the all the LINE WITH STUFF HERE lines below it should make up one Document, and a new document should start at the second DOCUMENT_IDENTIFIER line.
When I attempt to use the standard Debatching techniques, the pipeline fails: either it just fails completely (when, for instance, I try to define a header and body schemas for the pipeline) or it never starts the second document (if I try just a body schema).
I'm certain this is something fairly simple, but I'm completely missing how to get it done. Any suggestions/direction would be welcome.
If it matters, I'm stuck on BT2006 R2, at current.
What does your Body Schema look like? I would start getting that right and make sure that you have something that will create xml with separate records of all the "DOCUMENT_IDENTIFIER 1234" records.
I would use the "DOCUMENT_IDENTIFIER "1234 bit as the Tag Identifier, and then I would set the Tag Offset to 4, to avoid the first 4 characters.
You should have a
RecordForDocumentIdentifiers (Root of your Schema) Group Maxoccurs=*
RecordForDocumentIdentifier (Set the Tag Identifier here)
Fields for the columns you want to parse
RecordForOtherLines Group Maxoccurs=*
RecordForOtherLine Maxoccurs=* or whatever your rules are.
Fields for the columns of other lines
When that seems to parse your example okay, and generate the XML you want, I would start creating my header and body schemas from that. I know it is 2 steps, but it takes some of the guesswork out of it.
I guess the Header schema would be picked from the RecordDocumentIdentifier and the body would be RecordForOtherLines (The outer record for that).
I hope that helps. If not, post your actual file and schema and let us take a look at it.
I am trying to create a file format for myself, so i was forming the header for my file. To write a known length string into a ByteArray, which method should i use, writeUTF() or writeUTFBytes().
From the Flex 3 language ref, it tells me that writeUTF() prepends the length of the string and throws a RangeError whereas writeUTFBytes() does not.
Any suggessions would be appreciated.
The only difference between the two is that writeUTFBytes() doesn't prepend the message with the length of the string (The RangeError is because 65535 is the highest number you can store in 16 bits)
Where you'd use one over the other depends on what you're doing. For example, I use writeUTFBytes() when copying a XML object over to be compressed. In this case, I don't care about the length of the string, and it'd introduce something extra to the code.
writeUTF() can be useful if you're writing a streaming/network server, where as you prefix the message length to the message, you know how many bytes to stream on the other end before the end of the message. e.g., I have 200 bytes worth of message. I read the length (16-bit integer), which tells me the message is 100 bytes. I read in 100 bytes and I know it's a complete message. Everything after is another message. If the message length said the message was 300 bytes, then I'd know I'd have to wait a bit before I have the full message.
I think i have found the solution myself. It came to me when i was coding to read back the data. The corresponding functions to read from a bytearray readUTF() and readUTFBytes(length:uint) requires the length to be passed to it.
So if you know the length of the string that you are gonna write, you can use writeUTFBytes() and use readUTFBytes() with that size. Else you can use readUTF(), letting as3 write the size of the data which can be read back without any need to know the length of the string while using readUTF().
Hope this might be useful to some one as well.