Eclipse Community Forums: EGL Development Tools » Wizard for IBM i program calls

Help

Home

Home » Archived » EGL Development Tools » Wizard for IBM i program calls

Show: Today's Messages :: Show Polls :: Message Navigator

Wizard for IBM i program calls [message #855406]

Tue, 24 April 2012 19:55

Dan Darnell

Messages: 145
Registered: November 2011
Location: Arkansas

Senior Member

I am working my way through producing a new "Calling RPG from EGL using EDT" video to replace my "Calling RPG from EGL Community Edition" video.

I am having a lot of "ugh" moments where I feel that the IBM i crowd is not going to be happy with the complexity. I can already hear the complaints that are sure to come and anticipate plenty of comments that simply read: "Forget it. I'll just use PHP."

Calling RPG using EGL in RBD and the Community Edition was drop-dead simple. Not so with EDT. Now, I appreciate the direction that was taken with EDT and the flexibility represented in the implementation. Clearly, the solution for the IBM i crowd is a wizard that guides one through the steps and the parameter options.

What are the chances that we could get this added as a 0.8.1 deliverable?

--Dan

Report message to a moderator

Re: Wizard for IBM i program calls [message #855584 is a reply to message #855406]

Wed, 25 April 2012 00:02

Ben Margolis

Messages: 10
Registered: December 2011

Junior Member

Dan, I have also expressed concern about the EDT support for IBM i. Does the following entry resonate; or is the basic direction okay and only a wizard required?

bugs.eclipse.org/bugs/show_bug.cgi?id=375121

Report message to a moderator

Re: Wizard for IBM i program calls [message #856597 is a reply to message #855406]

Wed, 25 April 2012 20:32

Joseph Vincens

Messages: 31
Registered: December 2011
Location: Prospect CT

Member

Hi Dan,

I watched your CE Video - www.youtube.com/watch?v=lA25DoElnSc.

I want to understand the complexity so I've added the equivalent EDT code here for the service function and the service invocation in the Rich UI handler.

Create a Service with the function. For EDT the function is the model of what is being called on the host.

service CallRpgService
   function MYRPG(name string inout){
		@IBMiProgram {
			programName = "MYRPG",
			libraryName = "/QSYS.LIB/%LIBL%.LIB/",
			parameterAnnotations = [
				@AS400Text {length = 40}
			],
			connectionResourceBindingURI = "myi_connection"		
		}
	}

Then create an egldd IBMIConnection entry with the name myi_connection - enter the host system, your user and password.

You can call this service function directly in you Rui application:

call CallRpgService.MYRPG(nameField.text) using new HttpProxy returning to callReturn;

Is the complexity the fact that you need to model the host program as a function?

thank you for your feedback,
Joe

Report message to a moderator

Re: Wizard for IBM i program calls [message #856977 is a reply to message #856597]

Thu, 26 April 2012 06:15

Dan Darnell

Messages: 145
Registered: November 2011
Location: Arkansas

Senior Member

Hi Joe.

"Is the complexity the fact that you need to model the host program as a function?"

Yes, that was my concern (note the "was" in that sentence). As you know, with RBD the data types were there such that it only took a simple "call" with the right data types (plus an entry in the build descriptor) to call any RPG program.

I was ultimately able to put a video together that I think shows the EDT feature in a very positive light and I think it will be well received. The biggest win is the "wow" factor of being able to code an RPG call directly out of the client tier. I realize that the call isn't REALLY directly out of the client tier but it comes across as such and nothing else out there touches this degree of ease-of-use and integration with IBM i. (You may have noticed that when I originally posted this thread I posted another asking about how to do an IBM i call out of the client -- a feature hinted at on the blog but not documented in the help or online samples. Once I figured out how to make this type of call it was a major improvement and changed the direction of the example in my video. In essence, it's such an awesome feature that it makes the additional complexity of function/annotation definition inconsequential.)

Plus, there are other demonstrable benefits to the proxy function such as the code assist that is gained by having a defined function for the program call. One has to structure the function and annotation properly but, once done, there is less room for a misstep than with the implied data conversion that we have in RBD.

I'll have my video up soon and will start pushing IBM i people to watch it but I think now that the responses are going to be very positive.

What's your take on a creating a wizard to guide one through creating an IBM i program call annotation? I think the product needs it but I could be wrong.

I need to look around my old Java code ... I used to have a utility that took an RPG program's entry parameters and created the JTOpen definitions needed to call that program. With this, generating the EGL annotation from the RPG code wouldn't be a far stretch.

--Dan

Report message to a moderator

Re: Wizard for IBM i program calls [message #857001 is a reply to message #855584]

Thu, 26 April 2012 06:44

Dan Darnell

Messages: 145
Registered: November 2011
Location: Arkansas

Senior Member

Hi Ben.

I've been working through more examples and more complex examples...basically, revisiting my "EGL Has Landed" article from 2008 (http://www.iprodeveloper.com/article/rpg-programming/the-egl-has-landed-calling-rpg-programs-from-egl-62294).

I would love to see a wizard for annotation creation but I think maybe it is more of a marketing device than a practical one. Maybe I am in the minority but (with a few exceptions) when I have an example in code to draw from I tend to use the code rather than walking through a wizard to get to some code. I say "marketing device" because I think that a wizard shows really well and gives people who are new to the language that extra help needed to make it up the learning curve.

As for the discussion of proxy functions vs. interfaces...interesting reading. Granted, I'm still coming up to speed here but I like the proxy functions. I like being able to have a library (or service) consisting of functions that represent calls to different programs and/or functions in service programs. (Some of the implementation details discussed in the bugzilla entry are beyond me. For example, the notes on the bugzilla entry end this way "For now, here's the resolution: the proxy function will disappear in favor of an abstract function, but the overall structure is the same." I don't know what this means. Does it mean that we'll still be able to create functions with annotation in libraries, services, etc.?)

That said, I see the wisdom in the one-approach thinking. When I wrote about leveraging XMLService to make RPG program calls (see http://www.ibmsystemsmag.com/ibmi/developer/rpg/EGL-and-XMLService--Hand,-Meet-Glove/) the program calls came via an interface function. I just need to think about the whole topic a bit more and try to get my head around it.

Note too that there is mention in the bugzilla notes of an issue with credentials being static in the descriptor. We (almost) always make IBM i program calls as a "super user" and then use the switch profile function on the IBM i server to check user credentials. This ensures that the program call itself succeeds and allows us to gracefully respond to the client with authentication/authorization messages. So static credentials aren't necessarily just for use in a testing environment ... it just depends how authentication/authorization is implemented in a given application.

--Dan

Report message to a moderator

Re: Wizard for IBM i program calls [message #857491 is a reply to message #857001]

Thu, 26 April 2012 15:30

Ben Margolis

Messages: 10
Registered: December 2011

Junior Member

Dan,

Thanks for your response.

"Does [the use of an abstract function] mean that we'll still be able to create functions with annotation in libraries, services, etc.?).

Yes.

Since the EGL developer is not placing logic in the proxy function, it makes more sense to use a construct that looks like a function prototype (as now found in an Interface type) and to assign annotations to that prototype. Those constructs would be in a Library or Service, and no one would ever be tempted to add custom logic to an actual, concrete proxy function. Is a small change, a bit more elegant.

My suggestion (and Joe's) is to have the function prototypes be in an Interface type. Then we can explain the EGL back-end access technology in one short training session; or in an elevator speech or commercial. ("We" means all of us who want the technology to be simple and cool for an audience that should go way beyond the grizzled IT professional.) Given this change, your set of "functions" would be a set of function prototypes in one or more Interface types. Each prototype would be annotated: no change. However, call statements would be structured as they are structured for service access.

For service access (an asynchronous access, from Rich UI):

myBindingVar01 IHttp {@Resource {uri="binding:myJavaScriptDDEntry"}};
call MyInterface01.myServiceFunction("abc") using myBindingVar ... etc.

For IBM i access (a synchronous access, from a service generated to Java):

myBindingVar02 IBMiConnection {@Resource {uri="binding:myJavaDDEntry"}};
call MyInterface02.myIBMiFunction("abc") using myBindingVar02 ... etc.

The structure might not be exactly how people are used to thinking about accessing IBM i programs; but the uniformity of service and program access would be another reason to say, "Yes, learn a new language, it won't take you long, and even your junior developers can do sophisticated work quickly."

An aspect of life is that most people cannot remember more than a few rules at a time. We should be targeting simplicity, along with the ability to do work that is arbitrarily complex. Both of those are aspects of a language that could become surprisingly successful.

Your notes here suggest that you think that we've already made the sale for IBM i. Well, please consider this over the next couple of days. The folks at EGL Central tend to look to you (and to Joe Pluta) for a real-world sense about the IBM i usage.

If you agree with the bugzilla entry, you might help to change the direction for back-end access in general. If you don't agree with the entry, I'll likely close it.

[Updated on: Thu, 26 April 2012 21:21]

Report message to a moderator

Re: Wizard for IBM i program calls [message #857724 is a reply to message #857491]

Thu, 26 April 2012 20:09

Dan Darnell

Messages: 145
Registered: November 2011
Location: Arkansas

Senior Member

Ben,

A concern about the move to Interface definitions as the sole source for IBM i proxy function definitions...

Would we still be able to make synchronous calls to IBM i programs? Consider a RUI client that calls a service function implemented in EGL that does all of the following:

1. Calls IBM i program
2. Retrieves something from a database table using information obtained from the program call in step 1
3. Calls another IBM i program
4. Writes something to a database table using information from steps 1-3

The ability to embed multiple calls to IBM i programs and to have them execute synchronously is important.

As long as an IBM i program call can be synchronous (when coded in a service or library) or asynchronous (when coded in a handler) then I don't know if it matters whether the definition of the IBM i proxy function is restricted to Interface types.

--Dan

p.s. I am really intrigued by the discussion I have seen among the EDT team around "Ease of thought." The uniform approach is indeed important. Heck, I used EGL in RBD for two years before I knew you could directly invoke service program functions -- precisely because the way you made service program function calls was entirely different than the regular program call mechanism.

I am one who routinely argues in favor of EGL because it means learning one language and having an abstraction layer between apps and the technology du jour that underlies the apps. Is this really enough to drive people to EGL? Probably not. But couple "one language" and "technology abstraction" with "A BETTER WAY" and you have something.

I read about this the other day: [http://www.meteor.com/screencast]

Meteor is one language across tiers (JavaScript, blech) and technology abstraction but then nothing that really represents advancing the state of the art. It's former MIT guys geeking out on language theory.

EDT advances the state of the art AND keeps both eyes on being a real-world, in the trenches solution.

Report message to a moderator

Re: Wizard for IBM i program calls [message #857786 is a reply to message #857724]

Thu, 26 April 2012 21:37

Joseph Vincens

Messages: 31
Registered: December 2011
Location: Prospect CT

Member

Hi Dan,

I think Ben's example gave you the wrong impression.

myBindingVar IHttp {@Resource {uri="binding:myEntry"}};
call MyInterface.myIBMiFunction("abc") using myBindingVar ... etc.

This invokes a service and the service contains a call statement to call the host program.

Service xyz implements MyInterface
    function myIBMiFunction(id string in)returns(ResultData)
        ibmiConn {@Resource {uri="binding:myIbmiEntry"}};
        dbId int;
        call MyIBMiProgram.entryPoint1(id, dbId) using ibmiConn;
        [color=limegreen]//including your suggections[/color]
        ret.id = dbId;
        custs Customer[];
        get custs .... where id > dbId;//DB access
        
        //note we use the same connection and the program is a service program with multiple entry points
        call MyIBMiProgram.valiateCustomers(custs) using ibmiConn;
        ret.customers = custs;
        ret ResultData;
        //the connection must be returned to the connection pool
        return(ret);
    end

A call statement with a using of type IBMIConnection is only valid in Java gen and is always synchronous.
A handler never calls an IBMi program directly it always uses an async call to a service which can then call an IBMI program. With a proxy function it's possible for the handler to use the proxy function to make the host call, but the handler is still using a service function to access the host program.

regards,
Joe

Report message to a moderator

Re: Wizard for IBM i program calls [message #858036 is a reply to message #857786]

Fri, 27 April 2012 01:21

Ben Margolis

Messages: 10
Registered: December 2011

Junior Member

Two variations are available if you want to access an IBM i program from a Rich UI app:

o The Rich UI app can access a proxy function that resides in a service. In this case, the proxy function calls the back-end IBM i function synchronously and returns a message to the Rich UI application. However, the Rich UI app must rely on the details that are in the IBMiProgram annotation, which must include all details necessary to establish a connection with the program on IBM i.

o Alternatively, the Rich UI app can access a different service function that in turn invokes the proxy function. In Joe's example, the call to MyIBMiProgram.entry1 is a call to a proxy function that resides in a library named MyIBMiProgram.

***************

With a change, all access would use a similar mechanism:

For service access (an asynchronous access, from Rich UI):

myBindingVar01 IHttp {@Resource {uri="binding:myJavaScriptDDEntry"}};
call MyInterface01.myServiceFunction("abc") using myBindingVar ... etc.

For IBM i access (a synchronous access, from a service generated to Java):

myBindingVar02 IBMiConnection {@Resource {uri="binding:myJavaDDEntry"}};
call MyInterface02.myIBMiFunction("abc") using myBindingVar02 ... etc.

The following rule makes the difference in purpose easy to remember: only a Java service can access a back-end program directly.

(Another detail is that you can set the second binding variable as shown or in two other ways; but we needn't talk about those details until 5 minutes into the lesson.)

[Updated on: Fri, 27 April 2012 14:22]

Report message to a moderator

Re: Wizard for IBM i program calls [message #859446 is a reply to message #857786]

Fri, 27 April 2012 16:44

Dan Darnell

Messages: 145
Registered: November 2011
Location: Arkansas

Senior Member

Hi Joe,

"A call statement with a using of type IBMIConnection is only valid in Java gen and is always synchronous. [...] With a proxy function it's possible for the handler to use the proxy function to make the host call, but the handler is still using a service function to access the host program."

I got that...I just wanted to make sure that in an Interface-definition-only world for IBM i program calls that hand-coded synchronous calls would not come off the table. Glad to see from your examples that both modes would exist even with Interface-based definitions.

--Dan

p.s. Again, it's just too cool that you can make a call to an IBM i program from a handler without having to hand-code the service function that makes the call. This is an awesome feature! I remember Will mentioning this possibility way before you guys started implementing the IBM i support and then it never came up again in any of the discussions I was involved in. It was a surprise then when I saw the capability mentioned in the announcement on the blog. I was thrilled that this capability made the cut. Again, nothing else out there right now includes this degree of integration. Well done!

Report message to a moderator

Re: Wizard for IBM i program calls [message #859483 is a reply to message #858036]

Fri, 27 April 2012 17:02

Dan Darnell

Messages: 145
Registered: November 2011
Location: Arkansas

Senior Member

Hi Ben,

"The following rule makes the difference in purpose easy to remember: only a Java service can access a back-end program directly."

Yep...I get that...my only concern was that in an Interface-definition-only world (one of the possibilities discussed in the bugzilla note) that we might lose the ability to hand-code synchronous calls. I just wanted you guys to be aware that we need to keep that ability as well as now being able to enjoy the new call-from-handler ability.

As for the Interface-only-definition discussion....

I think I see where Tim is coming from in terms of interfaces not being implementations. I agree with that. However, consider the following REST interface definition and IBM i program call definition:

Interface WeatherForecast

   Function GetWeatherByZipCode(zipcode string in) returns(myRecordPart)
      {@GetRest{uriTemplate="/GetWeatherByZipCode?zipCode={zipcode}",
                requestFormat = JSON,
                responseFormat = JSON}};

	
   function hello(name string inout) 
	   {
	      @IBMiProgram {         
	      	 programName = "MYRPG",
	         libraryName = "/QSYS.LIB/*LIBL.LIB/",
	         parameterAnnotations = [
	            @AS400Text{length = 40}
	         ]
	      }
	   }

end

To me they imply a similar degree of underlying implementation. Certainly, as an application developer, I don't know (or care) how "requestFormat=JSON" is accommodated. Just as I don't know (or care) how "@AS400Text{length = 40}" is accommodated.

So if I were looking for where IBM i program call definitions naturally "fit" on a conceptual level ... I think I would have to say as interface functions. That's my take as an application developer using the language.

--Dan

Report message to a moderator