Transport-Requests

Jede Applikation wird einer offenen Transportaufgabe des angemeldeten Benutzers zugeordnet, damit Änderungen ins Test- und Produktivsystem transportiert werden können. Der Designer holt die Liste Ihrer offenen Aufgaben aus dem SAP-System ab.

Transport im App-Anlege-Dialog

Beim Anlegen einer neuen Applikation wählen Sie:

Feld	Hinweis
Paket	Muss im SAP-System existieren – siehe SAP-Pakete.
Transport	Eingabefeld mit Vorschlagsliste und Wertehilfe – enthält die offenen Aufgaben des angemeldeten Benutzers. Pflichtfeld, unabhängig vom Paket (auch bei $TMP).

Die Liste hängt nicht vom gewählten Paket ab. Beim Speichern prüft der Designer, dass die eingetragene Nummer eine dieser Aufgaben ist – sonst erscheint „Die Transportnummer ist ungültig."

Status der Transports

Angeboten werden ausschließlich offene Aufgaben des angemeldeten Benutzers, deren Workbench-Auftrag im aktuellen Mandanten ebenfalls noch offen ist. Freigegebene Aufgaben und Aufgaben anderer Benutzer tauchen nicht auf, weil sie keine weiteren Änderungen mehr aufnehmen können. Einzutragen ist die Aufgabe, nicht der übergeordnete Auftrag.

Transport beim Speichern und Bauen

Der Transport wird nicht bei jedem Speichern bestückt, sondern beim Build: Dann bucht das Backend die App-Definition, die Übersetzungen, Build-Info und Build-Log sowie die BSP-Anwendung der gebauten App auf den Transportauftrag, zu dem die Aufgabe des angemeldeten Benutzers gehört. Speichern und Übersetzungen pflegen schreiben nur in die Tabellen des Mobile Builders und ändern keinen Transport.

Vorgang	Anhang an Transport
Speichern	Kein Anhang – die App-Definition kommt mit dem nächsten Build in den Transport
Übersetzungen pflegen	Kein Anhang – die Texte kommen mit dem nächsten Build in den Transport
Build	App-Definition, Übersetzungen, Build-Info und -Log, BSP-Anwendung der gebauten App
Backend-Klasse generieren	Erzeugte ABAP-Klasse auf der gewählten Aufgabe
Backend Konstanten-Attribute generieren	Kein eigener Anhang – die Attribute werden über die Standard-Klassenpflege in die bestehende View-Klasse geschrieben

Lokale Entwicklung mit $TMP

Für die initiale Entwicklung können Sie die App im Paket $TMP anlegen. Eine Transportaufgabe verlangt der Anlege-Dialog trotzdem – Objekte in $TMP werden aber nicht transportiert, die App ist nur lokal verfügbar.

Produktiv stellen aus $TMP

Wenn Sie eine $TMP-App produktiv stellen möchten, legen Sie sie in einem Z-Paket neu an (die Definition übernehmen Sie über Download und Upload der Meta-Funktionen) und bauen sie dort – erst der Build bucht die Objekte auf den Transport.

Fehlerbild: keine offene Aufgabe

Der Build bricht ab, wenn im Auftrag zur zugeordneten Aufgabe keine offene Aufgabe des angemeldeten Benutzers mehr existiert – etwa weil die Aufgabe bereits freigegeben wurde oder einem anderen Benutzer gehört. Das Build-Log zeigt dann „Für den Transportauftrag <Aufgabe> ist keine offene Aufgabe für <Benutzer> vorhanden“ und „Die SAPUI5-Anwendung <Repository> wurde nicht erfolgreich hochgeladen!“. Lösung:

1. Eine neue Version mit einer offenen Aufgabe anlegen, oder
2. Sperre durch BASIS aufheben lassen

Transport im Designer wechseln

Im Eigenschaften-Panel der App-Wurzel sind Transport und Paket schreibgeschützt. Eine andere Transportaufgabe erhält eine App nur beim Anlegen einer neuen Version – dort fragt der Dialog die Aufgabe ab. Soll eine bereits angelegte Version in einen anderen Transport wandern, ist das eine BASIS-Aktion (über die Transaktion SE03 oder vergleichbare Werkzeuge).

Nächste Schritte

• SAP-Pakete – Paket-Validierung und -Konventionen
• Build & Deployment