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

[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

[camouflage]

Ich schliess mich mal hier gerade auch an. Die heutigen Anfroderungen verlangen halt, dass ein Mix aus verschiedensten Umgebungen nötig ist. Ich denke, das hat auch IBM erkannt und lässt allerlei auf der IBMi zu, siehe die neusten "Open"-Umgebungen.

Und wenn ich schon dabei bin, ich krieg es einfach nicht gebacken, ein Eingabefeld unter Unicode für verschiedene Sprachen zu erstellen. Sprich, Bezeichnungen für Griechisch, Englisch, Deutsch und Tschechisch unter einer CCSID zu erfassen. (Ok, griechische Zeichen z.B. mit Copy/Paste aus Win).
Das muss doch möglich sein, da bin ich doch nicht der Einzige. :-(

[Rainer Ross]

Zu der interessanten Diskussion über Webservices habe ich ein paar Beispiele von mir zusammengetragen

Webservice auf der IBM i, der Daten in Tschechisch, Russisch und Chinesisch in XML mit unterschiedlichen CCSID's liefert: www.myhofi.com/muscgip/mymustst.pgm

Webservice auf der IBM i, der Daten in JSON liefert: www.myhofi.com/myapp/websrvknd1.pgm?id=1

PHP ruft Webservice auf der IBM i auf: http://phpfiddle.org/main/code/z4ij-5n7d

Webservice auf der IBM i mit Node.js programmiert: https://github.com/RainerRoss/webser...-i-and-Node.js

Webservices von IBM i anzusprechen, z.B. den Webservice von Google Maps, geht sehr einfach über HTTPGETCLOB oder HTTPGETBLOB https://worksofbarry.github.io/blog/?4

Mein Spezialgebiet ist das Bereitstellen von zeitkrititschen und hochperformanten Webservices auf der IBM i, z.B. die Anbindung von Webshops, die Daten von der IBM i benötigen oder von Webanwendungen, die über AJAX auf Webservices zugreifen www.myhofi.com/devhtm/spoolsorter.htm

Herzliche Grüße
Rainer