Using the WebFacing application bridge to interoperate with other Web applications

The WebFacing application bridge introduced in version 7.1 allows you to seamlessly interconnect new Web applications (written with EGL, for example) with existing WebFacing and/or HATS applications.

With this technology your applications can be quickly and easily modernized using WebFacing and/or HATS, and new Web applications can be added iteratively to take advantage of the latest Web technologies.

The application bridge allows WebFacing applications to transfer control and data to and from other Web applications such as EGL, giving you the ability to combine HATS, WebFacing and EGL applications into a single application. This goes beyond getting data from i5/OS® in a Web application using direct database access or by calling a batch program via a Web Service. It allows you to link your new Web application to an interactive i5/OS application and share data.

The WebFacing application and the corresponding Web application should be packaged as an EAR file for deployment. The EAR file can be created using the J2EE perspective of the IDE.

To support the interoperability between a WebFacing application and another Web application, a DDS linkage record should be created and the Application bridge Web Setting should be set for that record. A DDS linkage record is standard DDS record containing fields defined as hidden fields (usage H), that you can use to transfer data. The DDS linkage record is never actually displayed. It is simply used to transfer data and control to the Web application specified in the Target application URL of the Application Bridge Web Setting when your i5/OS application does a WRITE on the record.

Please refer to the Application Bridge Web Setting in Using Web Settings with your DDS source for further information on creating a DDS linkage record.

The WebFacing application bridge supports the transfer of control and data in the following scenarios:
  1. A WebFacing application calls another Web application with data; the other Web application returns control back to WebFacing with data updates.
    • The i5/OS application does a WRITE on the WebFaced linkage record (transfer control and Data to another Web application) immediately followed by a READ and waits for the data to come back.
  2. A Web application calls a WebFacing application. The WebFacing application will execute, and then return data back to the other Web application.
    • The i5/OS application does a WRITE on a WebFaced linkage record with the FRCDTA keyword and then terminates the application.

Scenario 1 passes data from the WebFacing application to the Web application specified in the Target application URL of the Application Bridge Web Setting when the i5/OS application does a WRITE and READ on the DDS linkage record. The WebFacing application will then wait for a response from the Web application. The Web application will then read the data via the "LinkageData" request attribute, make any updates and send back the updates to the WebFacing application at which point the WebFacing application will resume control.

Scenario 2 is supported through WebFacing programmatic invocation, which allows you to specify any CL command with or without parameters to start a WebFacing application. The WebFacing application runs, then passes data back to the Web application specified in the Target application URL of the Application Bridge Web Setting when the i5/OS application does a WRITE on the DDS linkage record. For this scenario, the FRCDTA keyword should be specified on the DDS linkage record so that the application can terminate successfully. Please refer to Programmatically invoking WebFacing applications from other Web applications for further information on programmatic invocation.

The WebFacing application bridge can be used to make WebFacing and/or HATS applications interoperate with other Web applications. HATS is enabled with WebFacing when a HATS and WebFacing project are linked using the interoperability feature. For linked HATS/WebFacing projects the application bridge can be used as in the following scenarios:
  1. HATS and Web/EGL: only the linkage record is converted/WebFaced in your WebFacing project; allows HATS projects to pass control and data to Web/EGL.
  2. WebFacing, HATS, and Web/EGL: part of your application is WebFaced and the other part runs as a HATS project; allows WebFacing and/or HATS projects to pass control and data to Web/EGL .

Passing control from WebFacing to another Web application

In both scenarios above, a WRITE is done on a DDS linkage record to pass control from Webfacing to another Web application. This is done using the J2EE forward method on the URL specified in the Target application URL of the Application Bridge Web Setting. The WebFacing application will use the first part of the target application's URL as the context root and forward the WebFacing application to the remaining part of the URL. If the target application's URL is /appContextRoot/appEntryPoint, then the WebFacing application will use appContextRoot as the context root and forward to the appEntryPoint. The WebFacing application will add the request attribute "forwarded" with the value "WF" in the request object prior to forwarding. This will allow the receiving application runtime to take any special actions, if necessary, on receiving control from a forward.

Passing control from another Web application to WebFacing

In Scenario 1, when passing control back to the WebFacing application and in order to have proper data updates, the Web application should add the attribute "forwarded" in the request object prior to forwarding. The request attribute should be "EGL" for a request forwarded from an EGL application and "CUSTOM" for a request forwarded from other Web application. This will allow the receiving WebFacing application to take any special actions, if necessary, on receiving control from a forward. The entry point for the WebFacing application is "/webfacing/WebFacing.do".

Exchanging data between WebFacing and other Web application

Application bridge data delivered via the DDS linkage record to the WebFacing application is saved in a Java™ HashMap, with field name as the key in the HashMap and field value as the value for the associated key. A request attribute called "LinkageData" will be used to provide access to the HashMap.

Field values in the DDS linkage record will stored as Unicode string data in the HashMap. The other Web application will update the fields in the HashMap as necessary and send the HashMap back to the WebFacing application via the "LinkageData" request attribute. A field value should contain those characters which are allowed by the corresponding DDS data type and have the proper length; otherwise, it will be discarded by the WebFacing application.

Note the following:
  1. Character fields and DBCS fields: no formatting is performed on these data types.
  2. Numeric fields: a decimal point "." will be inserted into the proper location in the data if the decimal position for a field is greater than 0; a negative sign "-" will be added to the beginning of the data for a negative number. For example, -000123.45 is the proper format for a numeric with length 8 and decimal position 2.
  3. Date fields: ISO format YYYY-MM-DD is used.
  4. Time fields: ISO format hh:mm:ss is used.
  5. Timestamp fields: ISO format YYYY-MM-DDThh:mm:ss.uuuuuu is used.
Note: When a DDS linkage record does not contain any fields, the request attribute "LinkageData" value will be set to null.
Related information
Programmatically invoking WebFacing applications from other Web applications

Feedback