Meridian Awards 2010

Ceridian has touched on all five of the core criteria that exemplify this category of technical achievement. Namely, extending the use of Pitney Bowes Group 1 technology beyond the standard feature sets, creating a highly scalable and/or highly available application, pushing the limits of the Pitney Bowes Group 1 technology to create an optimal user experience, implementing a technically innovative solution and Integrating seamlessly with other products. This paper will get into the details of how we did this at Ceridian after noting how we addressed each of the core criteria.

When the Ceridian development team took over the development of our own programs for Pitney Bowes product called Streamweaver, the software used by Pitney Bowes mail insertion equipment, it was able to perform all of the functionality we needed. It had one drawback to its standard feature set though and that was the use of the DOS prompt to run batch files which in turn ran the Streamweaver programs. To the first point above we extended the functionality of our Microsoft Windows Streamweaver environment by creating a front end GUI program.

A side effect of the creation of our GUI front end also made our Streamweaver product more scalable because in the early stages of planning we decided to make the back end processes generic. This way any new Streamweaver applications, and converted old ones, could easily be implemented in the new environment. As for availability this was not an issue for our end users. In the old Streamweaver DOS environment they already had 24/7 access and we did not change this with the GUI front end.

The new GUI front end was a welcome addition for our end users. It now creates an optimal experience for them because instead of typing multiple commands, and hopefully in the right order, from a DOS prompt they now just point and click from a desktop shortcut. Ceridians production support teams experience is also optimized because instead of looking at a DOS window and hoping an error has not scrolled by they look at a pop up window which has each step of the process listed and stops at the errorred step. There is also a scroll bar on the side of the pop up window so the user has the option of scrolling back to all of the prior steps.

While the front end of the GUI program is important to the innovative solution we provided at Ceridian the back end is more so. What I mean by this is that by making generic batch files and using a database to control how the batch files and there parameters are called has made the whole process innovative. When discussing the problem of batch file use from the DOS prompt in Streamweaver with other companies and technology people at Pitney Bowes none of them have a solution. This process would actually be beneficial to other companies that use Streamweaver in a Windows environment. Besides other companies using this program and its back end processes it may also be useful for Pitney Bowes Group1 to include with their Streamweaver product for the Windows environment, perhaps through their professional services group.

The previous Streamweaver DOS Windows environment already integrated seamlessly with other products so this was not an issue for us. With that said one other advantage of having the set of generic batch files and using the database is that we can take existing Streamweaver applications and easily convert them to use the new GUI front end. So in that regard it integrates seamlessly with our old Streamweaver environment.

Now to discuss the technical details of our new Streamweaver process, starting with the front end program. One of the developers here wrote the front end executable in VB, which just as easily could have been written in C# or some other programming language. The executable can be placed on the Streamweaver PC as a shortcut to get the point and click capability. He designed the VB script to create pop up windows when running the executable. The first pop up window is a log in screen for security purposes. This serves two purposes, first, only the allowed users are able to log in. The second purpose is to connect the user to a database which the VB script uses. After logging in through this pop up window a second window will appear. At Ceridian we have several main systems that have their own separate products that we run through Streamweaver. On the window that is now displayed there are two drop down lists and two command buttons. The first drop down is to select a system to run, once the system is selected then the second drop down lets the user pick a product to go with it. The command buttons are either to exit the program or execute the Streamweaver process.

After selecting the system and product then clicking the execute button another pop up window appears and the back end processes start up. A note here, when in the designing phase for this process it was decided to make the back end batch files as generic as possible so creating any new Streamweaver applications, or to convert old ones, is as simple a task as possible. At this stage we can start discussing the usage of the database by the VB script; which in our case was Oracle but could have been SQL Server or some other database. In the pop up window that just opened up the VB script now queries the database for the system and process selected. Once these are found in a database table it will then query another database table for the batch files it will use based on the previous selection. The batch file query will also use an order by clause to determine which order the batch files will run in the VB program. This will eliminate an area of potential problems we were having with running the batch files from the DOS prompt, batch file B could accidentally be run before A. There are two other items of interest in this Oracle table. One is the batch files when run will return an errorlevel value that we have built into the VB program to check. If the maximum allowed value stored in the table is exceeded for that batch file then the VB errors out and stops the whole program. This means that in the pop up window each batch file is displayed as a step and if one of the steps (batch files) errors then it displays an error message for that step and stops. Regardless if one of the steps errors or they all complete there is an okay button at the bottom of the pop up so once all the steps complete, successfully or with an error clicking the button will close this window and bring you back to the previous window. In the previous window you would now have the option of selecting and executing another system and process or clicking on the exit button to end the program.

These pop up windows described above are all there is for the end users experience but again there is more going on behind the scenes. Above it was mentioned there are two items of interest in the table for selecting which batch files to run, one was the maximum errorlevel value. The other item is a flag column that tells whether to run the batch file called in that step or not. The purpose of this would be for the development and/or production support teams. Say we need to debug a particular application that errorred if necessary we could set the value to N for all the steps that followed a step that errorred then we would be able to stop the whole process there and check files generated or anything else that would be helpful to fix the error. Another possible benefit of having this flag value could be if a step became obsolete we could change it from a Y to an N and the program would now skip that step.

The batch files called by the VB program would have parameters and this would be handled by a third database table. Based on the batch file selected in the previous table this third table would then be queried picking up all of its parameters. Again an order by clause would be used to make sure the parameters are in the right order, parameter 1 is selected followed by parameter 2, etc.

A few words about the generic batch files, after the development team analyzed the existing Streamweaver DOS batch file processes we discovered that they all did a small group of basic functions. This is what lead to the generic batch file set we developed for the VB front end program. To further explain we found that the flow of all of the Streamweaver applications was to copy, move and delete files. On top of this we would need to run the actual Streamweaver executable to generate the Streamweaver output. While we could not make the batch file generic which runs the Streamweaver executable, mostly because all of our Streamweaver documents had a unique format, we did create a wrapper batch file around it to handle the calling of the executable. For the rest of the flow we were able to create generic batch files. There are four main generic batch files and their names explain what they do, Concatenate_Files.bat, Copy_Files.bat, Delete_Files.bat and FTP_SW.bat. We do use other generic batch files but they are unique to our particular situation at Ceridian.

The last technical detail to discuss is another database table which could be considered optional. This table is an audit table. There are pros and cons for using the audit table. The reason we are using it at Ceridian is because it keeps a history of every job we ran through the Streamweaver VB program. This is important because once the end user clicks okay on the VBs pop up window that displays the steps and final status of the particular Streamweaver job the pop up window closes. This means the user would not be able the see the steps anymore. That is the pro of using this table. The con would be that while the other three database tables are fairly static in size, the number of rows only increases with a new Streamweaver application, the audit table size will grow every time a system and process is run through the VB program. This would be a design consideration of anyone planning on implementing this VB program and its back end processes. One of the items stored in the audit table is an id which ties the audit table row back to which system and process was run. At Ceridian we store an item we call a job id which we use to track each run of a system and process through Streamweaver. This is also stored in the audit table row. Both of these columns will have multiple rows in the table because the audit table is broken down to the batch file steps level. In other words, if a particular system and process is run through Streamweaver then the audit table will keep a row for each of the batch files run for that system and process. The other items of interest in the audit table are an id that ties back to the batch file table, a start and stop date and time for the batch file run, and a return code and comment for the status of that batch file run. This wraps up an overview of the technical details of this paper.