2016-04-12 11 views
0

Wir arbeiten an einem SAP ICF-Dienst (HTTP), mit dem mobile Geräte Funktionsbausteine ​​über eine XML-Schnittstelle aufrufen können. Das angegebene XML enthält Daten darüber, welcher Funktionsbaustein aufgerufen werden soll und welche Parameter verwendet werden müssen. Immer wenn der Funktionsbaustein beendet ist, wird das Ergebnis zurück an das mobile Gerät gesendet. Wir verwenden einen IF_HTTP_EXTENSION Handler.Verhindern, dass SAP ICF die Ausführung beendet, wenn der Client die Verbindung trennt

Das Problem ist, dass das mobile Gerät jedes Mal, wenn das Ausführen des Funktionsbausteins lange dauert, ein Timeout auslöst und dann die Verbindung schließt, die Verbindung erneut herstellt und die Anforderung erneut sendet. Wann immer dies geschieht, wird die handle_request Methode des IF_HTTP_EXTENSION Handlers sofort beendet. Aber wir müssen die Ausführung der aufgerufenen Funktion fortsetzen, da der Client die Anfrage mit der gleichen Sequenznummer erneut sendet. Also rufen wir die eigentliche Funktion nicht zweimal auf, sondern eine "Warte" -Methode, die darauf wartet, dass die zuvor aufgerufene Funktion beendet wird. Wir tun dies durch regelmäßige Überprüfung der Datenbank (WHILE Schleife mit WAIT UP TO 2 SECONDS in jeder Iteration).

Solange der Client nicht Timeout, möchten wir die Antwort so schnell wie möglich senden. Deshalb ist es in der ersten Anfrage nicht angebracht, eine While-Schleife mit 2 Sekunden Verzögerung zu machen.

Unsere aktuellen Ansatz ist die folgende (in handle_request):

CALL FUNCTION 'CLIENT_DESIRED_FUNCTION' 
    STARTING NEW TASK l_client_id 
    CALLING processing_finished ON END OF TASK 
    EXPORTING 
     ... 

Danach warten wir auf seine Fertigstellung von:

WAIT UNTIL a_running <> 'X'. 

Aber, sobald der Client die Verbindung trennt, die angerufene Funktion (und die handle_request Methode auch) beendet.

Wenn wir die CALLING processing_finished ON END OF TASK entfernen, wird die Funktion tatsächlich fortgesetzt! Dies ist unser gewünschtes Verhalten. Es gibt jedoch keine Möglichkeit, auf das Ende der Funktion zu warten, da die WAIT UNTIL-Anweisung mit sy-subrc = 4 (keine asynchronen RFC-Funktionsaufrufe) zurückkehrt.

Wir könnten einfach eine einfache WHILE - WAIT UP TO 2 SECONDS -loop verwenden, aber dann haben wir die Verzögerung, die wir wirklich verhindern wollen. Eine andere Lösung, über die wir nachgedacht haben, war, einen HTTP-Code 102 direkt vor dem Timeout an den Client zu senden. Aber das ist keine gute Lösung, da das mobile Gerät ohne Netzwerk sein könnte und dann nicht die 102 in der Zeit erhält.

Gibt es eine Möglichkeit zu verhindern, dass SAP ICF die Methode handle_request beendet ODER Ist es möglich, effizient auf die asynchrone Task zu warten, ohne den Parameter CALLING ... ON END OF TASK zu verwenden?

Mit freundlichen Grüßen Tobias

Antwort

0

Ich habe den Code nicht zur Hand, aber ich habe dieses Problem gelöst vor, wenn SAP-Gateway war nicht herum und Sie hatten Ihre eigenen REST-Services zu bauen.

Ich verwendete ein Timeout für die Verarbeitung von 2 Sekunden. Nach dieser Zeit muss der Server mit etwas antworten. Wenn die Verarbeitung nicht beendet ist (mit dem async-Funktionsbaustein), antwortet der Server mit HTTP-Status 202 akzeptiert. Der Client kann dann zu einem späteren Zeitpunkt eine weitere Anfrage senden und nach dem Status der vorherigen Anfrage fragen.

Dieses Muster hat sehr gut funktioniert. Der Frontend-Entwickler verwendete ein Async-Modell für alle Anfragen und erstellte eine Anwendung, die selbst bei unterschiedlichen Antwortzeiten in SAP keine Verzögerungen aufwies. Als Beispiel könnte das Begehen eines Kundenauftrags während der Stoßzeiten 1 bis 15 Sekunden dauern.

+0

Dies war unsere erste Lösung. Leider funktioniert das Senden einer "Ich mache etwas" -Nachricht an das mobile Gerät nicht, da der Client ohne Netzwerk sein könnte und daher diese Nachricht nicht empfängt und trotzdem die Verbindung schließt. Wir wissen, dass ein Kunde, der unsere Technik nutzen möchte, eine schlechte WLAN-Abdeckung hat. Die Benutzer müssen nicht warten, da die Clients diese Anfragen asynchron senden können, wie Sie auch vorgeschlagen haben :-). Vielen Dank für Ihren Vorschlag, aber dies funktioniert nicht in unserem Fall, aufgrund der Verbindung Behavior der mobilen Geräte. :-( –

+0

Jedes Mal, wenn der Client eine Anfrage an den Server sendet, erhält er sofort eine Antwort. Die Antwort lautet 201 Accepted - wird dem Kunden als "Wir haben Ihre Anfrage erhalten und beginnen mit der Verarbeitung. Bitte überprüfen Sie später wieder. ". Wann immer der Client die zweite Zeit verbindet, ist irrelevant, da Sie den Status der ersten Anfrage überprüfen können. Am wahrscheinlichsten wird er verarbeitet und eine korrekte Antwort kann ausgegeben werden. Dieses Muster soll gelegentliche Verbindungsunterbrechungen und Clients mit hoher Latenz behandeln für den mobilen Einsatz. –