Integration Advisor – GS1 XML Messages and Namespa...

Jörg_Ackermann · ‎2023 May 23

We are happy to announce that we have now added the B2B Library of GS1 XML Messages to our predefined Type System content in Integration Advisor of SAP Integration Suite. Associated with this new content we also extend our support for namespace handling in XML messages. In this blog post I would like to give you a short overview of these related topics.

GS1 XML Messages

The GS1 organization offers the GS1 XML library. This library contains a set of standard messages for the GS1 EDI (Electronic Data Interchange) enabling the exchange of transactional information between trading partners. For more background on GS1 XML you can refer to the GS1 homepage (Link).

Integration Advisor provides 7 versions (of the version 3 series) of GS1 XML from 3.0 up to 3.5.1:

This offering contains overall 49 messages such as, orderMessage, invoiceMessage or despatchAdviceMessage:

Use of the GS1 Global Codelist collection

The GS1 organization also provides numerous codelists for different domains. GS1 follows the philosophy to define and deliver codelists independently from a specific message standard. As a result, different GS1 message standards like GS1 EANCOM or GS1 XML can use the same set of GS1 Codelists.

Integration Advisor has been offering the GS1 Codelists since last year. You can find more information about this offering in this blog post: Link

Due to this GS1 strategy, the GS1 XML Type System itself does not contain any Codelists. Instead, all GS1 messages will refer to the GS1 Global Codelists wherever needed.

Note that GS1 distinguishes between two types of codelists called *Enumeration and *Code. Codelists of both types are included in the GS1 Codelist collection.

Namespace Prefixes in GS1 XML Payloads

The XML standard offers the option that XML elements or attributes can be part of a namespace and require a namespace declaration (so called form=qualified).

GS1 XML messages use this option. To illustrate this, let us take a look at an XML payload example of the GS1 orderMessage:

The root node of this message is called <order:orderMessage>. The namespace prefix "order" declares that this element is part of the namespace "urn:gs1:ecom:order:xsd:3".

The next element is <sh:StandardBusinessDocumentHeader>. Each GS1 XML message contains this standardized element. This element and its substructure are defined by the UNECE organization and is reused here within the GS1 XML messages. This complete subtree belongs to the namespace "http://www.unece.org/cefact/namespaces/StandardBusinessDocumentHeader" which uses the namespace prefix "sh". It is defined in a way that a namespace declaration (prefix "sh") is required for all sub-elements (form=qualified), but not for its attributes. See the element <sh:HeaderVersion> in above screenshot for reference.

After this standardized header the actual order details are provided by the element <order>. Note that this element <order> and all its sub-elements are defined in a way that no namespace declaration is required (form=unqualified) and therefore these elements don't carry a namespace prefix (like "order:").

Extended XML Namespace Support

In the past, Integration Advisor had only provided preliminary namespace support for the root node.

To cater for the GS1 XML requirements we now extend our offering and support XML messages that require namespace prefixes for its elements or attributes. This particularly relates to the generated Runtime Artifacts (XSDs and XSLTs) which need to take these namespace declarations and prefixes into account.

What does this mean for our MIG Editor? We consider namespace prefixes as rather technical and therefore of little interest to the typical Business Expert. Therefore, the message tree structure (shown on the left of MIG Editor) will only show the Node Identifier (like "HeaderVersion") without the namespace prefixes:

But if you want, you can mark any node and navigate to its properties. You will find the following technical details under the Identifier section in the Details tab:

Namespace Prefix:
- This field is shown if a node requires a namespace prefix (form=qualified). In this case it shows the specific prefix Integration Advisor uses for this node.
- For example, the node "HeaderVersion" uses "sh" as namespace prefix.
- This field is not shown if no namespace prefix is required (form=unqualified).

XML Node Name:
- This field shows the exact way how this node would be called in an XML Payload.
- It will contain a namespace prefix if required and will skip it if not required.
- In our example this would be <sh:HeaderVersion> - compare also the earlier screenshot of the GS1 payload for orderMessage.

Moreover, under the tab Namespaces you will find the list of all namespaces and associated namespace prefixes that are relevant for your MIG.

One final remark around this topic: Integration Advisor offers advanced features for semantic message payload validation where you can validate cross-field dependencies via so called XSD Assertions. (More details about this feature can be found in this blog post: Link). Technically such an Assertion must be a valid Boolean XPath 2.0 expression. If you want to refer to any node of your message structure in this XPath, you must use the correct name by which the node is called in the XML payload. This needs to contain the namespace prefix if required. For your convenience, the field "XML Node Name" will provide you with the name to be used in your XPath.

Runtime Artifacts for Cloud Integration

For any Message Implementation Guideline (MIG) or Mapping Guideline (MAG) defined in Integration Advisor, you can generate the required Runtime Artifacts.

For GS1 XML you will find multiple MIG RD XSD files in the exported archive (typically 2 or 3):

The primary XSD file with file name ending on "*_RD.xsd".

And one or more supporting XSD files with file names looking like "*_RD_n.xsd"

If you use semantic XML validation in Cloud Integration, your Integration Flow will include a flow step for XML Validation. As before, you need to assign the (primary) MIG RD XSD file (with file name ending on "*_RD.xsd") as reference in this flow step.

But note that this primary MIG RD XSD file refers to the other (supporting) XSD files and needs them for correct execution. Therefore, if you manually update your Integration Flow, you need to make sure that you upload/update all these MIG RD XSD files together as Resource into your Integration Flow.

Conclusion

With this new feature we now support the GS1 XML Message Standard. You get an end-to-end solution where you can view and customize GS1 XML messages in Integration Advisor and process such messages in Cloud Integration.