Webservice Performance

[Fuerchau]

Dein Problem ist hier nicht ILERPG sondern die statische Definition der Schnittstelle (dein XSD-Schema).

Wenn du nun hier eine dynamische Struktur definieren könntest muss doch irgendwo die Anzahl der Positionen übergeben werden, sonst ist es keine dynamische Struktur.

In ILERPG wird ja nur ein Pointer übergeben, so dass du nur die Anzahl der Positionsstrukturen auswerten musst um eben auf nur diese Adressen zuzugreifen.

Mittels Pointer und Pointerarritmetik kann man die DS auch sehr variabel bearbeiten.

Wobei ich immer noch nicht glaube, dass die Performance von der Größe der Struktur abhängig ist.

Vielleicht verbrät dein Programm ja die Zeit irgendwo unnötigerweise.
Andere Web-Services arbeiten ja auch bei großen Datenmengen nur im Sekundenbereich.
Gib mal eine Logdatei mit Timestampwerten zwischen Aufruf und Return aus, oder wie ermittelst du die Zeiten?

[ThomasSprenger]

Also die gesamt Zeit ermittle ich über SOAP UI 4.0 -> es gibt die Zeit im Millisekunden für einen Zugriff an. Mit SOAP UI Teste ich auch.

Die Programmverarbeitung denke ich ist es nicht, da die Verarbeitung in meinem Test-PGM sehr Übersichtlich ist:

C *entry plist
C parm structCart
C parm ErrorO
/free
eval structCart.nGross_Total= 20;
eval STRUCTCART.ACSUB_CART.ACVATS_TOTAL(1).NVAT_AMOUNT = 1;
eval STRUCTCART.ACSUB_CART.ACVATS_TOTAL(2).NVAT_AMOUNT = 2;

eval ErrorO.ErrorFlag = *blank;
eval ErrorO.ErrorText = *blanks;
// *inlr = *on;
return;

Ansonsten werden nur Parameter ein und ausgegeben.

Das Original PGM mit Verarbeitung braucht nur unwesentlich länger.


Da ich Client und Server auf 2-Systemen habe kann ich folgende Zeitmessung nur über stoppen machen: Lasse ich mir im Test-PGM einen MSG schicken, dauert der Vorlauf ungefähr genau solang wie der Nachlauf (7,5 zu 8,5 Sekunden).

-------------------------------
Dein Problem ist hier nicht ILERPG sondern die statische Definition der Schnittstelle (dein XSD-Schema).

Wenn du nun hier eine dynamische Struktur definieren könntest muss doch irgendwo die Anzahl der Positionen übergeben werden, sonst ist es keine dynamische Struktur.
--------------------------------------

Das sehe ich auch so. die Automatisch kreierten Javaklassen der AS/400 für diesen Webservice scheinen die fehlenden Werte automatisch aufzufüllen da sie Statisch sind, nur wie teile ich dies meinem Kind - sprich der AS/400 mit? dass ich nur die übergebenen Werte brauche?

Hier habe ich keine Idee wie eine DS aussehen könnte das die AS/400 dies für den Webservice als variables XSD-Schema erkennt oder interpretiert.

[BenderD]

... das ist das Spielzeug, von dem ich sprach. Von RPG bottom up, das wird nix!
Wenn man das ordentlich machen würde, dann würde man von der WSDL top down gehen, dann hat man die größere Mächtigkeit für die Schnittstelle. Da brauchts dann aber einen Java oder .NET Programmierer; wenns denn unbedingt sein muss, kann der dann auch noch ein RPG Programm aufrufen, damit die Grüngesichter auch ein wenig Spass haben.

D*B

[ThomasSprenger]

Tja, nur das Problem ist halt - In Java muss alles neu programmiert werden was in RPG schon da ist - Aber wenn es so weiter geht, werde ich wohl einen Webservice in Java schreiben müssen.
Was schade ist, den von der Basis her ist der Webservice mit RPG eigentlich sehr einfach und mit RPG-Wissen zu gestalten.

Es hakt halt nur an ein paar Ecken. Vielleicht werden die ja auch noch abgeschliffen.

[AS400.lehrling]

Lassen sich die "alt" PGM nicht via Programm Aufruf durch Java in alt gewohnter weise benutzen ?

Weiß ja nicht ob ich nun zu einfach denke, aber ein PGM das "nur" aus Aufrufen anderer PGM besteht sollte doch auch in Java recht schnell zu schreiben sein.

Das Ganze als Server App auf der i & alles mit Java WebPlugin kann es Benutzen.

Gruß AS400.lehrling

[BenderD]

... naja, die blanke Hülle kriegst du ja aus der WSDL generiert und die kann ja dann die RPG Funktionen referenzieren (als stored Procedure z.B.)

D*B

