Schlüsselfaktoren für den Erfolg von Mobile-Business-Projekten
Kommentare

Eine abstrakte Repräsentation der über die Schnittstelle auszutauschenden Daten lässt sich z.B. durch die in Listing 2 gezeigte, zunächst völlig systemunabhängige Struktur eines Interface-Objects

Eine abstrakte Repräsentation der über die Schnittstelle auszutauschenden Daten lässt sich z.B. durch die in Listing 2 gezeigte, zunächst völlig systemunabhängige Struktur eines Interface-Objects (IFO) erreichen. Nötigenfalls kann die Struktur an die Gegebenheiten des Back-end-Systems angepasst werden, da in der mobilen Komponente Mapping-Mechanismen vorgesehen sind.

Listing 2: XML-Liste abstrakter Datenstrukturen (IFO)
--------------------------------------------------------------------------

          -----base64 codierter string "ifo-xml"-----
       Dekodierter String "ifo-xml":


  auftrag_nrI-05-09370
      task_bezeichnertask_A
   

Die Daten können einerseits mittels eines typfreien Ansatzes durch die WebService-Verbindung geschickt werden. Dabei ist die Verbindung nicht viel mehr als ein Tunnel als Parameter auf SOAP-Ebene wird nur ein einzelner String übergeben. Andererseits bietet sich der typisierte Ansatz an, in dem die einzelnen Werte als Parameter des Web-Service-Aufrufs spezifiziert sind. Die Abwägung ist hier zwischen Flexibilität und Fehlersicherheit der Schnittstelle zu treffen. Der typfreie Ansatz erlaubt es, die Definition der Schnittstelle unverändert beizubehalten. Typ- und Mappinginformationen für die einzelnen Datenfelder des XML-Strings werden in den Systemen zur Laufzeit interpretiert. Durch Änderung dieser Konfiguration können Datenfelder leicht verändert oder hinzugefügt werden. Da bei diesem Ansatz ein vollständiger XML-String als Argument in einem weiteren XML-String (dem SOAP-Envelope) verschickt wird, kann es zu Unterschieden im Encoding kommen. Dies sollte vermieden werden, da nicht alle Werkzeuge fehlerfrei mit derartigen Situationen umgehen können. Der typisierte Ansatz entspricht dagegen dem gängigen Vorgehen bei Verwendung von Code-Generatoren, die aus internen Datenstrukturen einen XML-Datenstring generieren. Derartige Funktionalität findet sich bei allen gängigen ERP-Systemen wie z.B. Navision oder SAP, aber auch bei vielen Branchenlösungen lassen sich relationale Strukturen direkt in entsprechende XML-Strings konvertieren.

In Listing 3 sind die beiden Varianten jeweils mit dem Soap-Aufruf dargestellt. 

Listing 3
3a: Nicht typisierte Version (mit Header)
-----------------------------------------------------------------------------------

           -----base64 codierteer string "table-object-xml"-----
        Dekodierter String "table-object-xml":
----------------------
DW_CIP_EDIT_HEAD
I-05-093701crea_pers_id I-05-09370nochar(30)auftragauftrag_nrDW_CIP_TASK
I-05-093701task_id task_Anochar(30)tasktask_bezeichner 3b: Typisierte Version (mit Header) ---------------------- I-05-09370task_A

Während in 3a die Datenfelder über das -Attribut definiert sind, werden sie in 3b explizit als Parameter definiert. Die Referenzierung auf die eigentlichen Datenfelder wird in 3a zudem noch über eine Indirektionsstufe mit -Referenzen in den Daten selbst (und nicht deren Beschreibungen) festgelegt. Allerdings muss das entsprechende Format händisch erstellt werden. In 3b ist dagegen die klare Struktur definiert, die eine solche Flexibilität nicht aufweist, sich aber über eine entsprechende WSDL automatisiert generieren und befüllen lässt. Neben dem XML-Format sollte das Mapping in mehrfacher Hinsicht betrachtet werden:

  • Mapping von Bezeichnern sind meist erforderlich und erlauben, Daten in die richtigen Datenfelder einzutragen
  • Formate müssen gemappt werden, weil es oft keine automatische Formatübermittlung (z.B. Zahlenformate oder Auswahllisten) aus den Back-end-Systemen gibt
  • Strukturen sind ggf. erforderlich, falls die mobile oder Back-end-seitige Anwendung nicht mit flachen Tabellen, sondern mit Objekten arbeitet. Falls notwendig müssen solche Objekte dann über das Mapping auch als solche instanziiert sowie Hierarchieabhängigkeiten angelegt werden

