Hello SAPers!

 

Here is another blog post exploring DMEE functionality options. Hope it will be interesting and will give you new insights on DME engine.

DMEE engine provides a lot different mapping options that allow you to populate nodes in DMEE tree with necessary values. Just to recap, you can use the following options:

In addition to mapping options SAP also provides other options that enable you to structure your DMEE tree flexibly e.g.:

  • Delimiter options that can be used to separate elements in segment groups, segments;
  • Definition of allowed / not-allowed characters to take care of special (e.g. #, $, “, ” etc.) and local characters (e.g. ü, ä, ö etc.);
  • Conditions technique – to customize display of certain nodes depending on certain conditions.
  • Built-in conversion functions that apply specific formatting to the node values before that are displayed. Consider, for instance, a node with a date value. Conversion function YYYYMMDD is applied to a node and as a result date in this node will be displayed in YYYY.MM.DD format.

You can check the list of conversion functions by selecting the field and pressing F4:

As you can see, there are 355 predefined conversion functions delivered by SAP. These functions can be logically divided into three groups and can be applied to the following data types: dates, currency amounts and character strings. Though, these functions provide a lot of flexibility they are not exhaustive. Suppose, you need to format a date value in the following format: YYYY-MM-DD. This is quite common requirement, but there is no built-in conversion function for this purpose. So, the question is how can this requirement be solved?

One way is to use own mapping (with atom handling 01) as a mapping option for a date field (e.g. SubmissionDate). Then to create several 5 atoms – two technical ones (i.e. hyphen), which would serve as a delimiter with constant value “-” and three atoms referencing the same structure field containing date, but with different conversion functions (see attached table below for more details). Thus, each date-related atom will store only part of the date – year, month and day respectively. Use of own mapping will insure that date will be displayed in proper format.

Node of DMEE tree configured following this proposal might look as follows:

One might wonder whether this approach is the best one? Well, if you should apply this formatting to one node only – then it is probably the best way. However, let’s suppose you have several date fields on header level and several on line item level? In that case, DMEE tree will be overloaded with technical fields and it will take a lot of time to make sure that all technical nodes are configured correctly.

There is a better way to meet this requirement by usage of XSLT-transformations. Unfortunately, it is restricted to XML-based DMEE trees only. Basically XSLT-transformation is a program that enables you to transform the content of one XML-document into another XML-document, which would be different from format or structure perspective. As this post is intended for functional consultants, I’ll not go into technical details (anyway, I’m not an expert on XSLT), but will focus on the implications of this technology for DMEE application. XSLT-transformation can be defined in t-code XSLT_TOOL and might look as this:

 <xsl:stylesheet version="1.0"
 xmlns:xsl="http://www.w3.org/1999/XSL/Transform">
 <xsl:output omit-xml-declaration="yes" indent="yes"/>
 <xsl:strip-space elements="*"/>

<xsl:template match="node() | @*">
    <xsl:copy>
      <xsl:apply-templates select="node() | @*" />
    </xsl:copy>
  </xsl:template>

  <xsl:template match="*[name( ) = 'SubmissionDate']">
    <xsl:call-template name="FormatDate">
      <xsl:with-param name="Date"  select="."/>
      <xsl:with-param name="Name"  select="name()"/>
    </xsl:call-template>
  </xsl:template>

  <xsl:template match="*[name( ) = 'DataFrom']">
    <xsl:call-template name="FormatDate">
      <xsl:with-param name="Date"  select="."/>
      <xsl:with-param name="Name"  select="name()"/>
    </xsl:call-template>
  </xsl:template>

  <xsl:template match="*[name( ) = 'DataTo']">
    <xsl:call-template name="FormatDate">
      <xsl:with-param name="Date"  select="."/>
      <xsl:with-param name="Name"  select="name()"/>
    </xsl:call-template>
  </xsl:template>

  <xsl:template match="*[name( ) = 'documentDate']">
    <xsl:call-template name="FormatDate">
      <xsl:with-param name="Date"  select="."/>
      <xsl:with-param name="Name"  select="name()"/>
    </xsl:call-template>
  </xsl:template>

  <xsl:template name="FormatDate">
    <xsl:param name="Date" />
    <xsl:param name="Name" />
    <xsl:element name="{$Name}">
      <xsl:value-of select="translate($Date, '.', '-')"/>
    </xsl:element>
  </xsl:template>

</xsl:stylesheet>

Basically, this transformation does the following: copies all tags from the XML-document generated by DMEE, but in those cases when it encounters specific fields during copying (i.e. SubmissionDate, DataFrom, DataTo, documentDate) it applies format template “FormatDate” by replacing “.” in the date value by “-” (it is assumed that date is passed in as YYYY.MM.DD).

XSLT-transformation should be assigned to DMEE tree on Format attributes tab.

After execution of XSLT-transformation all date values will be converted to a correct format.

This example demonstrates quite simple case and is intended to give functional consultant a better understanding of possible options behind DME engine. This approach has its own drawbacks. As was already mentioned before, it is applicable to XML-based DMEE trees only and it implies development efforts as opposed to pure customizing by a functional consultant. On the other case, there might be quite complex requirements, which cannot be solved by customizing. In that cases, XSLT-transformation might be considered as one of possible enhancement options along with exit modules and implicit enhancements.

I hope this post was useful! Your suggestions and comments are welcome! You can also find this post on Medium platform via the following link.

Best regards,

Bohdan Petrushchak

 

P.S. Acknowledgments. Thanks to Svetlana Shlapak for XSLT-transformation.

To report this post you need to login first.

4 Comments

You must be Logged on to comment or reply to a post.

  1. Morten Wittrock

    Hi Bohdan

    That’s interesting, I didn’t know that XSLT was available in this context. It is indeed an awesome language for transforming XML. Very flexible and powerful, but at the cost of a somewhat steep learning curve.

    Regards,

    Morten

    (0) 
    1. Bohdan Petrushchak Post author

      Hi Morten,

      Thanks for your feedback! With SAP it’s always this way – there are a lot of useful options, which might be hidden deep in the settings and you will never know about them. Sometimes you either stumble upon them accidentally or are faced by a problem, which cannot be solved by a more visible functionality. That’s when you start looking for some additional features.

      In this particular case, the assignment of transformation is quite visible, but the problem is that functional consultants who customize DMEE might not understand its power, whereas developers might not be aware about the possibility of this assignment in the first place and will start looking for more complex solutions. It was a problem for me a couple of years ago – you see some customizing option, but cannot comprehend what it is doing. So I decided to contribute a bit to resolution of this problem.

      Regards,

      Bohdan

      (1) 
  2. Bastiaan Jansen

    I’m not sure if will need to use it soon but it will definitely help me  analyzing “uneplainable behaviour” of DMEE output! Thanks a lot for making us aware of this option / technique.

    If only 1 small change is required I will probably handle it with an exit or atoms. You can find the source where you expect it this way. However it seems very powerfull if a lot of conversions need to be done.

    (0) 

Leave a Reply