REST Webservice aus SRVPGM Error 404

[Malte]

Hallo alle zusammen,

Ich versuche mich grade an 2 für mich neunen Sachen in einem.

Ich muss für ein Externes Programm einen Webservice erstellen der 3 vor definierte Funktionen hat und über HTTP angesprochen werden kann.

Also ein REST Webservice mit SRVPGM dahinter.

Nun Habe ich ein Folgendes Modul erstellt

       ctl-opt nomain;       
       ctl-opt pgminfo(*pcml:*module:*dclcase);
       ctl-opt datfmt(*iso);
       ctl-opt alwnull(*usrctl);
      
       dcl-c hk const('''');


       dcl-proc GetQueries export;
          dcl-pi *n;
             result varchar(500000);
          END-PI;
          result = ''
                 + %trim(lpTag('Query':'GetLagH':'Single'))
                 + '';


          return;
       end-proc;

        
       dcl-proc GetQueryInfo export;
          dcl-pi *n
             queryName varchar(500000);
             result varchar(500000);
          END-PI;


          result = '';


          Select;
            when queryName = 'GetLagH';
               result = %trim(result)
                      + %trim(lpTag('Parameter':'ItemNumber':'String'));
          ENDSL;



          result = %trim(result) + '';


          return;
       end-proc;


       dcl-proc GetData export;
          dcl-pi *n;
             query varchar(500000);
             result varchar(500000);
          END-PI;


          result = 'Hallo Welt';


          return;
       end-proc;

Diese kann ich auch wunderbar kompilieren und mit hilfe dieses Zusatzes in ein SRVPGM umwandeln

     STRPGMEXP  PGMLVL(*CURRENT) SIGNATURE('B_PERFIWS')               
                  EXPORT     SYMBOL('GETQUERIES')
                  EXPORT     SYMBOL('GETQUERYINFO')
                  EXPORT     SYMBOL('GETDATA')
     ENDPGMEXP

Hier der Befehl mit dem ich dan das Servic Programm erstellt habe

CRTSRVPGM SRVPGM(*LIBL/SRVPERFION) MODULE(*LIBL/PERFIONWS) SRCFILE(*LIBL/QSRVSRC) SRCMBR(PERFIONSRV)

Dann Webservice als REST erstellt bei den Funktionen wie folgt definiert:

Prozedurnamen:	GETDATA
HTTP-Anforderungsmethode:	POST
URI-Pfadvorlage für die Methode:	*NONE
HTTP response code output parameter:	*NONE
HTTP header array output parameter:	*NONE
Zulässige Eingabemedientypen:	*XML_AND_JSON
Zurückgegebene Ausgabemedientypen:	*XML_AND_JSON

Eingabeparameterzuordnungen: Parametername Datentyp Input source Kennung Default Value query struct *NONE

Prozedurnamen:	GETQUERYINFO
HTTP-Anforderungsmethode:	POST
URI-Pfadvorlage für die Methode:	*NONE
HTTP response code output parameter:	*NONE
HTTP header array output parameter:	*NONE
Zulässige Eingabemedientypen:	*XML_AND_JSON
Zurückgegebene Ausgabemedientypen:	*XML_AND_JSON

Eingabeparameterzuordnungen: Parametername Datentyp Input source Kennung Default Value queryName struct *NONE

Prozedurnamen:	GETQUERIES
HTTP-Anforderungsmethode:	GET
URI-Pfadvorlage für die Methode:	*NONE
HTTP response code output parameter:	*NONE
HTTP header array output parameter:	*NONE
Zulässige Eingabemedientypen:	*XML_AND_JSON
Zurückgegebene Ausgabemedientypen:	*XML_AND_JSON

Aber wenn ich den WS versuche aufzurufen über die IP
http://myIP:myPort/web/services/Perf...Api/GetQueries

Bekomme ich immer ein HTTP Error 404 (über SOAP ui rausgefunden)

Und ich hab mittlerweile keine Idee mehr warum ich hier kein Result bekomme

Vielen Dank schon mal ich hoffe mir kann jemand helfe und es ist nur eine dumme Kleinigkeit

MfG Malte

[Malte]

Hallo *all,

ich hab es mittlerweile so weit hin bekommen das ich ich die Methoden ansprechen kann.

bei mir war das Problem das ich bei URI-Pfadvorlage den Pfad nicht erweitert habe
Also jetzt sieht das so aus :

Prozedurnamen:	GETDATA
HTTP-Anforderungsmethode:	GET
URI-Pfadvorlage für die Methode:	GetData/{request}
HTTP response code output parameter:	*NONE
HTTP header array output parameter:	*NONE
Zulässige Eingabemedientypen:	*ALL
Zurückgegebene Ausgabemedientypen:	*JSON

Eingabeparameterzuordnungen: Parametername Datentyp Input source Kennung Default Value query char *PATH_PARAM request *NONE

Prozedurnamen:	GETQUERYINFO
HTTP-Anforderungsmethode:	GET
URI-Pfadvorlage für die Methode:	GetQueryInfo/{queryName}
HTTP response code output parameter:	*NONE
HTTP header array output parameter:	*NONE
Zulässige Eingabemedientypen:	*ALL
Zurückgegebene Ausgabemedientypen:	*JSON

Eingabeparameterzuordnungen: Parametername Datentyp Input source Kennung Default Value queryName char *PATH_PARAM queryName *NONE

Prozedurnamen:	GETQUERIES
HTTP-Anforderungsmethode:	GET
URI-Pfadvorlage für die Methode:	GetQueries/
HTTP response code output parameter:	*NONE
HTTP header array output parameter:	*NONE
Zulässige Eingabemedientypen:	*ALL
Zurückgegebene Ausgabemedientypen:	*JSON

Das einzige Problem ist jetzt noch ich weiß nicht wie ich es hinbekommen kann das ich an den Webservice XML übergebe das läuft bei mir immer auf einen 404 weil er die "/" im XML als Trennzeichen für den URL interpretiert.

Hat da einer eine Idee ?

MfG Malte

[andreaspr@aon.at]

Ich persönlich finde ja das RPG nie dafür gemacht wurde mit dem Web zu interagieren.
Und all diese Erweiterungen damit es irgendwie mit dem Web kommunizieren kann, finde ich nicht unbedingt zeitgemäß.
Aber wie gesagt, nur meine persönliche Meinung!

Ich bevorzuge da PHP auf der i. Da kannst du mit wenigen Zeilen Code ein fertiges WebService erstellen.
Um die korrekte Verarbeitung von XML (ein/ausgehend) brauche ich mir da auch keine Gedanken machen.
Und mit JSON geht es sogar noch einfacher.

Kann auch schnell und einfach getestet werden.

[mihael]

Ich persönlich finde ja das RPG nie dafür gemacht wurde mit dem Web zu interagieren.
Und all diese Erweiterungen damit es irgendwie mit dem Web kommunizieren kann, finde ich nicht unbedingt zeitgemäß.
Aber wie gesagt, nur meine persönliche Meinung!

Ich bevorzuge da PHP auf der i. Da kannst du mit wenigen Zeilen Code ein fertiges WebService erstellen.
Um die korrekte Verarbeitung von XML (ein/ausgehend) brauche ich mir da auch keine Gedanken machen.
Und mit JSON geht es sogar noch einfacher.

Kann auch schnell und einfach getestet werden.

Was kann denn PHP was RPG nicht kann (rhetorisch)? Das Problem besteht überhaupt nicht in der Programmiersprache. Besonders nicht, da man von RPG auch auf andere ILE fähigen Sprachen zugreifen kann. Das Problem ist, dass für RPG fast ausschliesslich IBM Frameworks und Spracherweiterung anbietet. Und wenn IBM in dem Feld nix macht, dann passiert auch nix. In anderen Sprachen ist die Community wesentlich aktiver (was Softwareprojekte angeht) und nicht so fixiert auf den Hersteller der Programmiersprache. Wenn in anderen Sprachen Elemente oder Frameworks fehlen, dann werden sie von der Community beigesteuert. Das fehlt im RPG Umfeld fast total.

Wenn RPG ein gutes Framework hätte für Web Services, dann wäre auch RPG ein guter Mitspieler im WWW. Leider fehlt ein entsprechendes Angebot an Software.

Ich versuche dem ein wenig abzuhelfen und habe ein Projekt gestartet: BlueDroplet. Siehe https://bitbucket.org/m1hael/bluedroplet . Das Projekt steckt noch in den Kinderschuhen, aber wir machen schon ganz gute Fortschritte.

Meine 2 Cent.

Mihael

[Fuerchau]

Da nun mal RPGLE trotz allem nicht objektorientiert ist, stellt sich eine Spracherweiterung eben als nicht so einfach dar.
OOP-Sprachen sind da äußerst flexibel und mittels Funktionsbibliotheken unendlich erweiterbar.
Hier ist das halt im RPGLE-Umfeld doch mit nicht unerheblichen Schwierigkeiten verbunden.
Da kann ich die OOP-Fraktionen durchaus verstehen.

Nichts desto trotz lassen sich natürlich mit RPGLE super Anwendungen für die AS/400 schreiben.

[mihael]

Manche Dinge lassen sich in OO Sprachen sicherlich einfacher umsetzen. Dennoch ist sehr vieles in RPG möglich. Vieles was in C möglich ist ist auch in RPG möglich. Es liegt an der Community. Es liegt an den fehlenden Softwareprojekten der Community, dass alle glauben, dass man Dinge nicht mit RPG umsetzen kann.

Ich denke es lässt sich ein REST Framework auch in einer (oder mehreren) ILE fähigen Sprache(n) umsetzen, so dass es dann von RPG nutzbar ist.

[BenderD]

Da nun mal RPGLE trotz allem nicht objektorientiert ist, stellt sich eine Spracherweiterung eben als nicht so einfach dar.
OOP-Sprachen sind da äußerst flexibel und mittels Funktionsbibliotheken unendlich erweiterbar.
Hier ist das halt im RPGLE-Umfeld doch mit nicht unerheblichen Schwierigkeiten verbunden.
Da kann ich die OOP-Fraktionen durchaus verstehen.

Nichts desto trotz lassen sich natürlich mit RPGLE super Anwendungen für die AS/400 schreiben.

... was hat PHP mit Objekt Orientierung zu tun? Ich denke gerade darüber nach, ob PHP eine Programmiersprache ist - na gut, für Arme und Kranke, wenn man sonst nix hat oder kann...

D*B

[B.Hauser]

Lieber Dieter,

da für Dich alles nicht gut genug ist ... was ist denn Deiner Meinung nach die beste Lösung? Java?!
Das hat aber auch seine Ecken und Kanten und an manchen Stellen sind eben Dinge sogar mit den Pfusch und Huddelduddel-Sprachen einfacher und eleganter zu realisieren.

Die Tendenz geht einfach dahin, dass das richtige Tool für den richtigen Zweck verwendet wird.

Birgitta

[andreaspr@aon.at]

Was kann denn PHP was RPG nicht kann (rhetorisch)?

Du hast es eh schon sehr gut auf den Punkt gebracht.
Ich verwende PHP nur als Schnittstelle da es dort einfach eine Vielzahl an Möglichkeiten gibt die in ILE mit RPG & Co nur sehr schwer (wenn überhaupt) realisierbar sind.
Für die eigentliche Verarbeitung (Business Logik) verwende ich ganz normal meine ILE Anwendungen.

Ich habe auch schon ein WebService in Java erstellt. Da waren die Anforderungen halt entsprechend hoch, sodass ich schlussendlich auch in PHP an die grenzen stieß. (Z.B.: SOAP mit Signatur)
Hauptsächlich jedoch, da ich nicht alle PHP Plugins auf der IBM i installieren kann, da manche bestimmte Compiler benötigen.
Und ich bin kein Freund davon Standardfunktionen, wie das Erstellen eines SOAP XMLs, manuell zu programmieren.
Wenn es wichtige Funktion nicht gibt, ist die Sprache für mich nicht die richtige (für genau diesen Fall halt!).

Wie Birgitta schon sagte: das richtige Tool für den richtigen Zweck.
Und ich schließe hier nichts aus. ... Na ok, COBOL schon :-)

lg Andreas

[mihael]

Wenn es wichtige Funktion nicht gibt, ist die Sprache für mich nicht die richtige (für genau diesen Fall halt!).

Du hast es schon richtig formuliert. In deinem Beispiel brauchtest Du eine Funktion und eine Funktion ist (oder muss nicht) Bestandteil der Sprache sein, sondern kann mittels der Sprache realisiert werden. Das Problem bei RPG ist, dass sich keiner (oder kaum einer) die Mühe macht, dieses zu realisieren und dann auch noch frei verfügbar zu machen.

Und da fängt das nächste Problem schon an. Wenn es denn frei verfügbar ist, wie bekommen die Benutzer/Interessenten mit, dass es so was überhaupt gibt. Und wenn sie es mitbekommen haben, wie kann man es denn installieren und benutzen.

Da sind noch ganz viele Baustellen offen zu der die RPG Community nicht in der Lage ist, diese zu anzugehen.

Ein zögerlich Ansatz (und nur eine Lösung für ein Teil des Gesamtproblems) ist das Projekt RELIC : https://github.com/OSSILE/RelicPackageManager

[BenderD]

Lieber Dieter,

da für Dich alles nicht gut genug ist ... was ist denn Deiner Meinung nach die beste Lösung? Java?!
Das hat aber auch seine Ecken und Kanten und an manchen Stellen sind eben Dinge sogar mit den Pfusch und Huddelduddel-Sprachen einfacher und eleganter zu realisieren.

Die Tendenz geht einfach dahin, dass das richtige Tool für den richtigen Zweck verwendet wird.

Birgitta

... was soll denn diese persönliche Anmache? PHP ist eine Skriptsprache zur Erstellung dynamischer Webseiten - nicht mehr und nicht weniger. Wer meint damit klassische Business Anwendungen, wie sie in RPG existieren, neu zu erstellen, nutzt einfach das falsche Werkzeug! Objekt orientiert nennt sich heute fast alles, das ist so schön modern, trifft aber auf vieles nicht wirklich zu.
Das mit dem richtigen Tool ist entweder schönfärberisch oder geht an der Realität vorbei. Im richtigen Leben benutzt man - oft leider - in der Tat das was man hat oder kann und viel zu oft eben gerade nicht ein - es gibt immer mehrere Möglichkeiten - angemessenes Werkzeug.

D*B

[mihael]

Das mit dem richtigen Tool ist entweder schönfärberisch oder geht an der Realität vorbei. Im richtigen Leben benutzt man - oft leider - in der Tat das was man hat oder kann und viel zu oft eben gerade nicht ein - es gibt immer mehrere Möglichkeiten - angemessenes Werkzeug.

Da muss ich Dieter Recht geben. Viele nutzen einfach nur die Tools, die sie kennen. Ob es dann das richtige oder auch angemessene Tool ist spielt keine Rolle. Viele sind nicht bereit (oder in der Lage) sich auf Neues (oder etwas was sie noch nicht kennen, egal wie alt es ist) einzulassen. Und ich schliesse mich da selber gar nicht von aus (manchmal siegt ebend auch die Faulheit =) ).

Mihael