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.
Related
I have a BLE characteristic that shall represent a switch, hence a boolean value. My intention is to give it a fixed size of "1 byte", and when read, 0 means false, 1 means true. I want this characteristic to be readable and writable.
Since the value can be written, I want to validate that only one of those two values is written to the characteristic. Any other values are invalid.
The Bluetooth Core Specification v5.3 specifies in Volume 3, Part F, chapter 3.4.5.1 "ATT_WRITE_REQ" (page 1443):
If the attribute value has a fixed length and the requested attribute value
parameter length is greater than the length of the attribute value then the
server shall respond with an ATT_ERROR_RSP PDU with the Error Code
parameter set to Invalid Attribute Value Length (0x0D).
This code 0x0D is also mentioned on page 1423 in a table of ATT error codes. So when the client attempts to write more than 1 byte to the characterstic, I reject the write request with that error code 0x0D, and the correct error message appears in nRF Connect for example.
What I cannot find is if there is any recommended way to respond something that conveys an "invalid value" or "value out of range" error kind; in my case, that would be the response to any 1-byte-values other than 0x00 or 0x01, like 0x0A for example.
I see that table 3.4 on pages 1422f contains error codes for the ATT_ERROR_RSP PDU, 0x13 "Value Not Allowed" being one of them. 0x13 is however not listed as valid error code in response to an ATT_WRITE_REQ (table 3.44, page 1458).
The concept of "invalid argument" appears so fundamental to me that I don't trust my understanding it is not covered by the standard codes already.
But the only somewhat matching pre-defined and valid error code would be 0x06 "Request Not Supported", but that one is so widely used for all kinds of requests that I don't think it's meant to be used here.
Is it really up to me to pick a custom error code from the "Application Error" range? If not, which pre-defined error code should I use?
Background
Note that the error codes that are defined and discussed in the ATT chapter are mainly ATT protocol related error codes. The ATT protocol's task is to make sure that the request opcode is supported, the handle is valid, the permissions are acceptable, a sent value conforms to the maximum length requirements etc. The ATT protocol does not inspect or validate the contents of the individual bytes. That is the task of a "higher level specification", i.e. in practice GATT or a GATT service. You should therefore definitely not use ATT protocol specific error codes such as "Request Not Supported" since that refers to that an ATT operation is not implemented.
Keep in mind that the Bluetooth specification is written and maintained by a huge amount of companies and organizations who can propose not so always well thought out changes that after a (quick) review can get incorporated into the standard. Also since different Bluetooth SIG GATT services are made by different people, these people might have different opinions on which error codes should be used due to the lack of good ones properly defined by the core standard.
Let's go back to Bluetooth v4.0, when BLE was introduced. Here we can read that the only valid error codes for Write Requests are "Application Error" error codes (0x80-0xff) beyond some ATT protocol specific error codes. The ATT chapter does not specify the meaning for specific Application Error codes but instead says they are defined in a "higher layer specification".
In the GATT chapter of the 4.0 specification, we can read:
If the Characteristic Value that is written is the wrong size, or has an invalid value as defined by the profile, then the value shall not be written and an Error Response shall be sent with the Error Code set to Application Error by the server.
Opening up various GATT service specifications from Bluetooth SIG, custom application error codes are defined in a table with the corresponding meaning for this service and how the specific error code is used. One example is the Alert Notification Service, where one code is defined as "command not allowed". Another example is the HTTP Proxy Service which defines the application errors "Invalid Request" when the URI, HTTP Header or body is incorrect, and "Network Not Available" when no network connection is available. For the Physical Activity Monitor Service there is one error code "Invalid Type" that is used when the Type value is in the RFU range. Otherwise, the early defined services back in 2011 often ignore the case when an invalid value is written and do not specify how that should be handled. Take the Link Loss service for example where the alert level can be one of three different levels. It specifies how the device should act upon a disconnection for (only) the three different levels. It does not mention that a value out of range should be rejected when written and it does not specify what should happen upon disconnection if the written value was out of range.
To solve the mess a few "Common Profile and Service Error Codes" were added in Bluetooth 4.1 and listed in the Core Specification Supplement. Two of particular interest are the following:
2.1 OUT OF RANGE (0xFF)
The Out of Range error code is used when an attribute value is out of range as defined by a profile or service specification.
2.4 WRITE REQUEST REJECTED (0xFC)
The Write Request Rejected error code is used when a requested write operation cannot be fulfilled for reasons other than permissions. Note: This differs from the “Write Not Permitted” error response in Vol 3, Part F, Section 3.4.1.1 (ATT), which is intended when the write operation cannot be fulfilled due to permissions.
Lately defined services, such as the Emergency Configuration Service, has a big section in its introduction that when a client writes a value that is RFU, the server should generally "reject" the write, which I assume means use the error code above. The server can also, when specified, ignore individual RFU bits or whole RFU values, in case that would be more relevant.
In the ATT chapter of Bluetooth 4.1, the Application Error range has now been decreased from 0x80-0xff to 0x80-0x9f. The range 0xa0-0xdf is now RFU and 0xe0-0xff is allocated for "Common Profile and Service Error Codes". Apart from being breaking changes, they did two mistakes:
They forgot to include "Common Profile and Service Error Codes" in the list of allowed Error Response codes for relevant corresponding request methods "Attribute Request and Response Summary".
They forgot to change the text in the GATT chapter about how to handle a written value that is the wrong size or is invalid as defined by the profile. It still says (only) that an "Application Error" shall be sent. It should mention the possibility of "Common Profile and Service Error Codes" as well.
Since neither of the ATT nor GATT standards mention these new error codes as being valid to use for any of the Write methods, they are technically never allowed to be used...
The first mistake was fixed first in version 5.3. The second mistake has still not been fixed as of the latest version (5.3).
In Bluetooth 5.1, a Client Supported Features characteristic was added to the Generic Attribute Profile Service. This contains a bitfield that can be written by the client. If a client has ever written 1 to a bit, it may not later write a 0 to the same bit. Since the team defining this missed that the error code "Write Request Rejected" exists, or didn't think it was good enough, they invented a new error code "Value Not Allowed" which, according to my interpretation, means that the value is in range but in this situation not allowed. Here I think they made a mistake adding this as an error code as part of the ATT standard, rather than as a "Common Profile and Service Error Code". Again, they made the same mistake as before, i.e. forgot to update the table of valid error codes for the different ATT request methods as well as updating the Write section in the GATT chapter that this error code may be used when a value is not allowed.
This new Value Not Allowed error code is used in the Microphone Control Service. It has a Mute characteristic (readable, writable, notifiable) which can contain Not Muted, Muted, Disabled or RFU. A client may only write Not Muted or Muted, otherwise the server shall return "Write Not Allowed". Only the server can hence set the value to "Disabled".
So due to the lack of a clearly defined "invalid value" error defined in the first place in Bluetooth 4.0, the various specifications are not consistent how to handle the case when a written value is out of range or RFU. Some services ignore values that are RFU, some use the "Write Not Allowed" error code, some use the "Write Request Rejected" error code, some use service-defined application error codes and you also have the "Out Of Range" error code.
Conclusion
For your case, I would probably go with the "Out Of Range" 0xff error code when 1 byte is written, but the byte is out of range, since it best describes the error and is probably the most helpful one, rather than a custom application error code or a generic not allowed/rejected error code. Clients complying to Bluetooth 4.1 or newer will see this 0xff as "Out Of Range", while clients complying to Bluetooth 4.0 will see this 0xff as an Application Error code.
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.
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 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~~