In some of our BizTalk 2009 development environments, when attempting to process a HIPPA X12 file, 4010 270 file type, any element defined in the schema to be type X12_AN is throwing an "Invalid character in data element" error; e.g. NM103__InformationReceiverLastOrOrganizationName. The invalid character that it is complaining about is the letter "U". It's only the capital letter "U" and not a lowercase "u".
This error only presents in our development environments that exist in Citrix VDIs running Windows Server 2003 R2 Enterprise X64 Edition. The instance of BizTalk Server 2009 installed on the VDIs has been updated with the most recent hotfix.
So far, I tried everything I can think of from converting the input file encoding, to retyping the entire file manually. I recompiled and deployed both the schemas and maps. I even enabling and disabling EDI validation at the party level. Nothing seems to be working.
Has anyone seen this type of error before? Is there any way to modify or override the character set that is used for element validation in BizTalk?
Any information that you can offer would be greatly appreciated!
It looks like you have a couple of different issues here. I can't speak to the differences (implied by your post) between your Dev and Production environments.
As to the rest:
Yes, you can modify the X12 Validation. I don't have it in front of me but I believe you can just turn it off completely (if that's what you want). Otherwise, you have to (essentially) create a custom 270 schema that allows the character (you can even do this to make elements that would otherwise be invalid valid), and then use that custom schema for any partner that hits that validation rule.
What I've always done is to modify the incoming file: send it through a regex that will change that character in that field to a lowercase 'u'. As long as you're keeping a copy of the original (unedited) message, and you're not changing any actual data values, you won't run into any HIPAA regs.
I would also encourage you to go through the offending files with the proverbial fine-toothed comb. Usually (not always) there is something else that is actually causing the error, but it only manifests noticeably in circumstance X (in your case, a capital U in your NM103).
Revisiting this issue after a couple of weeks I found the fix for this issue to be much simpler than expected.
We work in the the healthcare industry and are currently supporting HIPAA 4010 applications while actively upgrading those applications in our development environment to meet the HIPAA 5010 requirements. As such, this issue was caused in BizTalk when the party property "Use ISA11 as repetition separator" was CHECKED within the configuration of a party used only for 4010 development. Since the default ISA11 value for 4010 is "U", BizTalk reported that character as invalid everywhere it was found.
I hope this saves someone else a lot of headaches. It's fun to be reminded every now and then that you should always check the obvious, simple solutions first, even if you KNOW they're not the issue!
Related
today we received info from one of our customer about this malware detection:
Gen:Variant.Adware.Kazy.795337
It's only inside the qwebp.dll file attached to our project by qtdeploy process.
We're building 32-bit Qt (5.13.2.0) from the source and the same issue is reported on the same DLL no matter where it was built. We're using the latest VS 2019.
https://www.virustotal.com/gui/file/9f09c05803ad4ffcd99454c420a840e17549ee711690fb1f11fd1b59bccc3b23/detection
https://www.virustotal.com/gui/file/80c4c747d781a27c72de71c0900ccc045aefd2b4e4f17c949aaeeb3d0b7973b1/detection
When I scanned the older version (5.13.0.0) everything is ok:
Previous versions seem to be clean:
https://www.virustotal.com/gui/file/b7b7cacaef0e76439ef8c367c401524e93dfa00c9ca67a20290e829fec325a5a/detection
Also, any debug build and 64-bit builds are clean too.
Any idea what can cause this? Can anyone else please try to scan this file?
Thanks
TL;DR: It is probably nothing, but notify Qt anyway (and check your own systems).
Are you using the prebuilt Qt binaries or are you compiling the sources yourself?
If you are using the official prebuilt binaries, I'd of course expect that the Qt Devteam scans them and verifies that they don't accidently spread malware, but there is always the miniscule chance of something slipping through.
Same goes for the sources - while their review process should be thorough enough to avoid malicious code being slipped in, there is still the outside chance of either a key account being compromised or (even more unlikely) bad code being added slice-by-slice over a longer time period to avoid detection (along the lines of the underhanded C contest). Still, either case seems to be rather unlikely.
Bottom line: while this does sound like (and probably is) a false positive, you still may want to raise an issue with Qt e.g. on the their Bugtracking site or directly with Qt support (if you have a commercial license) to be sure. Also (if you didn't do that already) verify that the problem is not on your end, e.g. that your computers are clean and that you don't just randomly catch/detect your infection in that file.
Update:
A ticket concerning this issue was opened (I assume by Ludek Vodicka) on Qt bugtracker. Opened on Nov 19th and categorized as P1: Critical, but unfortunately no indication that it is actually being worked on (at least of Dec 18th).
Background: we needed a more mature canonical message format for our ESB solutions than our home grown canonical that is outdated. I researched a bit and found OAGIS looked very promising and I liked the document model. I downloaded version 10.1 and picked out the BOD's I would first implement. I am working specifically with ProcessSalesOrder in BizTalk 2010 mapping a fairly simple web service schema to the ProcessSalesOrder BOD. I got the map where I think I like it but it creates a lot of bloated tags I don't need or want and map execution (at least in my virtual server workstation environment) takes forever to execute. As the map attached to the WCF call in BizTalk Receive location it will time out.
OAGIS 10.1 Download page
Question is has anyone tried to optimize the schemas for OAGIS 10.1?
I can only find BizTalk references with much older versions where the schema was broken into nouns and components - this isn't the case for 10.1 there is only one LARGE schema for ProcessSalesOrder. I have set my root reference properly.
Can the BOD be edited to remove sections that aren't being used without a ton of dev time?
Any thoughts or suggestions are desperately needed before I scratch the project and go to modifying our crappy canonical for expediency sake.
If you leave unneeded fields unmapped. the map should excute pretty fast. To test just the map performance, can you try to do test map and see how it performs?
Another option can be stripping of unwanted data in Recieve pipeline before it hits the map
I have inherited a web application and when trying when trying to put it on the same server on a different IP and IIS site I get a page full of stuff like this in all browsers. (not sure how the server here will output this but it is basically the same as if you were to open a binary in a text editor or bad character encoding).
���r#ə6��{��Ί��&��6�K�MЀh��"Pd�AP;�RN�K9�r��<ϛ���!��GZ�4��J�z�����R'���i�j�uZLe�V`=��&��T!e]rGVx#d��N���V���w>���pc�hw��B>��^�|L�]��3�~-��g��n��n�i�>Z� �ٲ������z_�����U�,i��2��\�+���F��FB���m��r�7�v��7�}�U�N�o�G�K�o?�w凲��و�����ߓ�x!���_?��V��v�/V��olt˭Z����� >M�kwkh&��j�C3�|̓��=�8��jJ����Uo�~��T7�\w�eW�������u*���f0c��}�.����]o������7���|�;}�&O���N�)[ys��+Q��o�T�~����F����c���έm��.�Q�ů�2#P���i�ˠ�~g��u�<| $ۭ>zZ/e��'�;R�'���v�ˠ�����
I've copied the same build and all its files to the site running under another IP, used the <globalization> web.config tag and set all encoding to UTF-8 and for the hell of it I even tried setting it to ASCII.
The application, although written for users in only US cities does make use of localization resource files for Russian and Romanian since it had been outsourced to developers there. I guess they did so to make things easier on developers who may have been less fluent in english, who knows.
Besides using the exact same copy running in production and changing web.config encoding settings I have found it runs fine on my IIS 7/Windows 7 workstation, tried throwing a uncompiled copy up there with .cs files and all, wrote a simple ASPX page that performed a response.write (which came out fine).
So as you can see I am pretty much at a roadblock and decided to ask the fine professional community we have here. Any input you may have on this matter would be highly appreciated.
I fixed it by exporting the IIS settings for the production system that it worked fine on and created a new IIS site from that file. Sadly I could see no difference between the 2 before I did this but if you run into this issue then here is another thing you can add to your list of troubleshooting tasks.
It's probably a long shot based on your description, but from a little Internet digging, a couple of forum posters have mentioned bad NICs corrupting packets. You did say you had the app on a different IP on the server -- does your server have more than 1 NIC?
Wrong answer was autoselected by the stupid bounty system.
I'm using front page extensions to interact with SharePoint Services 3.0 as described here.
In most samples I have seen the client simply looks for particular English strings in the result and uses that to determine if an error has occurred. However, I am writing an application which may be widely deployed and put on non-English language SharePoint servers so I would like to use the returned error codes instead.
Unfortunately, the documentation for the error codes is very poorly defined. It contains such gems as:
Although many RPC protocol methods have unique error messages, most rely on a standard error message format to relay information if a method fails to complete properly.
Hrm, what would be this "standard error message format"...
and
The status is the error code from
FrontPage Server Extensions for the
condition encountered. osstatus is the
error code from the operating system..
also sadly entertaining:
In general, the codes are integer
values and the messages are text
strings that summarize the error.
but nowhere is a table which describes the possible content of these errors to be found.
It seems likely to me that the OS error code would be an HRESULT but I have no idea what to look for in terms of potential sources for SharePoint error codes. My only clue is that status=589826 seems to indicate that a file already exists.
Wrong answer was autoselected by the stupid bounty system.
I guess it refers to this list of "standard" system error codes:
http://msdn.microsoft.com/en-us/library/ms681381(VS.85).aspx
What setting might be missing or misapplied that would cause the same code that works on an IIS 6.0 server to fail on an IIS 5.1 server?
I've inherited this large Classic ASP application. It "caches" a series of files with funcitons in them using the ExecuteGlobal command. On both server, the command executes without error. However, when the application later tries to reference the functions that were 'cached', IIS 6.0 seems to work just fine while IIS 5.1 acts as though those functions never existed and I get errors to that effect.
The 5.1 system is for testing purposes on an XP Pro box. The 6.0 is our production system on Windows 2003.
It's taken a long time to isolate the problem (identical code failing in test but working in production) to this code. Setting up another server isn't an option unfortunately (budget restraints - no money to pay the support people or to rent space where all servers must be physically located - military installation).
What directions have I missed looking into?
Are "caching" and "using the functions that were cached" happens while processing the same HTTP request?
If the answer is "yes", then I've got no ideas, and I sincerelly hope someone else will answer your question.
If the answer is "no", then I'm pretty sure your problem is you "cache" the function into a different VBScript execution context.
Try (on the test server, of course :-) adding the following 2 lines in a file that defines the functions:
Dim g_FunctionsLoadedOK
g_FunctionsLoadedOK = "OK"
and the following line just before you're using the function:
if( Eval( "VarType(g_FunctionsLoadedOK)" ) <> vbString then
' Then you're sure there's no 'g_FunctionsLoadedOK' string variable defined in this VBScript execution context,
' so maybe you should reload the cached functions, or do something else..
end if
P.S. Unless the system you're dealing with is really large, why not use <!-- #include file="MyFile.inc" --> instead of that "ExecuteGlobal" approach?
Can you post the code for the fake ExecuteGlobal stuff, it might be possible to refactor it to get it to do what you want using Includes so that you don't have to break anything. Failing that a bit of find and replace might be needed :)