How Zend Builds a Bridge
Can you modernize with Zend Bridge and PHP?
In February, we blogged about the Zend 5250 Bridge announcement (“Zend Builds a Bridge”) and we thought it was time to show you how it works in practice. As we noted at the time, the Bridge isn’t a silver-bullet solution, but rather a toolkit of possibilities. At the recent ZendCon, we were delighted to see how many IBM i users were either already using or planning to use the Bridge. Some of those users have had tremendous success in modernizing their existing applications using the combination of Bridge and PHP. Hopefully, we can bring you some of those stories here or in the magazine in the coming months.
The Bridge API comes in two flavors—procedural and object-oriented (OO). For the purposes of this article, we’ll be using the procedural APIs, which while a little less efficient (they’re built on top of the OO APIs), are easier to get your head around if you’re unfamiliar with OO programming.
Before we look at the PHP code, it’s important to understand the basic process involved in using the Bridge. In essence, the Bridge APIs let you write a PHP script that will act as the “operator” of a 5250 terminal. Your script must sign in, call programs and interact with those programs. When you first start working with the APIs, one of the things to get used to is that the 5250 session's output is your script's input—and your script's output will become the 5250's input. Of course, in most cases, your script will take the data from the 5250 and, in turn, display it in the browser for the real user. The user then interacts with that display and your script processes the input and reacts to it, which may or may not involve responding to the 5250 session.
Zend supplies three demonstration programs with the Bridge, two of them interface to the same 5250 subfile program. One uses the procedural APIs and presents a very simple interface that mirrors the functionality of the 5250 display. The other uses the OO APIs and AJAX techniques to supply a more sophisticated UI. The third program is a green-screen emulator that serves two purposes. First, it can be used to allow programs that haven’t been refaced yet to coexist seamlessly with others that have. Second, it can be used to help you identify the necessary field identifiers you’ll need to build your Bridge scripts.
Figure 1 shows this emulator in action running the 5250 application that we’ll be using. Notice that when the cursor hovered over the first customer number in the subfile, the emulator told us the identifier for the field was outputField 8. We’ll use this information in our Bridge script. There are other ways to establish the field references, but this is a convenient, interactive approach. Check out the sidebar for the PHP code for a simple utility function you may find useful when developing your own Bridge applications.
The application shown here is a simple output-only subfile, which we’ll be converting to use a browser interface. Since Zend already supplied basic subfile demonstrations that mirror the current 5250 operation, we decided we'd do something a little different in our code. Rather than implement paging logic, we decided to effectively convert the application to a load-all subfile (see Figure 2)—only displaying it to the user when all data had been received. No changes were required in the 5250 application. Clearly this approach wouldn’t be practical if we anticipated thousands of records in the subfile, but for smaller volumes it’s an interesting possibility.
comments powered by