Tja, nur das Problem ist halt - In Java muss alles neu programmiert werden was in RPG schon da ist - Aber wenn es so weiter geht, werde ich wohl einen Webservice in Java schreiben müssen.
Was schade ist, den von der Basis her ist der Webservice mit RPG eigentlich sehr einfach und mit RPG-Wissen zu gestalten.

Es hakt halt nur an ein paar Ecken. Vielleicht werden die ja auch noch abgeschliffen.

[holgerscherer]

Die Struktur der Schnittstelle nach aussen ist leider duch den WebServiceClient (Onlineshop) vorgegeben.

Wie wärs denn mal mit Net.Data? Jaja, Leichen reanimieren, aber langsamer wird das nicht sein

-h

[BenderD]

... zu Net.Data kann ich mich nicht äußern, da fehlt mir sowohl Kenntnis als auch erst recht Erfahrung. Aber vielleicht nochmal ein paar Grundlagen zu WebServices und deren Implementierung.
Bei einem WebService git es eine Kette von Schichten, die von der Implementierung bis zur WSDL reicht. Der Punkt, wo sich die Spreu vom Weizem teilt ist: Top down oder Bottom up und das ist in erster Linie ein Problem der verfügbaren Tools!!! Die volle Bandbreite hat man, wenn man mit der WSDL anfängt, natürlich kann man jetzt mit CGI Programmen sich ein XML um die Ohren hauen lassen und das mit was auch immer auseinanderfusseln und da was zusammen basteln, wenn die Schnittstelle einfach genug ist, kriegt man das auch hin. Genau bei den Fragen wie hier - variable Anzahlen von Wiederholungsgruppen - fangen dann die Probleme an, die hier keineswegs aufhören, eine WSDL Schnittstelle kann weit komplizierter sein!
Dann gibt es Zauberkästen, vergleichbar mit Zauberkästen, die man für 20 € kauft und 8 jährigen zu Weihnachten schenkt, die können ganz einfache WebServic Schnittstellen erstellen, meist bottom up, da steckt man oben einen RPG Prototyp rein und bekommt unten einen WebService raus, die können dann soviel, wie ein RPG Prototyp kann - und der kann nicht soviel, wie hier ja gerade diskutiert wird.
Macht man das z.B. mit Java, dann gibt es in Eclipse plugins, die einem da viel abnehmen; da kann man aus der WSDL eine Dummy Implementierung (einen Skeleton) generieren, den man dann nur noch füllen muss. Das ist einfach und frei verfügbar, nicht zuletzt dadurch Mainstream, was einigermaßen sicherstellt, dass das in 5 Jahren auch noch so geht und einigermaßen zuverläsig funktioniert. Bei .Net ist die Lage ähnllich, da kauft man das alles zusammen für eine überschaubare Gebühr von Herrn Gates und befindet sich dann auch da im Mainstream.

D*B

PS: Bei der Verwendung sieht das wieder ganz ähnlich aus, aber das ist ein anderes Thema.

[ThomasSprenger]

Vielen Danke an alle,
dann werde ich wohl meine WSDL nehmen und mal alles TOP-Down mit Java erstellen. Dort dann die benötigten RPG- Programme aufrufen.
Kann ja dann meine Erfahrungen hier dazu posten.

[BenderD]

... dazu noch ein paar Tipps:
- das PCML Geraffel für Aufrufe würde ich generell vermeiden
- wenn die genug können dann die RPG Programme als stored Procedures einpacken
- die List Problematik kann man dann auch durch mehrfach aufrufen mit einem more Flag als zusätzlichem Parameter abbraten, wenn man nicht gleich EInzelaufrufe draus macht und den Rest der Logik ins Java schiebt.
- immer überlegen, ob der RPG Einsatz überhaupt Sinn macht; meist mangelt es an einsetzbaren Komponenten, die diesen Namen verdient haben und beim neuprogrammieren bricht man sich im RPG oft die Finger ab, für Dinge die in Java einfacher, mit weniger Aufwand und besser zu erledigen gewesen wären.

D*B

[ThomasSprenger]

Das sind RPG-Module die die Verfügbarkeit von Artikeln ermitteln oder bei Produktion berechnen, + den Preis Incl. Konditionen und Fracht.

Das nach zu programmieren, würde dann den Rahmen sprengen ;-).

[BenderD]

... wenn das Komponenten sind, ist das völlig in Ordnung, In diesem Fall ist es ja auch so, dass das alles politisch abgenickt ist und jede Änderung des Wahrheitsgehaltes (egal ob richtiger oder falscher) bei Neuprogrammierung problematisch ist.
Da sollte nur dann in der neuen Anwendung die technologische Seite der (Alt) Komponenten gekapselt werden.
(in Java: komplett eigenes Package für die Bedienung der Komponenten und Facade Objekte als Proxy in der Java Applikation).

D*B