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.
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.
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.