Re: XMLSERVICE with .Net

Possibly.

But how much of the IBM i world has embraced and built core business functionality into SubProcedures ?

We usually use Subprocedures as small special purpose re-usable functions. When it comes to returning data we use resultsets from RPG or SQL calls.

Give me an example of your largest and most complex subprocedure and how much logic you've built in to it.

You're right it is cool to redeploy subprocedures, but re-architecting current code to send back resultsets and or be called as a stored procedure is probably just as easy.

Although I have a semi-open mind so I can be persuaded :-)

Regards,
Richard Schoen
RJS Software Systems Inc.
Where Information Meets Innovation
Document Management, Workflow, Report Delivery, Forms and Business Intelligence
Email: richard@xxxxxxxxxxxxxxx
Web Site: http://www.rjssoftware.com
Tel: (952) 736-5800
Fax: (952) 736-5801
Toll Free: (888) RJSSOFT

------------------------------

message: 2
date: Fri, 10 Aug 2012 15:30:25 -0400
from: Jon Paris <jon.paris@xxxxxxxxxxxxxx>
subject: Re: [WEB400] XMLSERVICE with .Net


On 2012-08-10, at 1:00 PM, web400-request@xxxxxxxxxxxx wrote:

Why would it need to when it can return a result set from a stored procedure ?

I personally have found no limits with jt400. Maybe I'm just too
simple :-)

In any case I plan to test XMLSERVICE more and complete a .Net service wrapper before COMMON next year for my .Net sessions.

You're completely missing the point Richard. The point is redeployment.

For example: I have many existing RPG subprocedures that I have developed as part of my existing applications. All of them return values in different forms. Some a simple 40 char field. Some a simple DS. Others a compound DS or DS array.

_None_ of those can be called from JT400 - and because it used the same underlying interface - none of them could be called from the old PHP toolkit.

If I've got all my logic in stored procedures I don't need it - but that isn't the way that most of my clients have their existing apps coded - and why would they. They were designed to feed their green screen and batch apps. They now want to use them from the web - or as a web service - or ... and to do so without wrappering them. That's where XMLSERVICE stands out.