Autograph Seriennummer

A success story with simple transformations

Simple Transformations (ST) are a wonderful and efficient way ABAP data in XML documents and transform back. They are conceptually two-way, making it ideal for serialization and deserialization suitable - and also they are able to observe how we, highly efficient. If once you have become incorporated into the concept, they are also really simple
, as the name promises, that is easy to implement.
Thanks to the simple transformations, we have succeeded, an unreliable component of our XI system (the JDBC adapter) with a stable running to replace ABAP programmed adapter, which is exactly about his work in the job log accountable and on top of a much better throughput than the previous solution.
We have a remote database, in the fed throughout the day from different sources always new "Messages" (value of goods and factors). To read this and supply the Java classes mapping to further processing, we've been using the supplied by SAP called

 JDBC Adapter 
, according to the description would be exactly suited for this task. Unfortunately, this adapter (in our system) a vulnerability, which could not resolve despite intensive efforts - he suffers to some extent under 
 narcolepsy 

: Quite suddenly, he is every now and then his work is a complete - without giving nor any sign of life, but even without that the process breaks happens in the middle of a processing simply nothing more.
As the incoming messages are time critical, this has repeatedly led to extra maintenance. It had monitoring programs are written to ensure the timely processing of the messages. The wrong time (something always happens the wrong time!) Our support with SMS alarm was out of bed because it was once again permitted. The manual workaround to the JDBC Adapter to get back to work was, then, is to define a second, identically configured channel and switch to it.
The JDBC adapter Unfortunately for us, a "black box". That's the problem with the Java components provided by SAP (not the Java language itself - is the great language Java). We can use the SAP Java components do not study how an ABAP program to draw our own conclusions. [1] We can fix the no fishing circuit to locate these spontaneously occurring errors in more detail. We are forced to addressieren

any problem to the support of SAP. SAP had no response even close to our problem and had the OSS reports, because the problem's not reproducible.

 
 We have therefore decided, this JDBC adapter from the XI input process eliminated and replaced by a programmed in ABAP component that ultimately called 
 Plain Adapter 
 used. This is a the ABAP side ICF Offeree REST-like HTTP Service (accessed through 
 / sap / xi / adapter_plain 
). In the body of the HTTP request from the Plain adapter expects the XML document in the form in which it is finally processed by the XI mapping. It extends that document them on to the XI mapping layer. 

The intrinsically programmed component A started at regular intervals job that the data from the remote database into internal tables reads, transforms the ABAP data to an XML document - this is the place to come where the simple transformations are used - and the XML document passes finally an "internal" HTTP request to the Plain Adapter [2]

In a (typical) job run. , 403 messages with a total of 125 254 notification items processed in 123 seconds. This means a rate of about 1 millisecond per item. This includes reading the position of the database, the mapping of messages in an XML document, and finally the processing in the "Plain Adapter". These are wonderful times! The following chart shows how divided the duration of a typical job run on these steps:

For marshaling , ie the conversion of the ABAP data to an XML document, only 12 of the 125 seconds were needed. The XML conversion, including a step-Prepare in ABAP, in which the data for the transformation can be suitably prepared, ie 10 detail records creates per millisecond. This is more than satisfactory.

 It makes sense to implement before the actual call to the ST a preliminary step in which the data for accessing the ST are suitably prepared. Simple transformations are not only easy to understand, they should also be easily designed. For the more simple a Simple transformation unit, the more efficient they will. In this case, the ST produces a sequence of elements ("lines"), each containing data from head and position. The appropriate data structure for this is an internal table with a deep line type: Each line represents one message and the component 

detail of the line itself is an inter-table containing the items. For nested structures is the increased memory requirements must be ensured. A rough calculation showed us, however, that the main memory is sufficient for the required volume of data for very large messages yet. Moreover, it is indeed only an auxiliary table with extremely short life - she works as a local field "on the stack "and is just broken down in the method and who performs the simple transformation: [3]
* Header / Detail in Table represent a deep line structure loop at it_header assigning \u0026lt;ls_header>

 ls_meldung clear.. 

