SAP MII : Input & Output Parameter

von Sebastian Holzschuh
SAP MII Input & Output - pouring water in a glass

Bei der Nutzung von SAP MII Transaktionen sollten Sie immer die gleichen, sauber strukturierten Übergabeparameter nutzen. Dies verbessert nicht nur die Möglichkeit des parallelen Arbeitens, sondern hilft auf lange Sicht auch bei der Wartung.

Nebst der Tatsache, dass die Entwicklung von Transaktionsschnittstellen sich immer auf eine gewisse Struktur verlassen kann, sind auch die Namen der Parameter immer identisch. Dies erlaubt ein hoch flexibles Vorgehen und ermöglicht die Entwicklung von Webapplikationen auch ohne zuvor abgestimmte oder gar vorhandene Detailstruktur.

Definition der Input-Parameter

Es gibt, wie in der Entwicklung üblich, die verschiedensten Ansätze bei der Definition der Eingabeparameter. Die beiden gängigsten Ansätze sind:
  • Übergabe verschiedener Parameter mit einfacher Benamung ( "Username", "Site", "Workcenter", "Amount" )
  • Übergabe verschiedener Parameter mit typenbasierter Benamung ( "sUsername", "sSite", "sWorkcenter", "iAmount" )
Der Aufruf der Transaktion erfolgt aus dem Webfrontend heraus über einen HTTP GET Aufruf (siehe Tipp zum Rest Service). Die Parameter werden demnach als Variablen in die URL mit übergeben.
Transaction=path/to/transaction&sUsername=holzschuh&sSite=007&sWorkcenter=Montage01&Amount=23
Dieser Aufruf erlaubt die schnelle und unkomplizierte Übergabe von Parametern an eine SAP MII Transaktion, beschränkt sich aber bei sauberem Arbeiten auf einfache Strukturen. Weiterhin ist vermutlich jeder Transaktionsaufruf unterschiedlich, da die Eingabeparameter bei den meisten Transaktionen unterschiedlich sind.

Dementgegen steht die Übergabge der Daten in Form einer XML-Struktur. Der erste Vorteil dieser Übergabevariante ist die Tatsache, dass der Name des Inputparameters immer gleich heißen kann. In vergangenen Projekten (z. B. bei der Integration mit SAP PO) hat sich herausgestellt, dass die XML-Strukturen unterschiedliche Namen haben müssen, damit SAP PO Eingabe und Ausgabe korrekt verarbeiten kann.

Als Name für den Inputparameter nutzen wir xml_input. Demnach beginnt der Inhalt des Übergabe-XMLs mit einer entsprechenden Root-Node. Auf Grund der Lesbarkeit werden alle XML-Nodes klein geschrieben.

<xml_input>
    <username>holzschuh</username>
    <site>007</site>
    <work_center>Montage01</work_center>
    <amount>23</amount>
    <guid>32165-dsa58-564ds564dfsaf-564dsa</guid>
</xml_input>

Als zusätzlicher Parameter kann eine guid zu übergeben. Diese kann während des Loggings genutzt werden, um eine eindeutige Verfolgbarkeit des Aufrufs und seiner Log-Einträge zu gewährleisten. Ein weiterer Vorteil der Nutzung eines XML-Übergabgeparameters ist das Logging der Struktur in das NW Log, da hier nur ein einzelner Parameter geloggt werden muss.

Je nach Entwicklungsumfeld empfiehlt es sich, für die xmlInput Struktur feste Parameter zu definieren, die immer übergeben werden müssen. Auch diese Definition erleichtert das verteilte Arbeiten.

Definition der Output-Parameter

Ähnlich der Input-Parameter verhält es sich auch mit den Output-Parametern: eine einheitliche Variable mit sauberer Struktur macht das Entwicklerleben unendlich viel einfacher! Als Name für den Output-Parameter nutzen wir xml_output. Analog der Eingabe beginnt auch beim Output der Inhalt des Übergabe-XMLs mit einer entsprechenden Root-Node. Ein Unterschied gegenüber des Input-Parameters ist jedoch, dass der Output-Parameter eine fest vorgegebene Struktur hat. Dies erlaubt dem Frontend, auf jede Transaktion gleich zu reagieren und unterstützt so die Entwicklung einer API.

  • success ist entweder true oder false
  • message beinhaltet im Falle success=false immer eine sprachunabhängige Nachricht (i18n)
  • system_message beinhaltet im Falle success=false die technische Fehlermeldung (sofern vorhanden)
  • params gibt zur Verifikation die Übergabeparameter zurück
  • data beinhaltet die Resultate der Abfrage
Im Falle eines Fehlers wäre das Resultat beispielsweise:
<xml_output>
    <success>false</success>
    <message>i18n.MyProject.Common.Error.FatalSqlError</message>
    <system_message>Fatal error while trying to connect to database with jdbc:inetdae:localhost:1433?database=testdb&sql7=true</systemmessage>
    <params>
        <username>holzschuh</username>
        <site>007</site>
        <work_center>Montage01</work_center>
        <amount>23</amount>
        <guid>32165-dsa58-564ds564dfsaf-564dsa</guid>
    </params>
    <data/>
</xml_output>
Im Falle eines erfolgreichen Transaktionsverlaufes hingegen beispielsweise:
<xml_output>
    <success>true</success>
    <message/>
    <system_message/>
    <params>
        <username>holzschuh</username>
        <site>007</site>
        <work_center>Montage01</work_center>
        <amount>23</amount>
        <guid>32165-dsa58-564ds564dfsaf-564dsa</guid>
    </params>
    <data>
        <order_list>
            <item>
                <aufnr>012345678</aufnr>
            </item>
        </order_list>
    </data>
</xml_output>
Anhand der beiden Beispiele wird deutlich, wie leicht die Oberfläche Fehler- und Erfolgsfall verarbeiten kann.