Skip to main content

Notice: this Wiki will be going read only early in 2024 and edits will no longer be possible. Please see: https://gitlab.eclipse.org/eclipsefdn/helpdesk/-/wikis/Wiki-shutdown-plan for the plan.

Jump to: navigation, search

Difference between revisions of "EDT:Support for IBM i"

 
(17 intermediate revisions by the same user not shown)
Line 7: Line 7:
 
== Use of the JTOpen toolkit  ==
 
== Use of the JTOpen toolkit  ==
  
Direct access to IBM i host programs is by way of the JTOpen toolkit, which determines what program types are supported. Two cases apply:<br>
+
Direct access to IBM i host programs is by way of the JTOpen toolkit, which determines what program types are supported. Details on that toolkit are here: [http://jt400.sourceforge.net/ JTOpen]
  
*In the EDT nightly build, the toolkit is available automatically.&nbsp;
+
Two cases apply:<br>  
*In EDT 0.80 and in the EDT 0.81 milestone versions, the toolkit is not embedded in the software provided for EGL Development Tools. <br>Here is the prerequisite task for those versions:
+
  
#Review the description at the following site and download the toolkit: [http://jt400.sourceforge.net/ JTOpen].  
+
*The EDT nightly build includes the JTOpen toolkit and makes it available at development time.&nbsp; <br><br>When you deploy code that requires use of the toolkit, the EGL deployer places the JTOpen jar file (<code>org.jtopen_0.8.1.jar</code>) in the WebContent/WEB-INF/lib folder. <!-- [not in EDT] or includes the file as a library in the target EAR project.--><br><br>
 +
 
 +
*Neither the EDT 0.80 version nor the EDT 0.81 milestone builds include the toolkit. <br><br>Here is the prerequisite task for those versions:
 +
 
 +
#Download the toolkit: [http://jt400.sourceforge.net/ JTOpen].  
 
#Extract the <code>jt400.jar</code> file.  
 
#Extract the <code>jt400.jar</code> file.  
#Reference that file in the Java class path.
+
#Reference that file in the Java class path.  
 +
#Add the jar file to the classpath of the server that will receive your deployed application. For example, during EGL deployment, you might add the file to the <code>lib</code> folder of the target project. <!-- [not in EDT] or as a library in the target EAR project. -->
  
In any case, you will add the jar file to the classpath of the server that will receive your deployed application. For example, during EGL deployment, you might add the file to the <code>lib</code> folder of the target project or as a library in the target EAR project. Outside of EGL deployment, you might add the file as a resource in the server classpath.
+
<br>In either case, when you deploy your code outside of the IDE, you might need to add the JTOpen jar file as a resource in the server classpath.
  
 
== Development overview  ==
 
== Development overview  ==

Latest revision as of 16:20, 6 July 2012

Resource Binding Introduction

Introduction

EGL code that is generated to Java can access IBM i called programs, as well as procedures in IBM service programs. The language also supports access of those programs from a Rich UI application, by way of an EGL service type generated to Java.

Use of the JTOpen toolkit

Direct access to IBM i host programs is by way of the JTOpen toolkit, which determines what program types are supported. Details on that toolkit are here: JTOpen

Two cases apply:

  • The EDT nightly build includes the JTOpen toolkit and makes it available at development time. 

    When you deploy code that requires use of the toolkit, the EGL deployer places the JTOpen jar file (org.jtopen_0.8.1.jar) in the WebContent/WEB-INF/lib folder.

  • Neither the EDT 0.80 version nor the EDT 0.81 milestone builds include the toolkit.

    Here is the prerequisite task for those versions:
  1. Download the toolkit: JTOpen.
  2. Extract the jt400.jar file.
  3. Reference that file in the Java class path.
  4. Add the jar file to the classpath of the server that will receive your deployed application. For example, during EGL deployment, you might add the file to the lib folder of the target project.


In either case, when you deploy your code outside of the IDE, you might need to add the JTOpen jar file as a resource in the server classpath.

Development overview

Your coding task has the following aspects:

  • You write an EGL proxy function. In relation to IBM i, the proxy function might be in any of the following types: an EGL Library, Service, Handler, or Program. The function has no logic, and any logic you place there will be ignored. Instead, you include one or more annotations.

    As in service access, the main annotations in the EGL proxy function are Resource, which tells "where" the backend code resides, and a second annotation that tells "what more" is required by the EGL generator. The "what more" annotation for IBM i is IBMiProgram.

    One runtime effect of referencing a resource binding is that you gain the performance benefits of using a connection from the AS400 connection pool.

  • When you write the EGL code that calls the function, you might access the proxy function and rely on the details provided there. The following variations apply:
  • If you access the function remotely, you cannot override the Resource annotation. At this time, remote access is possible only from a Rich UI application.
  • If you access the function locally in generated Java code, you might code a variable that references a different resource binding or that specifies new detail; and then refer to that variable in the using clause of the call statement.

When you include a using clause, the coded detail overrides the Resource annotation. If the using clause references a different deployment-descriptor entry, you still gain the performance benefits of using a pooled connection. However, the using clause might represent a connection that you define in your code; and in that case, you typically do not use a pooled connection, but rely on the AS400 connection object that is available in the JTOpen toolkit.
  • The parameters of the EGL proxy function represent the parameters of the host program, and your call can pass simple data, as well as records and handlers. If a value is returned from the proxy function, the type of value is an EGL Int. (On IBM i, a return value is possible from a service program but not from a called program.)


In general, a Rich UI application uses an asynchronous version of the call statement to get enterprise data from a service. In relation to an IBM i program, the application calls a public proxy function that is defined in an EGL Service type.


Runtime process

At run time, the proxy function is an endpoint for accessing an IBM i program. That function acts as follows:

  1. Retrieves a connection for the AS400 connection pool, if you are using that kind of connection.
  2. Converts your data from an EGL format to byte arrays. The structure of those arrays is based on a set of AS400DataType classes that are provided by the JTOpen toolkit.
  3. Creates a JTOpen ProgramCall or ServiceProgramCall object, depending on whether the call is to an IBM i called program or service program.
  4. Creates JTOpen ProgramParameter objects and passes the byte arrays to them.
  5. Calls the host program by calling the run method on the ProgramCall or ServiceProgramCall object.
  6. Reformats the returned value (if any) to EGL format.
  7. Converts the returned byte arrays to EGL format. The structure of those arrays is based on a set of AS400DataType classes that are provided by the JTOpen toolkit.
  8. Returns the connection to the AS400 connection pool, if you are using that kind of connection.

Coding details

The objects expected by the host are based on fixed-size types, whereas many EGL types are variably sized. You handle the difference by annotating the variably sized objects.

The annotations you specify are in the eglx.jtopen.annotations package, with annotation type names that of the form Structxxxx. The xxxx part of an annotation type name corresponds to the last part of a JTOpen class name in the com.ibm.as400.access.AS400Datatype package.

To determine which annotations to specify, refer to the table shown later, along with the Javadoc for the com.ibm.as400.access.AS400Datatype classes.

EGL proxy functions for IBM i

Here is an example of an EGL proxy function, including the annotations named ExternalName and IBMiProgram:

function GETRECA(CUST CUST[] inout, 
                 EOF   string inout, 
                 COUNT decimal (2,0) inout) {

      @ExternalName{value="MyHostProc"},


      // new in the overnight build for 0.81 Milestone 3
      @Resource{uri = "binding:file:EGLDDFile#MyConnection"},  
      
      @IBMiProgram {         
         programName = "GETREC",
         libraryName = "/QSYS.LIB/VARLABXX.LIB/",
         isServiceProgram=true,
         parameterAnnotations = [
            @StructArray{elementCount = 10},     // In the 0.81 M2 delivery: Struct400Array was AS400Array
            @StructText{length = 1},             //                          Struct400Text  was AS400Text
            null 
         ]
         
         // In the 0.81 M2 delivery, the following code was in use rather than @Resource:   
         //                          , connectionResourceBindingURI = "binding:file:EGLDDFile#MyConnection"
      }
   }
end   

The ExternalName annotation is optional. It holds the name of the IBM i procedure and defaults to the name of the EGL proxy function.

The Resource annotation is optional. It provides a default value; specifically, a reference to a binding that is defined in the EGL deployment descriptor. See the earlier "Development overview" section for details about the different implications of a local and remote call. Also note that any value specified in the library field of the deployment descriptor entry replaces the library field in the IBMiProgram annotation, which is the primary annotation that structures the call.

The IBMiProgram annotation holds the following detail:

  • The path of the library and program on IBM i.

    You can specify both details on the programName field; in the current example, the field value would be "/QSYS.LIB/VARLABXX.LIB/GETREC". In any case, the EGL runtime code appends a file extension to the value of the programName field: .SRVPGM for service programs, .PGM for called programs.

  • A flag as to whether a service program is being invoked.

  • Annotations for each parameter, as described later.

For general details on binding, see Resource bindings.

Annotations for data conversion

The data-conversion annotations cause the use of converters that are found in the following JTOpen package: com.ibm.as400.access. In version .081 Milestone 2, the EGL annotation name was identical to the Java class name. In more recent builds, the EGL annotation is similar to the Java class name: the annotation name begins with "Struct" and ends with a substring such as "Bin4." The reason for the change is to facilitate the future use of System z or other backend code.

The rest of this description uses the current naming standard, with "Struct" in place of the older "AS400".

When you set a value for the parameterAnnotations field, you specify an annotation or the null keyword for every annotation:

  • Values of simple reference types require an annotation. Example types are String, Decimal, and Timestamp.
  • Values of simple value types require an annotation only if you do not want to accept the defaults. Example types are String(7), Decimal (5,2), and Timestamp("yyyyMMddHHmm").
  • Lists require a parameter annotation.
  • null is always used for a variable that is based on a Record or Handler type.

If you do not set a value for the parameterAnnotations field, the defaults are used for every parameter.

Equivalent rules are in effect for the fields that are in a container; that is, in a variable that is based on a Record or Handler type. For example, here is a Record type with annotations:
Record Example
 
   // Convert using the default StructBin4
   f1 int;
 
   // After the host program call, f2 is resized using the data returned in f3
   f2 int[]{@StructArray{elementCount = 10, returnCountVariable = f3}};
 
   // A fixed text with a length 2 characters using the default encoding
   f3 string{@StructText{length = 2}};
 
   // Convert a number to a StructDecFloat
   f4 number?{@StructDecFloat{length = 34}};
 
   // Convert using the default StructPackedDecimal
   f5 decimal(10,2);
 
   // Convert using the StructZonedDecimal
   f6 decimal(10,4){@StructZonedDecimal{}};
 
end
If that Record type included a record, you would not specify an annotation for the included record, but might specify annotations for the fields in that record.

Call statements

You write a call statement to invoke the EGL proxy function. A using clause, if present, refers to a connection. If a using clause is not present in the call statement or if the call statement is in a Rich UI application, a Resource annotation in the proxy function must reference a deployment descriptor entry. Consider the following proxy function, which resides in an EGL Service type:
Program TestSimpleProgram 
 
   //On IBM i, only service programs support a return
   function MyHostProcedure(p1 string, p2 string)RETURNS(INT)
      {
         @Resource{ uri = "binding:someEntry" },
         @IBMiProgram{
            programName = "/QSYS.LIB/VARLABXX.LIB/GETREC",
            isServiceProgram= true,
            parameterAnnotations = [@StructText{length = 10}, @StructText{length = 10}]
         }
      }
   end
end
Here is a call from another function in the same service, including reference to a Customer Record type. The call relies on the binding detail that was just shown in the Resource annotation:
cust Customer;
result Int;
myString String = "abc";
try
   call MyHostProcedure(myString, cust) returns (result);
   onException(exception AnyException);
      //handle exception
end
Here is an alternative call, which provides binding detail that overrides the binding detail, if any, in the proxy function:
cust Customer;
result int;
myString String = "abc";
conn IBMiConnection? = Resources.getResource("binding:someOtherEntry");
try
   call MyHostProcedure(myString, cust) 
      using conn
      returns (result);
   onException(exception AnyException)
      //handle exception
end
The following code is equivalent to the previous logic:
cust Customer;
result int;
myString String = "abc";
try
   call MyHostProcedure(myString, cust) 
      using Resources.getResource("binding:someOtherEntry") 
         as IBMiConnection
      returns (result);
   onException(exception AnyException)
      //handle exception
end
Here is yet another alternative call, which might provide a value of type IBMiConnection instead of referencing the EGL deployment descriptor:
cust Customer;
result int;
myString String = "abc";
 
conn IBMiConnection? = getMyDefinedConnection();
try
   call MyHostProcedure(myString, cust) 
      using conn
      returns (result);
   onException(exception AnyException)
      //handle exception
end
If you want to access the AS400 connection pool from your code, you also assign connection detail to a variable of type IBMiConnection; but for that purpose, you invoke the static Java function that is referenced in the following EGL external type:
externalType JTOpenConnections type JavaObject
   private constructor();
   static function getAS400ConnectionPool()returns(AS400ConnectionPool);
end
For details on that function, see the JTOpen documentation for the AS400ConnectionPool object.


Fields in the EGL deployment descriptor entry

You can set a variety of fields in the EGL deployment descriptor entry. The type of each entry is AS400Connection, which is compatible with the IBMiConnection type that is used in the code examples.


You can use the fields in the deployment descriptor to override default behavior. In addition, you can set annotations on a field or parameter that is being passed to the proxy function, and that annotation overrides all other settings.


Here are the fields of the deployment descriptor entry:

dateFormat

The date format for AS400Date objects.
This value overrides the default date format, which is com.ibm.as400.access.AS400Date.FORMAT_ISO. The format specifies a separator character, but that character can be overridden; for details, see the next description.

dateSeparator

The date separator for AS400Date objects.
This value overrides the date separator that is specified in the dateFormat field value.

encoding

The character encoding for AS400Text objects.
This value overrides the default encoding, which is obtained from the CCSID value of the AS400 connection.

library

The library where the program is located. If you specify a value for this field, you replace any value specified in the IBMiProgram annotation, library field.

password

The password for the specified user ID.

system

The IBM i system name.

timeFormat

The time format for AS400Time objects.
This value overrides the default time format, which is com.ibm.as400.access.AS400Time.FORMAT_ISO. The format specifies a separator character, but that character can be overridden; for details, see the next description.

timeSeparator

The time separator for AS400Time objects.
This value overrides the time separator that is specified in the timeFormat field value.

timeZone

The time zone for AS400Date, AS400Time, and AS400Timestamp objects.
This value overrides the default time zone, which is obtained from the timezone field value of the AS400 connection.

userid

The user ID that provides access to the IBM i system.


For reference details and more examples

For more information, see the last sections in the following help-system topic: "IBM i bindings." The equivalent topic in the version 0.81 Milestone 2 build was named "Accessing an IBM i called or service program."

Back to the top