Archive for Instructions

CM WebClient and Vector Graphic File Support

By Abram Darnutzer, Sr. Application Consultant

All modern browsers have scalable vector graphic (SVG) file support. But there are several display options for these files.

The simplest method is to display the file directly as an image:

<img src=”test.svg” alt=”My Test SVG File”>

However, in so doing, you lose a unique function of SVG files because it is no longer possible to dynamically change the images using CSS or the SVG code itself.

A better method is to embed the code directly into the HTML using the “svg” tag:

<svg x=”0px” y=”0px” width=”612px” height=”502.174px” viewBox=”0 65.326 612 502.174″ enable-background=”new 0 65.326 612 502.174″ xml:space=”preserve” class=”logo”> <ellipse class=”ground” cx=”283.5″ cy=”487.5″ rx=”259″ ry=”80″/> <path class=”test” d=”testing”/> <filter id=”pictureFilter” > <feGaussianBlur stdDeviation=”15″ /> </filter> </svg>

Then you can manipulate the SVG image with CSS, as follows:

.logo {

width: 200px;

height: 164px;


.test {

fill: #94d31b;


.test:hover {

fill: #ace63c;


.ground {{

fill: #787f6a;


.ground:hover {

filter: url(#pictureFilter);

fill: #896d3d;


Creating a template for CM WebClient to use this kind of functionality is straightforward. You just need some simple HTML, like this:

<span id=”/(!NameID)” class=”/(!CustomClass:nc:class=/(!Param:class))” style=”/(!DefaultCSS:nc:withPos=/(!Param:default))”>

<svg width=”/(!Size:x)px” height=”/(!Size:y)px”>



Then, add some code in the JSOnLoad and/or add an action to do a SetValue in CM WebClient. You will be able to control the contents of this SVG tag through CA Plex.

Alternatively, you can reference an existing SVG file directly in the browser. By using the Object Tag you can reference an existing file while retaining all the functionality embedded within the SVG file. However, you still do not have control over the file using CSS. To retain control, write HTML that looks like this:

<object type=”image/svg+xml” data=”” class=”logo”>


Manipulating Object Positions in CSS

By Abram Darnutzer / Sr. Application Consultant

With HTML5/JavaScript applications, item positioning on a screen falls into two categories: relative positioning or absolute positioning. Absolute positioning for mobile applications should be avoided (with few exceptions) since mobile devices vary greatly. Relative positioning can be tricky to get just right, however. Below are a few quick and easy tricks to position items better in your app!

Header Setup

A typical header region contains two things: a centered logo and a back button in the top left corner. (You should limit the area to include 1-2 other items since you don’t want to overcrowd the space.) If you use Sencha Touch’s spacing to set this up, you may notice that your logo will be off-centered because the items on each side of the logo are different sizes. We can do some simple CSS to avoid this eyesore.

If you want an item to appear in the top left:

.TopLeftButton {

position: absolute;

left: .2em;


If you want an item to appear in the top right:

.TopRightButton {

position: absolute;

right: .2em;


And for the centered logo:

.CenteredLogo {

height: auto;

margin: auto;


You’ll end up with something like this:


The code is setting a discrete constant distance between the left and the right buttons from the edge of the screen and marking the logo margins as equal to the left and to the right. (Note: Since the left and right buttons are position absolute, they do not factor into the margin calculation.)

Displaying a Button Image Over Button Text

In WebClient Mobile, the button image and button text will appear on the same line by default because they both use the Span HTML tag, which displays items on the same line. Getting around this issue is simple.

For the button CSS:

.Mybutton {

display: table-cell !important;


For the button image:

.Mybutton .x-button-icon {

vertical-align: top;

margin-left: auto;

margin-right: auto;


And for the button text:

.Mybutton .x-button-label {

display: table-row;

vertical-align: bottom;


This will produce a layout like this:


These methods will ensure that your carefully designed objects will display optimally on whatever device your customers choose!

File Upload for WebClient

Follow the attached steps to implement a file upload from your browser to the web server.

1)    Import the attached (“FileUploadServlet”) Java Project into your Eclipse Workspace.File Upload

2)    Right click your Java Project, and select Properties. Under “Java Build Path”, add reference in the Projects tab to the “FileUploadServlet” project. And in the Libraries tab, add a reference to the “commons-io-2.1.jar”, which is in the “FileUploadServlet” project.

3)    Right click your Web Project, and select Properties. Under “Java Build Path”, add reference in the Projects tab to the “FileUploadServlet” project.

4)    Right click your Web Project, select New, then Servlet. Add the existing UploadServlet to your web project. This will update the web.xml with your new servlet.


5)    In your file, add the following setting. The value should be /”Your Web Project”/upload. If you want to change the url-pattern for your upload servlet in the web.xml file, the “/upload” part of this setting will need to change to whatever you set your url-pattern to:

        # Upload Servlet Location



6)    In Plex, create an upload pattern function called “~WebUploadShell”. This should inherit from “~WebShell” and “~DetailPopup”.


7)    In “~WebUploadShell”, add a field to the panel called “UploadFileName”, in a region called “UploadP”. This field will inherit from “FIELDS/FileName” and have two values added to it which are shown below.


8)     In the panel editor for “~WebUploadShell”, hide the label for “UploadFileName”, and add the following control name to the edit for “UploadFileName”:



9)    In the panel editor for “~WebUploadShell”, create an event called “UploadComplete” and attach it to the “Updated” physical event for the “UploadFileName” edit control.


10)    In the action diagram for “~WebUploadShell”, add the following code:


11)    Now that the patterns are created, have whatever function you want to have upload capability inherit from “~WebUploadShell”.


12)    In the “Edit Point Set Upload Folder”, you will need to set where you want the file to upload to UploadP<UploadFileName> and do a Put UploadP. If you need to perform code when the upload completes, please put this code in the UploadComplete event. When running, the UploadFileName field will appear as an upload button. When clicked, it will take you to a file selection window, when selected, the file will begin uploading.


NOTE: The placement of the UploadFileName field in the panel is based on a different html form than that of regular WebClient. It positions relative to the top of the panel, not relative to other objects. So, it will take some experimentation to get the placement exactly how you want it.

iOS App Tutorial for CA Plex / CM WebClient


Developers that have started using CM WebClient 1.8 Mobile’s touch optimized templates usually find that creating a mobile web app deployment is straightforward. But while deployment as a web app is acceptable for some, other developers creating commercial and specialized applications often benefit from native deployment. For example, you may need to use the camera to capture pictures or scan documents, implement a signature capability, or access the phone contact database. CM WebClient supports this style of native application using Adobe/Apache PhoneGap. There is a Camera and Signature template available, and you are encouraged to create your own device templates and share on the WebClient Mobile Google Code project.

This tutorial is for Apple devices (iPhone / iPad), and also requires use of a Mac to run Xcode and to meet Apple licensing requirements. If you are targeting Android or Blackberry devices, you will need to follow a similar but different procedure for each device platform. I.e. your core code remains the same, but the PhoneGap native wrapper is different for each technology. PhoneGap has tutorials available for every supported platform.

Download and Install Software

For this part you need access to an Apple Mac. Point the browser from your mac to the Apple developer website, Download the latest version of Xcode and the iOS SDK’s. It is over three gigabytes, so you may want to have a couple coffees at this point. You may also want to take some time to sign up as a developer, either individually or within an organization. Organizational approvals can take weeks to process by Apple, so it is always better to do this well in advance of needing to upload your app for public distribution.

After you have installed Xcode, download the PhoneGap distribution from This example is using version 1.3.

Run the installer


Follow the steps on the installer wizard


Create Your Xcode Project

Open Xcode and select “Create a new Xcode project”

New Project

Choose PhoneGap as the template for your new project


Give your project a name and identify your company. Typically your organization / company id will be your domain name in reverse word order. It is important to deselect Automatic Reference Counting – otherwise build errors will result.


Select a directory location for your project. A subfolder will be created beneath the directory you select to contain your project. It is recommended to also create a local repository for source code changes – that way you can easily revert if you make a mistake.


Next, enter project information. You can drag and drop application icons if you wish (you can do this later if you don’t have any  icons prepared).


Keep scrolling down and enter iPad information as well as application launch images (splash screens). Do not enter Entitlements unless you know what to fill in.


Hit the validate setting button to make sure all is ok


You may get a window like this. Accept this recommendation.


It is recommended to select the automatic snapshot option


Configure and Run

You will now see the Xcode workbench. First we have to run the application once in order to create a “www” folder that contains the Phonegap startup code and resources. Select a simulator target and hit the run (play) button.


You will see this error in the simulator – this is expected and is not an issue. It means that your app cannot find a start page.


This next step is very important and must be done exactly as described. We need to create a folder reference in Xcode to our www and javascript resources. You do this by opening Finder and dragging the “www” folder beneath the project onto the Xcode project work space. You will see a green plus sign indicating the drag target is accepted. You will then be prompted to create a reference to this folder.


Use the following settings


Run your project again, and you should see that PhoneGap is now working. The HTML5 and JavaScript you see are running directly on the device, not served up by a web server.


Connect your application

The next step is to connect your CM WebClient pages to PhoneGap. There are two parts to this.

First we need to add a whitelist entry to allow your app to access external resources. You do this in the PhoneGap.plist file.


Next, add some JavaScript in the index.html file to access your dynamic content. For production applications, you will want to create some static web pages and a mechanism to check the online status. This is straightforward but beyond the scope of this tutorial.


Run your app again from Xcode and you should be rewarded with your app on your device emulator!


Congratulations, You Are Deployed!

You need some further steps to deploy your app to physical devices and to iTunes. Stay tuned for more blog posts, or contact us at CM FIrst for assistance if you are on one of our support plans.


Movie – Debugging on Devices with Firebug

Movie on how to turn on the iOS device JavaScript console and enable Firebug debugging

Authenticate to the IBM i with WebClient

In many circumstances you need programmatic control of the IBM i authentication process, for example in single sign on situations. Please follow these basic steps for to implement.

Note that this method will work for both standard WebClient and for WebClient Mobile applications

1. Create a Plex function to accept your User Id and Password. You can create a panel for the user to enter in this information.

2. Add variables to the Local context:

  • IBMi Connection Property
  • Property Value
  • Return Value

3. Add Java source to authenticate the user to the IBMi


	   try {
			&(4:).set(new ObCharFld("   "));
			AS400 myas400 = new AS400(&(1:).getValue());        
	   	catch (AS400SecurityException i) {
			&(4:).set(new ObCharFld("INF"));
		catch (Exception e){
			&(4:).set(new ObCharFld("ERR"));

4. Once the user has been authenticated to the AS400, Java API calls are used to complete the process.


5. Make sure the file is located within the Java project in WebClient.


6. Obtain jt400.jar (Supplied by IBM) and add to your build path / deployment assembly in Eclipse. Compile and run the process.

First add to Java Project and add to build path

Copy and paste the jt400.jar file into the root of the Java project. Then right click and choose the build path option, libraries tab. Choose add JAR’s button.

Then add to Deployment Assembly in the Web project

Right click on the Web project. Select Properties, and select Deployment Assembly. Choose “Archives from Workspace”, then add the jar from the java project.




Note: This process is very similar to a standard Plex login to the IBMi. In client-server CA Plex apps each user has their own local copy of The difference here is that WebClient maintains a user copy of the file in the session.  So that the login is maintained for a specific user for a specific session

Contributed by Mark Schroeder. Mark can be reached at


Linking your CA Plex Java source folders in Eclipse

For many developers it is more convenient to link your CA Plex GEN folders directly into your Eclipse workspace, eliminating the need to run ANT scripts and move the Java source files. Eclipse will detect the fact that you have generated / changed your source files from CA Plex and will automatically build if you desire this.

To configure, follow these steps. You will link to the GEN/Src directory and to the GEN/Src/Res directory as generated from your Plex application. You will need to enter an exclusion pattern to avoid showing duplicate resource files in your project.

First, Right click on your Java project and select Build Path / Configure Build Path…

Next, select the link source button. Then enter the following path the your Plex GEN/Src directory:

Click next, and enter an exclusion pattern

Click Finish. Repeat for the Res (resource) subdirectory but do not add an exclusion pattern

You are done! Verify your path looks like this.


For large generate and build requests, Eclipse may compile before you finish generating. If you get out of sync, simply Refresh your Java project to rebuild any changed files.

WebClient Web Application Server Listener

To add an application server web session listener to your WebClient application, ensure that this  XML fragment is present under the web-app element in your web.xml.


When the listener is installed, then application clean-up will occur immediately when the session times out (as determined by the application server’s timeout settings). The user closing their browser window will also trigger a session clean-up. This is particularly important for WebSphere implementations.

WebClient January 2010 Newsletter Published

 The January 2010 WebClient newsletter is available at this link.

Highlights of this edition include:
  • New guide published for deploying applications to Websphere
  • New tip published for implementing an Ajax style wait cursor  
  • Version 1.4.19 released
  • CA World planned for May 2010, with extensive virtual conference. WebClient will be on display.

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!

© 2013 CM First Group - All rights reserved