Archive for Integrations

Running CA Plex Java on (virtually) any platform

Is Java truly write once run everywhere? In years past, it was often not the case but in the modern day it is more or less true. And you can run your Plex Java apps on many platforms with good performance, given a supported database and JRE. This is a very nice situation for the ISV or corporate developer who needs to rehost.

In practice is is advisable and desirable to run and debug a CA Plex java app on a Windows or another platform during the development process, such as Mac OS, Linux, iOS, Unix (Aix), or zOS. By far the easiest way to accomplish this is by using the free Eclipse IDE, or if you already have IBM Rational – then you can use this version. The Eclipse (Rational) product runs on virtually every major computing platform, from PC’s to the big iron iOS or zOS. If you do purchase a Rational version, you will have the added benefit of being able to debug not only Java, but RPG and COBOL as well. This is nice if you are trying to debug a full featured multitiered web app, running both in the web container and back end server. WebClient supports this style of application architecture.

The examples below use Eclipse for Mac and CA Plex 7.0, but the steps are the same regardless of platform or version. Mac OS is particularly useful for mobile device development, for example you can run your CA Plex WebClient apps on iOS devices such as iPhone and iPad by using Xcode and Phonegap.

First Step – Install the Eclipse or Rational IDE

Before installing, download and install a matching JDK from Oracle using this link. The JavaSE version is appropriate for most cases.

Next, download and install Eclipse or Rational IDE. You can download a open source version of Eclipse from this link to match your target platform, or go to IBM for a version that runs on an IBM host (PowerSystems, zOS) (warning, fees may apply). We recommend downloading the J2EE version so you get most necessary tooling included.

Second Step – Create a Java Project and Link your Plex source

Go to menu File / New, select other, then select Java project



Give it a name of your choosing



Third Step – Add ObRun and JDBC / Third Party Jars

Copy and paste any external jar files you may need into the project root. This includes both CA Plex product jars and JDBC jars for database access. Note – you can leave the jar files in place and add to the class path or reference by path. However, if you do this the resulting Java project is easily not portable between machines.

If you are not using WebClient, you will need to make sure the ObRun.jar is copied from the Plex product files. If you are using WebClient, then this will happen automatically when you add the WebClient nature to the project. See the WebClient user manual

After you copy and paste the jars into the project, you need to configure the build path to use the jars.



Select the jars you copied from the first step


Final Result


Fourth Step – Link to your CA Plex generated source

In this step simply link to the CA Plex generated source directory (under your model GEN folder). First remove the src directory from the build path and from the project. Next you will  link the Src subdirectory (with an exclusion to Res), and then link the Res directory.

Go to the build path and start with an empty screen. If you see a src folder, first remove from this screen then go back and delete the directory from the project itself.


If you get the message “directory exists with a different case” later it is because you need to remove the default src directory first!

Next, add a source folder for Plex bitmaps / GIFs. Copy the Plex BMP3 files into this directory


Next, use the link button to link to your CA Plex Gen/Src directory, where your Java source resides


Add an exclusion pattern to exclude the Res source directory (it will be added in the next step)


Link the Res directory in the same manner as Src


Your final build path for source should look like this:


Fifth Step – Compile and check for errors

Eclipse will automatically and incrementally build your CA Plex source as you generate – and will do so much faster that you can generate!

Check the “Problems” tab for any errors. Usually these errors are the result of C++ code injected into the java code. You will need to variant / clean up any native C++.


Sixth Step – Set up a run configuration

Click on the green “Play” button drop down to access the “Configurations” menu. Select this.


Type in the Name, Project (or browse), and the main class “ObRun.ObPanel.ObLaunch”


Click on the arguments tab

Type in the package.class name followed by “path= “, e.g. MobileApp.ConfMenu “path= “. Note the space between the = and final quote.


Congratulations, you are running Plex Java natively (in this case on Mac OSX Lion accessing MySQL)


Recommended Mockup Tool for Mobile/Web

We have received some recent inquiries on wireframe mockup tools for web and mobile application development.

Although there are many available, we recommend this one as the one we use.


Deploying CA Plex/WebClient Apps on IBM WebSphere

Deploying CA Plex/WebClient applications on the IBM WebSphere Application Server can be more challenging that on Tomcat – although the process is largely the same conceptually, WebSphere has more features, options, and versions available. This guide is written with IBM i in mind, but the steps can be generally applied to other versions of WebSphere running on Windows, Linux, AIX, or zOS. Please note that this guide only covers a small portion of total subject of WebSphere administration – for further information, please visit IBM. One good link to start from is

 This guide has been written by Matt Fleming, Application Consultant and WebClient support technician. Matt can be reached by contacting WebClient support, or at