move-corresponding to \u0026lt;ls_header> ls_meldung
loop at it_detail assigning \u0026lt;ls_detail> where sender = senders and \u0026lt;ls_header> meldungs_id = \u0026lt;ls_header>-meldungs_id and meldungs_datum = \u0026lt;ls_header>. - meldungs_datum partition_knoten and
= \u0026lt;ls_header>-And

 partition_knoten partition_tag = \u0026lt;ls_header>-partition_tag. Insert into table 

\u0026lt;ls_detail> ls_meldung-detail.
endloop. ls_meldung insert into table lt_meldungen. endloop.

Calling the transformation is then very simple:

 * specific message in XML transform 

call transformation (gv_transformation)
source messages = lt_meldungen
result xml ev_xml.

The transformation is called dynamically, we have for each message type, a simple transformation. The previously prepared Message table is passed as source - the result document is received in the parameter ev_xml type xstring (it could string a or an object of type

if_ixml_document be - the transformation automatically detects the expected type). The Simple transformation itself is really simple: After determining the reference data object using \u0026lt;tt:root> the messages with a nested
\u0026lt;tt:loop>
processed. In the inner loop, finally produced the results row by the corresponding source fields from message header or message Position be incorporated into the desired target field by the mapping.

Here is a typical example (we have about a dozen such transformations, and they all look similar):


\u0026lt;? Sap.transform.simple> \u0026lt;- Automatically generated transformation!. Please make adjustments only to the template
(XSLT transformation ZGDBW_TO_XI_CREATE) -> \u0026lt;tt:transform xmlns:tt="http://www.sap.com/transformation-templates"> \u0026lt;tt: root name = "MESSAGES" />
\u0026lt;tt:template> \u0026lt;ns:MT_MVN_DESADV2500 xmlns:ns="http://migros.ch/xi/DESADV2500"> \u0026lt;tt:loop ref=".MELDUNGEN" name="header">
\u0026lt;tt:loop ref="DETAIL"> \u0026lt;row> \u0026lt;sender>
\u0026lt;tt: ref value = "$ header.ABSENDER "/> \u0026lt;/ SENDER> \u0026lt;MELDUNGS_ID> \u0026lt;tt:value ref="$header.MELDUNGS_ID"/> \u0026lt;/ MELDUNGS_ID> (... more header fields ...) \u0026lt;FELD_1> \u0026lt;tt:value ref="FELD_1 "/> \u0026lt;/ Field_1 >

(... more detail fields ...) \u0026lt;/ row>

\u0026lt;/ tt: loop> \u0026lt;/ tt: loop> \u0026lt;/ ns: MT_MVN_DESADV2500 tt> \u0026lt;/: template> \u0026lt;/ tt: transform>



What do you mean "automatically generated"? Another strong advantage of simple transformations (like XSLT transformations) is that it is an easy-to-use API to create a transformation in the repository are - the class CL_O2_API_XSLTDESC . This came to us in our situation very opposite: things like the namespace of the target document and the actually extracting fields namely vary depending on the type of message. We have therefore provided a simple customizing table in which we specify for each message type these differences. A report Z_REGENERATE_ST expands this customizing table provided for all ST-transformations (which he himself used an XSLT transformation). These will be called dynamically. This approach has the advantage that the transformations are as simple and very fast. Also has a transformation in the repository maintained the advantage that it is buffered in operation in the main memory of the server - which speeds up their execution even more.

[1] Although there is next to the disassembler javap
excellent Java Decompiler with exciting user interfaces, such as
jd-gui . However, it is inconvenient to have to decompile a program first, to understand its logic and modify it if necessary. With the increasing in the industry, small-mindedness is also increased with the use of byte-darkening (obfuscation) is expected to complicate the readability of the code continue to decompile.
[2] This is done by means of an internal
HTTP requests - ie, the block HTTP_DISPATCH_REQUEST appears in its own call stack, the request is not processed in a separate task. In particular, the processing of requests is thus synchronous necessarily: If the job has finished, all reports have passed the Plain adapter.
[3] We have a loop through a table of N entering that contains a loop on a second table with N * M entries. This could result in a problem. So here there are no quadratic effects, the position table may not be a standard table. In our case, both tables are sorted. The inner loop with Where condition implicitly uses the sorting order according to the table key, so that there is no performance problem. A - a little more efficient - alternative was to start with the loop at
it_detail
(no WHERE clause) and by

at the new
read head data when switching to a new report. But, as we see the times, is not critical "marshaling Prepare" step in and this form.
1.