The WebFacing application bridge enables 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 IBM® i 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 IBM i application and share data.
The WebFacing application and the corresponding Web application can be packaged as an EAR file for deployment. The EAR file can be created using the Java™ EE perspective of the IDE. However, the WebFacing application and the Web application can also be deployed as separate EAR files within the same application server instance.
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 IBM i 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 IBM i 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 IBM i 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 Java EE 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.action".
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.