The first consideration that you will want to address when deploying WebClient with WebSphere on the IBM i is that you have compatible versions. WebClient requires Java 1.5 or better. WebSphere versions 6.0 and below do not use Java 1.5 and are therefore not compatible, so you will need version 6.1, 7.0 or higher. Additionally, you will need to verify that the version of i5 OS is using Java 1.5 or better. Furthermore, you will want to verify that all of IBM’s recommendations for deploying WebSphere are met, including the correct version of the operating system on the IBM i.

Once you have verified the versions, the next thing to consider is the differences that exist between the windows based deployment in Apache Tomcat or Jetty and the iSeries. To prepare your WebClient application we will help you address these differences.

The first thing to look for is the references that the web project uses for logs and other files. Locate your web project (usually named [projectname]web) in Eclipse, and expand the view of that project in the JavaEE perspective. You should see your WebContent folder there. Expand that, and then the WEB-INF subfolder within it. This is where the J2eeProxy.prop file is that contains the references that we will need to change.

If you are going to be doing continual development, it is best comment out any windows-specific entries that we will change below by placing a # symbol in front of the line. You can then make a separate entry for the IBM i specific values. This approach makes it easy to switch back and forth as you can test on the windows side before packaging for deployment.

Look first for the section entitled “Websydian Server section”. One of the first entries there is ‘websydianserver.ipaddr’; ensure that this has the proper reference to your iSeries. In that same section there are two entries for files. One for the license file and one for the log file. These paths will likely be in windows format by default. These entries ( ‘websydianserver.log.file’ and ‘websydianserver.licensefilepath’) will need to be changed to an IFS file path (or other file system path depending on platform). This file path that you enter here needs to be a path that exists and that is accessible at runtime by the web server.

Next, in the ‘Log section’, you will also need to change the entry for ‘servlet.log.file’. As before, this needs to be a valid IFS path, and needs to be accessible at runtime. Also, ensure that the read/write permissions are set up correctly for these locations so that at runtime these log files can be accessed.

Another good step in ensuring that your WebClient application is ready to deploy is to test it using Jetty or Apache Tomcat before beginning the process of deploying to WebSphere. That will ensure that your application has all of the necessary references that will be included in the deployment of the application, and will help you test minor fixes more quickly. If your WebClient application is missing a reference or has an error it is best to fix it before packaging the application for deployment in WebSphere. Don’t forget to make sure that when you test in Windows, that you comment out the IBM i specific entries with the # symbol, and remove that symbol from the Windows entries. Also make sure that you do the reverse before packaging for deployment to WebSphere.

Packaging for deployment

This step is quite easy. However, as mentioned, it is best to ensure that the WebClient application works in Windows before doing this step. This will help you in troubleshooting and in ensuring that you don’t have to re-deploy multiple times.

After making the preparations listed above (ensuring that the entries in the J2eeProxy.prop are set to the proper IBM i specific values), go to the JavaEE view in Eclipse. Right click on your web project, and go to the Export option. Click on WAR File, and you will see a dialog for the WAR export. For the Web Module value, leave it as the name of your web project; you should not have to change it. Select a path for the destination value where you want the WAR file to be copied to, and click Finish.

This process will build a Web Application Resource file using your WebClient web project, and all of its references. When it is finished the .war file will be ready to deploy to WebSphere.

Deploying in WebSphere

If you have used it before, you know that WebSphere can be a very complicated tool. Even small deployments can be difficult without the proper expertise in the WebSphere product. The good news, however, is that as far as deploying goes, there is nothing specific that WebClient requires that is not common to other project deployments in WebSphere.

Before you begin the deployment, you will need to identify context root for the war file. This information is stored in your web project, so we will get that before continuing. To see this information, right click on your web project (the same one that you packaged in the .war file) and select Properties. In the window that comes up, click on the Web Project Settings in the list on the left. What you will see on the right-hand side of the window is the Context Root. Copy the text from that box, and save it for later reference. You can then cancel out of this window.

The remainder of what needs to be done to deploy WebClient in WebSphere is within WebSphere itself. [Please note that different versions of WebSphere may have slightly different wording or differently designed screens] You will need to bring up the Administration Console in your browser to begin. (refer to your WebSphere documentation for details about the Administration Console). You will need to click on the menu item ‘Applications’ to expand it, then click on the ‘New Application’ option.

