Prototypes for service access

An Interface part is used for service access and includes function prototypes such as the following one:

Function GetEmployeeDetail(employeeCode STRING IN,                             
                           employeeSalary FLOAT OUT,
                           employeeStatus STRING INOUT)
         returns(myEmployeeRecordPart);

If the prototype is used to access an EGL REST-RPC service, the following rules apply:

• The prototype can include IN, OUT, and INOUT parameters.
• The data received and returned by the service is always in JSON format. JSON cannot include HEX, BLOB, or CLOB data.
• The service always returns a JSON string. In a Rich UI application, the EGL runtime code rounds any numeric data that is returned by the service and is greater than 15 significant digits. The rounding does not occur when JSON is returned to EGL-generated Java™ code.

If the prototype is used to access a third-party REST service, the following rules apply:

• The IN modifier is required for each parameter.
• If a parameter is used to construct the URI or the query string, the following rules apply:
  • The name of the parameter must match the name of the substitution variable in the URI template.
  • The data type of the parameter can be a primitive type or related data item.
  • If the requester is being generated to JavaScript™, the primitive type must be STRING or one the following types, which are assignment-compatible with STRING: FLOAT, BIN, or one of the integer equivalents to BIN (INT, SMALLINT, or BIGINT).
  • If the requester is being generated to Java™, any primitive type is valid other than HEX, BLOB, or CLOB.
  • If the REST service returns a JSON string to a Rich UI application, the EGL runtime code rounds any numeric data that is returned by the service and is greater than 15 significant digits. The rounding does not occur when JSON is returned to EGL-generated Java™ code.
• The value of a representation parameter can be a string, one of the previously mentioned assignment-compatible types, or a non-structured Record part whose only fields fulfill the following rules:
  • The field is of type STRING or is assignment-compatible with STRING.
  • The field is based on a non-structured Record part. Specifically, the field can be based on a Record part that includes only strings (or assignment-compatible values) or other non-structured Record parts. Records can be nested within records to any level.

If the prototype is used to directly access an IBM® i service program by way of a native binding, the following rules apply:

• Parameters must be of a fixed length. For example, non-structured records and values of type STRING are not supported. Dynamic arrays are also not supported.
• The service can return an integer or no value. If the native service returns an integer, you can invoke a service operation named theOperation in either of two ways, as suggested here:

     theService myEGLInterfacePart {@BindService{}};
     myStatus INT;
  
     // either of the next invocations is valid if an integer is returned
     theService.theOperation();
     myStatus = theService.theOperation();

• The failure to access the native service or a non-zero return code throws the ServiceInvocationException exception, as described in EGL core Exception records.