Idea Details

7795 - Consume a web service

Last activity 6 days ago
Simon_Cockayne's profile image
04-07-2011 04:57 AM


Another idea from our internal wishlist:

As a 2E developer I want to be able to consume a web service, i.e. to have the model support the implementation of a 2E application that can invoke a web service at runtime.



Simon Cockayne
CA Technologies
Principal Software Engineer


CA Subject Matter Expert


05-16-2012 03:35 AM

Hi,<br><br>just to add some details to my original vote from last year, we have had to consume web services and like others have used Scott Klement&#39;s httpapi which is an excellent piece of open source. We have each web service call as an RPG MOD which binds into our RPG PGM (an execute external function).  We did consider a generic function using different stream files but tried to keep things simple as this was all quite new to us..<br><br>The only things I can add to David&#39;s points are that we were using digital certificates and had to go down the route of using a  specific activation group.<br><br>Mark

05-11-2012 12:24 PM

Hi Simon,<br><br>I <u>absolutely</u> vote for this. Our requirements for integration of webservices are ramping up lately, to a point where we&#39;re now writing a lot of external RPG functions to consume them (even though we&#39;re really a COBOL shop).<br><br>We recently jumped into both consuming and creating webservices on our i, using Scott Klement&#39;s httpapi interface (for consuming) in RPG , which in , if you&#39;re unfamiliar, provides an interface to EXPAT (outside of 2E of course). We are about to upgrade 2E from 8.0 to 8.6 and, whilst the webservice access methods we&#39;re using work extremely well for us, it is a manual process outside of 2E, which is accompanied by extra maintenance.  <br><br>I was surprised that there doesn&#39;t appear to be any support for consuming a webservice in any version after 8.0. If 2E could hook into a WSDL, and provide support for mapping incoming xml into an existing data structure defined in 2E, accessible by regular function access (i.e. action diagrams), that would be ideal.  <br><br>When creating a webservice on the i, the server-side conveniently converts the data structure defined in your RPG/CBL ILE parameters into XML tags when you consume it. On the consumption side, the reverse conversion is left up to the program consuming the webservice.<br><br>If it&#39;s a challenge to supply  functions that will consume a webservice in 2E, then perhaps , if the consumption part was done externally, providing an IFS STMF, it would be helpful if 2E could map the XML in that STMF into a data structure in 2E automagically, so that , in essence, you give a regular 2e function the capability to access the data content from a webservice as if it were in any old regular file.<br><br>I imagine this type of provision would also integrate into one of 2E&#39;s best features, which is impact analysis. It&#39;s a challenge to catch all the referencees and usages, expecially if they&#39;re embedded in CL, executable messages, etc. , so this would also avoid having to perform additional checks on top of that.<br><br>Is anyone else experiencing increased requirements? what methods are other developers using?<br><br>Thanks<br><br>David

05-12-2011 09:02 AM

I would also think this function to consume a web service. I have one web service that has over 1000 values and arrays. The way I do it now is send request via DataQ or RPC over to a Windows server with IBM client Accces on it and then a VB net app to consume the service and send the back the response. <br><br>For small web services I use that work nice.<br>

04-07-2011 11:28 AM

Hi Simon, this one gets my vote. I have consumed web services manually, and it can be really tricky. <br><br>I took a 2E EEF, published it through the 8.5 Web Services functionality, then consumed that Web Service manually, so that I could call it from another 2E function (DSPFIL) across machines. This was really just to prove it all worked, but it was not for the feint of heart.<br><br>Any help in this area would surely be greeted with enthusiasm.<br><br>Not that I have a pressing need, but I can see it being another great feature for the product.<br><br>Crispin.<br>