In komplexen Situationen kann es erforderlich sein, nicht nur ein, sondern mehrere Back-end Systeme zu beliefern. Dann sollte über eine Orchestrierung der Dienste im Sinne eines SOA-Ansatzes nachgedacht werden.

Fehlerschnittstellen sind wichtig

Neben der reinen Funktionalität lebt eine Schnittstelle von der korrekten Fehlerbehandlung. Einerseits können Fehler durch eine temporäre Problematik entstehen (Komponenten stehen z.B. nicht zur Verfügung). In diesem Fall muss die Information zwischengespeichert werden, sodass die Daten dann bei einem erneuten Versuch mit übertragen werden. Wichtig ist dabei auch, die Reihenfolge der Übertragung einzuhalten, also ein FIFO-Prinzip anzuwenden. Andererseits gibt es endgültige Fehler (syntaktisch falsche E-Mail-Adresse wird z.B. vom E-Mail-Server abgelehnt). Diese müssen aus dem normalen Workflow entfernt und an das Back-end-System gemeldet werden, damit manuell eingegriffen werden kann. Sicherheitshalber sollten solche Daten auch innerhalb der mobilen Komponente gespeichert bleiben, damit die geänderten Daten erneut über die Schnittstelle übertragen werden können. Nicht minder wichtig ist der Aspekt, dass Fehler auf verschiedenen Ebenen auftreten können. Es gibt mindestens drei Ebenen, auf denen Fehler erkannt und behandelt werden müssen:

  • Im SOAP-Envelope werden Fehler gemeldet, wenn schon im Applikationsserver Probleme erkannt werden
  • In den Inhalten der SOAP Nachricht können ebenfalls Fehlermeldungen kommuniziert werden
  • Letztlich können auch logische Fehler auftreten, wenn z.B. ein Auftrag #n übermittelt, aber als #m bestätigt wird

Insbesondere für die Fehlermeldung aus den Komponenten sollte ein klares Format mit entsprechenden Feldern vereinbart werden, um die Erkennung von Fehlerzuständen zu verbessern. Ein Vorschlag zu den Daten ist in Listing 4 enthalten.

Listing 4: Parameter in der Fehlermeldung
--------------------------------------------------------------------------
- Typ
- Zeitstempel
- Fehlercode
- Fehlertext
- Fehlerlevel
- Komponente
- User

Dieser erlaubt es, einen realitätsnahen Workflow umzusetzen, in dem der Disponent Fehler direkt im Dispositionssytem erkennen kann und den Techniker (erkennbar am Parameter User) gegebenenfalls auch direkt ansprechen kann. Die „Uhrzeit“ dient dem schnellen Finden von Meldungen und die „Komponente“ bestimmt im weiteren Workflow, an welche Stelle gegebenenfalls eine Supportanfrage zur Behebung des Fehlerzustandes zu adressieren ist. Natürlich gäbe es zum Thema noch vieles anderes zu sagen, z.B. die Wichtigkeit von Workflows auf dem Client, die Unterschiede im GUI-Design zwischen PDA und Desktop- Anwendungen oder die Berücksichtigung von Performance-Gesichtspunkten. Aber schon die Einbeziehung der hier skizzierten Überlegungen in das Anwendungsdesign wird wesentlich zur Erstellung erfolgreicher Anwendungen beitragen.

Steffen Brandhorst designt und entwickelt bei der KI AG Schnittstellen für mobile Anwendungen. Joachim Lechelt arbeitet seit mehreren Jahren bei der KI AG als Lösungsarchitekt für mobile Anwendungen.
Unsere Redaktion empfiehlt:

Relevante Beiträge

Meinungen zu diesem Beitrag

X
- Gib Deinen Standort ein -
- or -