Mit dem BAPI Create() wird eine einzelne Instanz eines SAP-Business-Objekttyps erstellt. Analog hierzu legt das BAPI CreateMultiple() gleichzeitig mehrere Instanzen eines Business-Objekttyps an.

Gibt es an dem betreffenden Business-Objekttyp bereits eine Workflow-Methode mit dem Namen Create(), können Sie für Ihr BAPI den Namen CreateFromData() verwenden. Der bevorzugte Name für dieses BAPI ist jedoch Create().

Das BAPI Create() bzw. CreateMultiple() ist eine Klassenmethode (instanzunabhängig).

Zu jedem Create()-BAPI muß eine Methode bereitstehen, mit der die erstellte Business-Objektinstanz gelöscht bzw. storniert werden kann. Hierzu sollten Sie, abhängig von der betriebswirtschaftlichen Anwendungspraxis, eines der folgenden BAPIs implementieren:

• Delete(), mit dem eine Business-Objektinstanz von der Datenbank gelöscht wird

• Cancel(), mit dem eine Business-Objektinstanz storniert wird

Bei der Festlegung der Import-Parameter sind folgende Aspekte zu beachten:

• Das BAPI enthält als Import-Parameter im Funktionsbaustein die Daten, die benötigt werden, um eine Instanz eindeutig zu identifizieren. Die betriebswirtschaftlichen Schlüsselinformationen können vollständig mitgegeben werden, müssen aber zumindest ableitbar sein. Da es sich um Klassenmethoden handelt, darf keines der BOR-Schlüsselfelder ein Parameter im Funktionsbaustein bzw. des BAPIs sein.

• Das BAPI muß zusätzlich einen TestRun-Parameter besitzen, der es ermöglicht, Testläufe durchzuführen. Ist dieser Parameter mit dem Wert "X" gefüllt, wird das BAPI zwar normal abgearbeitet, die Ergebnisse werden aber nicht vom BAPI in den Verbucher geschrieben. Somit können nach Ausführen des BAPIs BapiService.TransactionCommit sämtliche Ergebnisse, wie beispielsweise der Application Log, ausgewertet werden, die Datenbank bleibt aber vom BAPI unberührt.

• Soll einem Kunden die Möglichkeit gegeben werden, die Import-Parameter des BAPIs modifikationsfrei zu erweitern, so ist der Parameter ExtensionIn anzulegen.

Bei der Festlegung der Export-Parameter sind folgende Aspekte zu beachten:

• Um dem aufrufenden Programm den Objekt-Handle zur Verfügung zu stellen, müssen in den Export-Parametern des Funktionsbausteins die Schlüsselfelder vollständig zurückgegeben werden. D.h., Sie legen pro Schlüsselfeld des Objekttyps einen gleichnamigen Export-Parameter am Funktionsbaustein an, der mit den entsprechenden Werten gefüllt wird. Diese Schlüssel-Parameter müssen den gleichen Namen besitzen wie die zugehörigen Schlüsselfelder des Objekttyps im BOR.

• Zusätzlich können weitere Export-Parameter angelegt werden, in denen beispielsweise generisch erzeugte Informationen zurückgegeben werden.

• Wird das Create()-BAPI erfolgreich abgearbeitet, also eine Instanz angelegt, muß im Return-Parameter folgende standardisierte T100-Nachricht übergeben werden:

• Das Feld MESSAGE_V1 enthält den externen Namen des zugehörigen Business-Objekttyps, wie z.B. SalesOrder.
• In dem Feld MESSAGE_V2 wird derjenige Schlüssel zurückgegeben, unter dem auf das erzeugte Objekt bei weiteren Aufrufen zugegriffen werden kann. Dies ist entweder bei externer Nummervergabe der mitgegebene externe Schlüssel oder bei interner Nummernvergabe der neu angelegte interne Schlüssel. Besitzt das Objekt mehrere Schlüsselfelder, dann müssen die Werte dieser Schlüsselfelder in MESSAGE_V2 konkateniert werden. Bei der Konkatenation ist die diejenige Reihenfolge einzuhalten, in der die Schlüsselfelder im BOR definiert sind. Außerdem muß für jedes Schlüsselfeld die maximale Länge verwendet werden, so daß u.U. ein Auffüllen notwendig ist.

