ALSB2.5[MFL] further extensions in escape character functionality - implied delimiters
(Doc ID 777427.1)
Last updated on APRIL 14, 2021
Applies to:Oracle Service Bus - Version 2.5 to 2.5 [Release Aqualogic Service Bus]
Information in this document applies to any platform.
Information in this document applies to any platform
ALSB2.5[MFL] further extensions in escape character functionality In case 635127 we have requested an enhancement which would provide the possibility of escaping field delimiters with specified characters. We wanted to use this enhancement to create MFL descriptions of EDIFACT messages; however, the offered functionality is still insufficient for this task. In EDIFACT messages, data is stored in a hierarchy of segments consisting of elements, which can either have simple values or consist of subelements. Each of these fields is delimited by a single character; default values are "'", "+" and ":" for segments, elements and subelements respectively. If a field value contains any of the delimiter characters, this character must be escaped in the EDIFACT message by putting a designated "release character" just before the character being escaped -- this must be done regardless of whether this character actually delimits the field (if a field value contains the "release character", it also has to be escaped). Default release character is "?". All delimiter characters and the release character defaults can be overridden by including the service string advice segment (UNA) at the beginning of the EDIFACT message. If the characters provided in UNA are different than the defaults, the default characters lose their special status and must not be escaped in fields. Even using the patch for escape character support (developed in case 635127) it is not possible to create an MFL file for an EDIFACT message format. The trouble is that: 1. higher-level delimiters (i.e. segment delimiter in case of an element; segment and element delimiters in case of a subelement) are not escaped if the current field is followed by a mandatory field 2. there is no way to escape a character unrelated to the current field (e.g. to escape the subelement delimiter in an element which does not contain any subelements). We therefore request an enhancement to the abovementioned patch, which would allow us to specify the set of characters that need to be escaped in XML -> non-XML conversion, and un-escaped in non-XML -> XML conversion -- in addition to escaping the actual delimiter characters. This set must allow its elements to be specified by field references and character literals, e.g. it must be possible to include in the set "the value of 'UNA_ElemDelim' field, or the '+' character if that field is not present in the message" -- like it is possible with delimiters . This set must be specified for each field (or for each StructFormat) separately, not for the whole message (as there must be no escaping in the UNA segment). Alternatively, it could be specified for the whole message and individual fields could toggle whether they use the set or not -- but the first approach seems more flexible.
To view full details, sign in with your My Oracle Support account.
Don't have a My Oracle Support account? Click to get started!
In this Document