Today I would like to share with you our newest feature: When creating a new Message Implementation Guideline (MIG) based on a payload, you can now select MIG nodes for automatic qualification based on the qualifier values in the payload. This feature should help to further simplify and speed-up the creation of MIGs. In this blog post I would like to give you a short overview of this new feature and how to use it.
The picture before depicts the overall building blocks of Integration Advisor (of SAP Integration Suite). This blog post mainly relates to the Message Implementation Guideline area.
Recap: Using the qualification feature for MIGs
You probably have already heard about the so-called Qualification feature in Integration Advisor. Qualification means explicitly modeling the precise semantic meaning of a generic node in a message structure. By doing so, you reap the following key benefits:
More precise specification / documentation (e.g., in communication with your B2B Partner)Simplified and extended payload validation at runtimeSignificantly simplified mapping implementation (save up to 30-50% of otherwise required mapping functions)
You can find an excellent introduction to the qualification concept in this blog post: Link
Let me add a few additional thoughts on the following question: when should you qualify a MIG node and when shouldn’t you do so?
The Qualification feature is most frequently used for EDI messages (e.g., from ASC X12 or UN/EDIFACT type systems) and SAP IDoc messages. For these messages you usually find a huge number of message nodes that are candidates for qualification (they have so called qualification markers, depicted by the grey arrow in the message structure). It is typically not advisable to use the qualification feature randomly at all the places where it would be possible.
You should use qualification, if in a specific scenario a node comes in different variants (with different qualifier values) and where one of the below applies:
There are significant structural differences in these different variants which you want to have covered in your detailed semantic validation at runtime.The different variants of the node need to be mapped to/from different nodes in your Mapping Guideline (MAG).Mapping details for the child nodes inside these node variants differ significantly.
On the other hand, if the different variants of a node are very similar to each other and shall be mapped to/from the same node in your MAG, it is most often recommended to refrain from qualifying this node. Please note that using qualification variants comes with a slight overhead in your mapping: you need to map each of the qualified nodes (and all their sub nodes) separately. This is great if you need to map them differently. But it is duplicate effort if the mapping for all these qualified nodes is identical.
To illustrate this, let us have a look at the example in the next screenshot.
The screenshot depicts an EDI flat-file payload for the UN/EDIFACT message ORDERS (more specifically it is from the Edifact subset GS1 EANCOM).
We can see that the DTM segment comes in two variants (depicted by the green box in above screenshot): one for order date/time (qualifier value 4) and one for message date/time (qualifier value 137). These variants differ in the used date time format, and we would like to ensure the incoming message uses the correct date time format. Moreover, we know that both DTM variants need to be mapped to different nodes on target side. As a result, we want to use qualification for the DTM node.
In a similar way, there are three variants of the NAD segment (inside of SG2 segment group): one for buyer (qualifier value BY), one for ship to (qualifier value ST) and one for supplier (qualifier value SU). We want to ensure the incoming message contains complete address information for the ship-to party, while address information is not required for buyer and supplier parties. Therefore, SG2 shall be qualified as well in our MIG.
In many real-life Edifact ORDERS MIGs, different variants of SG28 > QTY, SG28 > MOA and MOA are used. In our simplified example, however, all these nodes come only in one variant. Therefore, we choose to skip qualification for these nodes in our example MIG.
MIG Creation with payload
The Create Message Implementation Guideline wizard has already offered the option to supply a payload (step Sample Payload) in the past. If you do, all nodes present in your payload will be automatically selected in the structure of your new MIG. Moreover, payload values will be copied as Example Values into your MIG (should the according option be selected).
With our feature extension you will now find an additional step Node Selection in the Creation Wizard. Here you can select those nodes of the message structure which shall be qualified automatically. Refer next screenshot for an illustration.
In our example, we have selected message nodes DTM and SG2 to be qualified.
Please note the following technical boundary conditions: In step Node Selection you can choose only those nodes, for which the message structure already offers the required qualifier marker. You can’t use the new feature for situations where the node does not have the needed qualifier marker or the qualifying node does not yet have the required codelist or where you want to replace the standard codelist (for the qualifying node) with a different codelist. In such cases, just continue with the MIG creation without selecting this node and perform the qualification afterwards via the MIG Editor in the standard way.
Result of the MIG Creation
After the new MIG is created it contains already below customizations.
Qualified nodes
The nodes chosen in the MIG Creation Wizard will already be qualified in the MIG. Here each qualifier value present in your payload will create its own qualification variant.
In our example, segment DTM got qualified for the values 4 and 137 while segment group SG2 got qualified for the values BY, ST and SU. Refer next screenshot for an illustration.
Note that the used qualifier values must be part of the standard codelist. If the payload contains a value which is not part of the codelist, the qualification variant is ignored, and you are informed via a warning in column Status.
2. Selection of nodes and setting of example values
As before, all nodes used in your payload automatically get selected in your MIG. And your payload values are added as Example Values (if this option was chosen).
This behavior has now also been extended and improved: Node selection and example values take the qualification variants into account. As you can see in the screenshot above, in SG2 qualified for the supplier (SU) only those nodes are selected which are indeed used in the SG2 specific for SU. And for the node “3164 – City name” only the payload value Walldorf from the supplier variant was added.
Please note that mandatory nodes are automatically selected at the time of MIG creation which is not influenced by the payload. If your payload does not use a mandatory node, MIG Editor will inform you via a warning in column Status. In such a case you should investigate if your payload is incomplete or if this mandatory node is not used in your scenario.
And one final comment: Our feature even allows you to trigger nested qualification by selecting nodes to be qualified inside other nodes to be qualified. In such a situation, a simplification is applied by adding identical inner (nested) qualification variants to all related outer qualification variants. Potentially not all inner qualification variants might apply to all outer qualification variants – in this case you can simply deselect or remove the unwanted inner qualification variants.
Conclusion
This new feature helps you in building your Message Implementation Guidelines (MIGs) even faster and with less manual customization effort.
Further reading
Today I would like to share with you our newest feature: When creating a new Message Implementation Guideline (MIG) based on a payload, you can now select MIG nodes for automatic qualification based on the qualifier values in the payload. This feature should help to further simplify and speed-up the creation of MIGs. In this blog post I would like to give you a short overview of this new feature and how to use it. The picture before depicts the overall building blocks of Integration Advisor (of SAP Integration Suite). This blog post mainly relates to the Message Implementation Guideline area.Recap: Using the qualification feature for MIGsYou probably have already heard about the so-called Qualification feature in Integration Advisor. Qualification means explicitly modeling the precise semantic meaning of a generic node in a message structure. By doing so, you reap the following key benefits:More precise specification / documentation (e.g., in communication with your B2B Partner)Simplified and extended payload validation at runtimeSignificantly simplified mapping implementation (save up to 30-50% of otherwise required mapping functions)You can find an excellent introduction to the qualification concept in this blog post: LinkLet me add a few additional thoughts on the following question: when should you qualify a MIG node and when shouldn’t you do so?The Qualification feature is most frequently used for EDI messages (e.g., from ASC X12 or UN/EDIFACT type systems) and SAP IDoc messages. For these messages you usually find a huge number of message nodes that are candidates for qualification (they have so called qualification markers, depicted by the grey arrow in the message structure). It is typically not advisable to use the qualification feature randomly at all the places where it would be possible.You should use qualification, if in a specific scenario a node comes in different variants (with different qualifier values) and where one of the below applies:There are significant structural differences in these different variants which you want to have covered in your detailed semantic validation at runtime.The different variants of the node need to be mapped to/from different nodes in your Mapping Guideline (MAG).Mapping details for the child nodes inside these node variants differ significantly. On the other hand, if the different variants of a node are very similar to each other and shall be mapped to/from the same node in your MAG, it is most often recommended to refrain from qualifying this node. Please note that using qualification variants comes with a slight overhead in your mapping: you need to map each of the qualified nodes (and all their sub nodes) separately. This is great if you need to map them differently. But it is duplicate effort if the mapping for all these qualified nodes is identical.To illustrate this, let us have a look at the example in the next screenshot.The screenshot depicts an EDI flat-file payload for the UN/EDIFACT message ORDERS (more specifically it is from the Edifact subset GS1 EANCOM). We can see that the DTM segment comes in two variants (depicted by the green box in above screenshot): one for order date/time (qualifier value 4) and one for message date/time (qualifier value 137). These variants differ in the used date time format, and we would like to ensure the incoming message uses the correct date time format. Moreover, we know that both DTM variants need to be mapped to different nodes on target side. As a result, we want to use qualification for the DTM node. In a similar way, there are three variants of the NAD segment (inside of SG2 segment group): one for buyer (qualifier value BY), one for ship to (qualifier value ST) and one for supplier (qualifier value SU). We want to ensure the incoming message contains complete address information for the ship-to party, while address information is not required for buyer and supplier parties. Therefore, SG2 shall be qualified as well in our MIG. In many real-life Edifact ORDERS MIGs, different variants of SG28 > QTY, SG28 > MOA and MOA are used. In our simplified example, however, all these nodes come only in one variant. Therefore, we choose to skip qualification for these nodes in our example MIG. MIG Creation with payloadThe Create Message Implementation Guideline wizard has already offered the option to supply a payload (step Sample Payload) in the past. If you do, all nodes present in your payload will be automatically selected in the structure of your new MIG. Moreover, payload values will be copied as Example Values into your MIG (should the according option be selected).With our feature extension you will now find an additional step Node Selection in the Creation Wizard. Here you can select those nodes of the message structure which shall be qualified automatically. Refer next screenshot for an illustration.In our example, we have selected message nodes DTM and SG2 to be qualified.Please note the following technical boundary conditions: In step Node Selection you can choose only those nodes, for which the message structure already offers the required qualifier marker. You can’t use the new feature for situations where the node does not have the needed qualifier marker or the qualifying node does not yet have the required codelist or where you want to replace the standard codelist (for the qualifying node) with a different codelist. In such cases, just continue with the MIG creation without selecting this node and perform the qualification afterwards via the MIG Editor in the standard way.Result of the MIG CreationAfter the new MIG is created it contains already below customizations.Qualified nodesThe nodes chosen in the MIG Creation Wizard will already be qualified in the MIG. Here each qualifier value present in your payload will create its own qualification variant. In our example, segment DTM got qualified for the values 4 and 137 while segment group SG2 got qualified for the values BY, ST and SU. Refer next screenshot for an illustration. Note that the used qualifier values must be part of the standard codelist. If the payload contains a value which is not part of the codelist, the qualification variant is ignored, and you are informed via a warning in column Status.2. Selection of nodes and setting of example valuesAs before, all nodes used in your payload automatically get selected in your MIG. And your payload values are added as Example Values (if this option was chosen). This behavior has now also been extended and improved: Node selection and example values take the qualification variants into account. As you can see in the screenshot above, in SG2 qualified for the supplier (SU) only those nodes are selected which are indeed used in the SG2 specific for SU. And for the node “3164 – City name” only the payload value Walldorf from the supplier variant was added. Please note that mandatory nodes are automatically selected at the time of MIG creation which is not influenced by the payload. If your payload does not use a mandatory node, MIG Editor will inform you via a warning in column Status. In such a case you should investigate if your payload is incomplete or if this mandatory node is not used in your scenario. And one final comment: Our feature even allows you to trigger nested qualification by selecting nodes to be qualified inside other nodes to be qualified. In such a situation, a simplification is applied by adding identical inner (nested) qualification variants to all related outer qualification variants. Potentially not all inner qualification variants might apply to all outer qualification variants – in this case you can simply deselect or remove the unwanted inner qualification variants. ConclusionThis new feature helps you in building your Message Implementation Guidelines (MIGs) even faster and with less manual customization effort. Further readinghttps://community.sap.com/t5/technology-blogs-by-sap/integration-advisor-overview-of-components-for-… https://community.sap.com/t5/technology-blogs-by-sap/integration-content-advisor-create-a-customized… Read More Technology Blogs by SAP articles
#SAP
#SAPTechnologyblog
