I have a script sending data to a RESTful API. I'm troubleshooting an intermittent error and can't find any problems in syntax. However, looking at the return request reveals some funny business.
6914ðnicity=Hispanic%2FLatino
&discipline=director
&yearsTeaching=
&facultyType=Not+Applicable
°ree=Doctorate
Notice the first and last line start strangely. The first line should be &Ethnicity and the second line should be &Degree. In the script they are labeled simply "Ethnicity" and "Degree". Pretty straightforward so I have no idea how or why these characters are being returned. The other thing is that I'm not confident that this is related to the error I'm after since the exception apparently occurs at a separate line of code. The thing that makes me think it's related is that the API that's receiving the data DOES NOT accept Unicode characters such as ð and °.
Turns out this call isn't originating from my server but rather a web service I don't control. Apparently I confused some output logs. Thanks~~
Related
I'll answer this myself, just adding here for documentation if anyone else encounters it.
We are using dynamic WCF-SQL port. I had it working in one test orchestration, but when I copied code to the real orchestration, it gave the error:
Wcf.Action Must be a message part property of message part ...
and similar for each of the lines below (in a Message Assignment shape in a BizTalk orchestration).
The issue was just to remove the
.Messagepart
Example:
SQLRequestMessage(WCF.Action) = etc...
The built-in WCF related promoted fields are on the message, not the parts of the message.
My test orchestration didn't use multipart message types, but in the real orchestration that I'm modified, our standard is to use them.
Once I saw the issue, it was obvious, but was knocking my head to figure it out for a while.
I'm currently working on some asynchronous calls.
I'm currrently experiencing an issue where sometimes calls will just do nothing and don't throw an error or something.
It happens like once, twice in like 20-30 calls.
This is what I currently have.
DEFINE VARIABLE hAppServer AS HANDLE NO-UNDO.
hAppServer = getServersHandle(AppSrvConnectionEnum:apsvWorkFlow).
RUN ServiceInterface/StartAsync.p ON SERVER hAppServer ASYNCHRONOUS EVENT-PROCEDURE "ProcedureComplete" IN hCallBack (INPUT ipiWorkflowId).
I'm running it on Progress Version 11.6.4. I also have put messages on the ServiceInterface/StartAsync.p procedure, and when the calls do not get through no messages are written to the appserver ofcourse.
Does anyone have an idea?
Off the top of my head, you might have a dead reference to the server. Just for debugging, try to message valid-handle(hAppServer) and hAppServer itself, since I suspect at some point it's returning an invalid reference (though I imagine the enum is not changed during runtime). Nothing wrong in the code you posted, at first look.
This is the 1st time I meet this.
Normally when we received an inbound X12 file. A 999 will always be generated (by configuration in BizTalk) and in case of interchange level error occurs, a TA1 will be created.
But today I got a X12 file with some formatting errors, the error popup in BizTalk is :
Delimiters are not unique, field and component seperator are the same.
The sequence number of the suspended message is 1.
I am expecting to have a 999 or TA1 generated to reject the inbound file. but none of these 2 files created.
My question:
What file shall I expect to created for this kind of error? 999 or
TA1?
Is this a bug or normal behavior for BizTalk?
If this is normal, what is the best mechanism to catch this error and
response back to trading partner.
You should definitely not expect a 999 (which would be transaction set specific), because this error prevents BizTalk from parsing the transaction set at all - it doesn't have a reliable way to determine what kind of transaction it is.
A TA1 could be appropriate, but this seems like a grey area - might be worth contacting Microsoft support about. The documentation indicates that an invalid ISA should result in a negative TA1, but the error codes for TA1 don't list this particular scenario as one that's support (or at all).
A possible work around would be capturing this kind of message, generating a TA1 for it, and routing it back to the TP. However, having non-unique delimiters may make it impossible to determine the TP from the message itself, even though you might be able to determine it from context (but maybe not if multiple trading partners use the same ports/locations). My guess is that's why BizTalk isn't handling it properly out of the box. To be honest, unless this happens fairly frequently it'd probably be easier/more realible to deal with it on an exception basis with human intervention.
As far as capturing the message, I'm thinking you'd need a custom pipeline component - perhaps even subclassing the EdiDisassembler so you can catch this particular exception and deal with it.
My production server recently got a slew of access probes (to try and find a point to break in, to URI's like to /admin.php, /administrator, /wp-login.php, etc.), and I noticed that some of the REMOTE_ADDR's reported by Apache (IP4's) had two dots where there should be one.
What's up with this? Is this some way for servers to hide?
For one, it means that I need to log these to a wider field than expected. Expected would be xxx.xxx.xxx.xxx or 15 characters, but this might make it 16 or even 19.
[Edit: or better yet 50, see this]
The problem is happening in some code somewhere in your application (etc) that is doing formatting.
IP addresses are actually an array of 4 unsigned bytes. They are conventionally represented character-wise (for human consumption) in "ddd.ddd.ddd.ddd" form, but that is not the fundamental representation. The fundamental representation does not have dots in it at all.
It therefore follows that the extra dots you are seeing are some problem with either the way the IP addresses are converted to strings, or the resulting strings are incorporated into messages, or those messages are handled and ultimately displayed. The extra dots do not "mean" anything ... except ... possibly ... to say that some characters have been left out.
Without more information, we can't tell you where those dots come from, or how to stop them.
What's up with this? Is this some way for servers to hide?
Nope.
At the point that your systems first see those IP addresses, they are in 4-byte form, just like other IP addresses. The dots are not a new way to hide. Rather they are just a result of a local problem in the way things are being logged.
UPDATE
Looking at the evidence in your "half answer", one possibility is that you have some progress monitoring or debugging code somewhere that occasionally outputs a "dot" into the output stream. It looks like it would be on a different thread ...
So far my hosting company says only that I can clean up these values.
They are right. But you probably want to find where your application is injecting the garbage and fix that ... rather than massaging the log files.
What are you doing with that variable in your code? I expect it's being translated or parsed in some way that's adding the extra period.
It's extremely unlikely that Apache would report it that way, as that would be invalid as an IPv4 address.
Compare your output with the web server's access logs, which will have recorded the remote IP as Apache saw it.
Half of the answer is that php's $_SERVER['REMOTE_ADDR'] is untrusted because it comes directly from the http request as provided by the server to php it can apparently and from other reports be spoofed.
EDIT2: I have more recently found two more bad variables from $_SERVER with double dots, as follows:
SERVER_ADDR REMOTE_ADDR REQUEST_TIME_FLOAT
184..154.227.128 183.60.244.30 1391788916.198
184.154..227.128 183.60.244.37 1391788913.537
184.154..227.128 183.60.244.37 1391788914.368
184.154..227.128 184.154.227.128 1391086482.1889
184.154.227.128 183..60.244.30 1391788914.1494
184.154.227.128 183..60.244.37 1391788913.0523
184.154.227.128 183.60..244.37 1391788911.5938
184.154.227.128 183.60..244.37 1391788914.3977
184.154.227.128 183.60.244.37 1391788911..9855
So far my hosting company says only that I can clean up these values. That is easy, but cleaning up garbage is still garbage. If dots can and are being added, then the numbers can and possibly are be changed too I think. Humm?
See: this comment from the php manual.
Now that leaves the question where to find a trusted IP from the accessing client? Apache has it I'm guessing from the incoming http packet exchange with the client. (I'll ask this Q: in StackOverflow).
I am currently implementing an EDI solution in BizTalk Server 2010.
This is the scenario:
BizTalk is responsible for the correct message routing between a X.400 mailbox and the customer's ERP software. It is also used to put information about the exchanged message into a SharePoint site using the SharePoint webservices.
I am using Role Links and the BizTalk party management to apply the correct settings (send ports, password in UNB6 segment, etc.).
Now I have the following question:
When I try to fetch an outgoing INVOIC message from the customer's ERP system, extract the relevant information in an orchestration and write it into the SharePoint site, the receive port using the EDI receive pipeline gets suspended with the following error message:
An output message of the component "EDI disassembler" in receive pipeline
"**********.Pipelines.FileNamePromotionEDIReceivePipeline, **********.Pipelines,
Version=1.0.0.0, Culture=neutral, PublicKeyToken=****************" is suspended
due to the following error:
Error: 1 (Miscellaneous error)
33: Invalid occurence outside message, package or group.
The sequence number of the suspended message is 1.
This happens because the message uses a CR and LF as suffix after each segment delimiter. Now I could add the ASCII-hex-codes for CR and LF to the "EfactDelimiters" setting of the pipeline, but the problem is that there are other messages without the CR and LF, which then could not be received using the same pipeline. By the way, when I fetch one of those messages without CR and LF using the pipeline also without CR and LF set as delimiters, the receive port also gets suspended, this time with an error message resulting from the usage of dots instead of commas as decimal separator (although I have enabled the option "UseDotAsDecimalSeparator" in the pipeline). Again, only changing the EfactDelimiters helps.
I thought that the "Character set and separators" page in the party agreement was supposed to make exactly that possible: To set the delimiters individually for each business party. But the changes I make in these settings seem to have no effect whatsoever. I set the "UNA6 Suffix" to "CR LF" and the "Decimal Notation (UNA3)" to ".(Decimal)", restart the host instance... same problem.
Can anyone help?
I never used biztalk, but I know my EDIFACT, and as far as I know, those messages containing CR/LF are syntactically wrong. The UNA6 Suffix seems to be an addition by Microsoft, as I can find no trace of it in the official documents on EDIFACT at UNECE.
Normally, the chars you want to use as special chars in an EDIFACT message are set by the special (optinal) UNA segment, which always comes first. When you write, you set the separators / delimiters, I don't really know, what you mean by that, as it could refer either to setting the options for the created message (what delimiters are used in the message), setting the delimiters used for parsing by the receiving program, or it could refer to the chars that are printed in the UNA segment.
Know, in the UNA segment, there is no way that I know of, to indicate the use of any UNA6 suffix (as stated quite explicitly in the documents, the UNA segment has to be exactly 9 characters of length, see 8.3 Interchange formatting rules). That leads me to the conclusion, that you set the options for the created messages. I would not advise to use a UNA6 suffix, if you can avoid it. It might be nice for humans to read the message, but it does not belong there and is not useful for the machine to read.
If the receiving program has no option to allow optional occurrence of CR/LF, and you can not avoid a mix of those to kind of messages, I see no other way for you other than somehow insert a small program that gets rid of the CR/LF.
The most important principle is of course, to make the sending and the receiving program talk in the same syntax, otherwise it can't work. The same thing goes for the problem with the decimal separator. As of Syntax rules, 10.1, either the comma or the dot is allowed, which is a quite loose definition. If you want to be on the save side, send an UNA segment, specifying which one you use, and then only use that one.
I'm not really sure, how much this helps you with the specific problem, as it might be a thing that's only a question on how to configure biztalk, but I thing some background information should be useful.