There will be several options for new applications; you will need to select the ‘Enterprise Application’ option. On the following screen, you will choose the ‘install’ option to deploy your web application in WebSphere. Once you choose this, it will give you a dialog that allows you to select the location of the file. Select the .war file that you packaged earlier and click ‘Next’.

For our purposes, we will select the ‘Fast Path’ option for settings since, as stated previously, WebClient does not require special settings or additional steps in WebSphere. Click next after selecting ‘Fast Path’ to bring up the installation options. If your environment requires specific settings, you can set them up here. Please refer to the WebSphere documentation for the purpose and affect for each setting. The default settings should be acceptable if your environment does not require additional configuration.

The next step is for mapping the module to the server. This is for environments that have distributed servers and load balancing. Clicking next will bring up the only screen where we have to add some information. All web applications must specify their context root, and WebClient is no exception. Paste the text we copied from the context root of your web project here, and then click next.

The Summary is next screen to display. Quickly review that the settings match your environment, and click Finish. That will deploy the web application to WebSphere. In order to actually use the WebClient application however, you must first start the server from the Administration Console; it does not start automatically. The name in the list of servers to start will be the same as the Context Root that you specified.

Now that the WebClient application has been deployed and is started, the next thing to do is to bring it up in the browser. The URL format is the same as it is in Tomcat or Jetty. The first part of the URL will be whatever the installation of WebSphere has specified it to be. It is followed by /[context root]/webclient

You will now be able to run your application under WebSphere!

Enhance your Plex Web Application with hints and grid stretch

Note this post has been developed by WebClient Application Consultant Matt Fleming of ADC Austin. You can reach matt at

Even with the style sheets, the base functionality of a WebClient i+ for CA Plex application behaves in the same way that the original Plex function did. While this is useful, we can improve the original application’s functionality to make it more web-like in functionality.

Let’s look at this Order function as an example. This post uses the WXPCOURSE model and application that is supplied as an example with your WebClient software install, and is typical of a standard Plex application. Lets look at a popup modal dialog first.

Click on the ‘Add new data’ button, and you will see the Insert pop-up display.

This pop-up now works exactly as it did as generate for CA Plex client-server. However, WebClient gives us the ability to leverage a great deal of modern controls and techniques that allow us to improve the user interface. In this exercise we will make some minor changes that can greatly improve an application.

1. Hint Text

Sometimes the labels on a data entry screen don’t convey quite enough information about what data is expected. Adding hint text helps new users to know what should be entered into that particular field and adding that functionality is quite simple with WebClient.

You already have the panel open, so just highlight the edit control of the ID field, and in the same manner that you added text to the Control Name of the Order Date, add the following line to the Control Name of the ID field:

CustID:MainArea:hint=Customer ID:default

Save the panel and close it. Generate and build to see the results.

You can see that in the ID field, the hint we placed there lets the user know that the ID we are looking for there is the Customer ID. When you click on that field, the hint text disappears, and allows the user to enter the data they need to.

2. Grid Stretch

In many CA Plex grid’s you have the situation that the grid is actually bigger than what the columns needed. Rather than adjusting the size of the grid manually, we can actually specify one column to expand to fill the empty space, allowing room to accommodate the possibility of a long field.

To use this effect open up an grid panel in CA Plex and bring up the properties for the grid. As before, enter a value into the Control Name:

Grid1P:MainArea:stretch=Grid1PItem Description:default

Generate and build to see the result.



We have only scratched the surface of the number of ways that you can extend and improve your application for use in a browser using WebClient.

New Feature Spotlight – Apache Axis / DB2 Web Query

The latest release of WebClient, 1.4.12, brings compatibility with the Apache Axis web service platform. Apache Axis is an open source java-based implementation that is embedded in many software products, including Apple’s WebObjects, BEA’s WebLogic, IBM’s WebSphere, and many others.

One use of Axis is to create and control IBM DB2 Web Query reports from WebClient/Websydian-based applications. Web Query reports can then be tightly integrated with the CA Plex-based application, resulting in a BI information that is easily accessible – without navigating the Web Query menu system. IBM publishes their SOAP API/SDK. Here is a link to one IBM article in IBM System Magazine. This article contains code samples, which can be implemented in a number of ways including using Websydian TransacXML or Java source code.

© 2013 CM First Group - All rights reserved