Moombas liegt 100 prozentig richtig.
Du sprichst vermutlich von den üblichen SAPGUI. Normalerweise kann die SAPGUI Makros aufzeichnen und die wiederum treiben bspw. einen Art BatchInput. Das übliche Szenario in dem Zusammenhang ist der Batch Input.
Mit SAPGUI ist es wie mit dem Excel, dort kennen sie alle mit den 2% die sie gewohnt sind aus. Wenn die SAP meint ein Batch Input gehört so gemacht, dann ist das auch so. Alles andere ist denen an sich mal egal. Über ein externes Programm SAPGUI auszufüllen ist mal nicht vorgesehen. Darum gehts es. Batch Input ist eine ein sich geschlossene Technologie.
Das Fernsteuern von der SAPGUI geht bspw. mit der Implementierung von Patrick Theobald (ERPConnect.net) in .net sehr gut. Allein bekommst du das Problem, dass die zugrunde liegende library blockierende Calls macht und wenn die hängen bleiben, dann wirst du die Session nicht mehr von Seiten des aufrufenden Programms los. Mein Stand ist ca. 7 Jahre alt.
Die Frage ist ob du, wenn du schon meinst dich in dem Eck engagieren zu wollen, ob du das Problem nicht umdrehen kannst, sodass du einen exteren
RFC Server schreibst. Du erzeugst bspw. mit Hilfe von Connect for SAP von gs-soft, ERP-Connect.net oder den Connectoren in .net oder Java (falls es die noch gibt, vermutlich ja) einen 'Server'/eigene Executable auf den sich ein bspw. ABAP Programm laufend aus dem SAP raus zu dem Executable verbindet und du gibst ihm die Daten zurück. Darauf wird sich vermutlich der Admin nicht so wirklich stehen, aber gut.
Zum externen
RFC Server: Du baust in deinem Executable einerseits die MetaInfo (Funktionsprototypen) und befüllst die Elemente wie Parameter und Tabellen. Am Ende wird alles in einem großen Block aus Bytes zusammengewurstelt der auf Aufrufseite aufgrund der MetaInfo ausmaskiert wird. Das SAP System betrachtet deine Executable als anderes SAP System und ruft wie gewohnt remote eine Funktion auf. Ungewohnt ist ein wenig, dass im Zuge des Befüllens der kurz zuvor genannten Elemente die Funktion gleich mitgebaut wird (sprich on the fly/dynamisch).
Das Thema ist in
einer PDF von gs-soft am Ende zu finden, aber zur Orientierung kann man sich den Teil von vor zuvor auch geben.
Der Rest kann in der Hölle auf Erden enden, wenn du nicht viel mit SAP zu tun hast oder auf jeden Fall 'Well it depends', je nachdem was du machen willst.
Normalerweise müsste dir jemand am SAP System eine Funktionsbaustein bauen, den du benutzt und regelt Berechtigung usw. Meine Erfahrung ist allein, wenn die Anforderung mal in Richtung SAP
GUI remote steuern geht, dann gibt es den nicht oder er oder sie hat keine Zeit. Aber was der Grund.
Ich habe leider keinen Zugriff mehr auf ein SAP System, nicht mal mehr ein 'MiniSAP' und wäre auch nurmehr auf Stand 7 (sprich vor ein paar Jahren).
Meine letzt im Implementierung im Lab war 2005 bis 2006 ein auf Remobjects basierender Appsever der die Funktionsaufrufe skalierte, da zu dem Zeitpunkt die gepufferten Funktionsaufrufe (im Stile des Remote Function Calls) nicht zur Verfügung stand. Das Problem war, dass keine erlaubt hat die Security Information zu replizieren, was bei SAP Produkten untereinander hernach gang und gebe wurde (externen BI Tools). Der Ingeniör hat's nun mal schwör.
Könne die Typen nicht ein Service Schnittstelle aufmachen ala
SOAP. Die Typen könnten sich das generieren lassen und dir gegebenebfalls eine
WSDL zukommen lassen.
Hallo Moombas,
genre mache ich es gleich richtig. Hast du einen Link mit Informationen oder eventuell sogar Programmbeispiele für mich ? Das wäre super.
Danke Tanja