• In MESSAGE_V4 wird der korrespondierende Schlüssel zurückgegeben, sofern dieser existiert. Dies kann derjenige Schlüssel sein, unter dem das Objekt in einem Fremdsystem abgelegt ist, wie z.B. die externe Materialnummer. Das Füllen dieses Feldes dient lediglich der Identifizierung und nicht dem Zugriff auf das Objekt. Besteht der korresponierende Schlüssel ebenfalls aus mehreren Feldern, dann müssen diese in der gleichen Weise konkateniert werden.

• Tritt bei der Abarbeitung des Create()-BAPIs ein Fehler auf, ist neben den anwendungsspezifischen Fehlermeldungen folgende standardisierte T100-Nachricht im Return-Parameter zu übergeben:

• Neben der standardisierten Meldung können weitere Meldungen in den Return-Parameter geschrieben werden.

• Insbesondere im Fehlerfall müssen Meldungen zurückgegeben werden, die den Fehler konkret beschreiben. Deshalb sollte der volle Funktionsumfang des Typs BAPIRET2 Verwendung finden. Insbesondere sollten die Felder Parameter, Row und Field gefüllt werden.

Ein Create()-BAPI muß so implementiert werden, daß es möglich ist, mehrere Aufrufe derselben Create()-Methode innerhalb einer LUW abzusetzen und somit mehrere Instanzen des gleichen Objekttyps in einer LUW zu erzeugen.

Um einerseits zu erreichen, daß mehrere Instanzen des gleichen Objekttyps innerhalb einer LUW angelegt werden können und andererseits eine hohe Performance zu gewährleisten, sollten die Ergebnisse eines Create()-BAPIs bis zu ihrer Verbuchung im Verbucher gebündelt werden.
Dazu ruft das BAPI nach erfolgreicher Abarbeitung der Anwendungslogik einen Verbuchungsbaustein "IN UPDATE TASK" auf. Diese Verbuchungsbausteine stoßen die Datenbankzugriffe nicht direkt einzeln an, sondern die durchzuführenden Operationen werden jeweils im Funktionsgruppenspeicher zwischengespeichert und anschließend in einer Formroutine indirekt "ON COMMIT" aufgerufen. Somit wird diese Formroutine nur einmal durchlaufen und kommt durch Techniken wie Array-Insert mit nur einem Datenbankzugriff für die Verbuchung aus.

Es ist möglich, daß bestimmte Werte durch das Customizing festgelegt werden, jedoch an der BAPI-Schnittstelle weiterhin als variabel erscheinen. Diese Werte dürfen von einem Create()-BAPI nicht überschrieben werden.

Um Konflikte mit Customizing-Einstellungen zu vermeiden, sollten Sie ein Create()-BAPI folgendermaßen implementieren:

• Das BAPI sollte alle Felder übernehmen und gegen die Customizing-Einstellungen prüfen. Wenn ein Feld durch entsprechende Customizing-Einstellungen schreibgeschützt ist, darf dieser Wert nicht durch einen Wert aus der BAPI-Schnittstelle überschrieben werden.

• Für jeden Konfliktfall muß im Return-Parameter des BAPIs eine Nachricht vom Typ "Error" an die aufrufende Anwendung zurückgemeldet werden, z.B. "Feld 'MyAsset-AssetName' laut Customizing nicht änderbar".

• Alle Felder, die eventuell über das Customizing mit Default-Werten vorbelegt und daher schreibgeschützt sind, müssen entsprechend dokumentiert werden.

Bei einem Create()-BAPI mit externer Schlüsselvergabe übergibt der Aufrufer den Schlüssel (ID) der zu erzeugenden Objektinstanz, z.B. eine Belegnummer.

Wichtig: Diese Parameter für den externen Schlüssel dürfen nicht den gleichen Namen haben wie die Schlüssel des Objekttyps im BOR, da sonst das BAPI fälschlicherweise als Instanzmethode identifiziert werden würde. Außerdem müssen auch weiterhin die im BAPI erzeugten Schlüssel als Export-Parameter definiert werden.