Part of what I have been doing was getting all my financials ready for my accountant to do his annual review and my taxes. This is my first year running a business in the US and I do a lot of my own accounting. So I spent a lot of time working with Quickbooks, Quicken, and TurboTax. At least that work is out the way, but I learned some interesting stuff that I want to experiment with over the next few months, so look for a couple of posts in the upcoming months on integration with Quickbooks from various directions, including OpenEdge, Progress FUSE, .NET, and Java (specifically Eclipse RCP).

Another thing I have been working on is integration between Microsoft Exchange Server and OpenEdge using Progress FUSE. I have been working on this in conjunction with a business partner and we are going to be providing some interesting experiences and samples of making that integration happen.

I have also been working on a .NET version of the Dynamic OpenClient example that I posted a few months back. I hope to have it ready for release by the end of April.

My company, Intangere, is in the process of developing some very exciting code for those of you that are Progress customers looking for alternative integration strategies with Progress, and we have an announcement that will be coming early in the second quarter.

So look for some very interesting technical posts over the next few months…

Windows 7

Windows 7 has now been running on 4 machines here at home since I installed it back in November. Three of the 4 are 32-bit machines. The other is a 64-bit machine.

Two of the 32-bit machines are used by my two teenage kids. My son is studying drafting at college and he uses his machine extensively to run various CAD packages, including AutoCAD. He reports that his machine is much more stable now than it was with Vista, which was what his machine shipped with in March last year.

My daughter is at college, too, but her use of her machine will never really show up any major problems. She uses all the standard stuff like MS Office 2007 and Internet Explorer 8. She used to complain a lot about her machine going to a black screen prior to the Windows 7 upgrade, but I have heard nothing new since.

My wife uses her machine for college studies and accounting-related stuff. We run both Quicken and Quickbooks and it all works fine. We have not seen anything on her machine that causes a problem with one exception.

Slideshow Screen Saver Hangs

We have a couple of LaCie 2-Big network drives that contain shared data and backups. Among the shared data on one of the drives is our library of photographs. My wife uses the built-in screensaver that creates a slideshow of photographs onto the display. We have found that this screensaver will work for a period of time, but when she comes back to the machine to start working again, the machine freezes on the screensaver. We have switched to different screensavers and we don't have the problem with others so we are putting it down to that.

I have seen a similar problem on my 64-bit machine with the screensaver, but the difference is that the interface only becomes unresponsive for a period of about 20 seconds. After that it comes back whereas with the 32-bit machine, it hangs permanently.

Other Applications

On my 64-bit notebook I am running a lot of stuff, including Eclipse v3.3, 3.4 and 3.5, Java 1.5 and 1.6, Java EE, Glassfish, MySQL, Visual Studio 2008, DIRECTV Supercast which allows me to watch NFL games on my notebook, and Netflix's video player. Other than the issue with the screensaver, I have had no problem with this machine. It has been substantially more stable than when it was running Vista and I'd go as far as to say that it is more stable than my work notebook which runs Windows XP SP3.

Homegroups

A couple of people asked me about Homegroups and how effective they were. I set up a homegroup expecting that it would simplify things, but all it really does is ease file sharing. There is not a lot of value to it that I do not get from having a central share on the LaCie 2-big drive, so I have switched off the homegroup functionality.

Google Chrome Browser

I installed Google's Chrome Browser on my machine a while ago, but had not really used it. I had been using Internet Explorer 8 and did not really spend much time evaluating it.

A while ago, I was looking for a browser I could use at work. Corporate restrictions had me using Internet Explorer 6 which is not satisfactory. I had previously used Opera, but it fell short on a number of things that I needed it to do. I decided to re-evaluate Firefox and Chrome.

I ended up going with Google Chrome. Chrome is much faster than any of the others. It loads instantly and the first page comes up immediately. Screen-painting is instantaneous. When I compared this with any of the others, whether Firefox, Internet Explorer or Opera, there is just no comparison. Internet Explorer 8, for example, takes 3 or 4 seconds to start and another second or two to download my home page which is on my local network.  Firefox is even slower. Chrome is literally instant. The load time is imperceptible.

There are some things, though, that don't work with Chrome. Hosting a web meeting using AT&T's web meeting software does not work, but Webex does. Most plugins work as expected, but occasionally I run into pages that don't and I am forced to switch to Internet Explorer to work around those.

Another big thing with Chrome is that even though I use it on all my workstations, I have never had it crash or hang. I cannot say the same for either Internet Explorer or Firefox.

More than 90% of my browsing is now done using Chrome and it just works. What's interesting is that Chrome is new software and it is more stable than Internet Explorer or Firefox. If this is any indication of what is still to come, I think Google is onto something.

Conclusion

I am very satisfied with the improvements in Windows 7. I would be very happy if I could replace XP on my workstation at work with Windows 7. There are some nice features that I have gotten used to. I prefer the Windows 7 task bar. I also like being able to drag windows to the side of the screen and have Windows figure out that I want the windows tiled next to each other. Mostly, though, I am happier about the stability and I have nothing that I have tried to run that does not work on Windows 7, so I am pretty satisfied with it. I feel like it is generally faster than Vista was, but I could not substantiate that with empirical data, so it is really a feeling more than something I can substantiate.

I am extremely satisfied with Chrome and I am now running it on my Linux boxes as well. It's fast, and it works. It has become my browser of choice.

Internet Explorer 9

On Wednesday, Microsoft announced a significant re-investment in Internet Explorer. After just three weeks of development, they are talking about Internet Explorer 9 and its new features. When I read the announcement, I didn't think it said much so I was wondering why it was that Microsoft was in such a hurry to get what I thought was a very half-baked announcement out there.

The crux of the news is that Internet Explorer 9 is going to contain some significant enhancements to the way that it uses hardware and this should make it perform much better. It is also going to be far more standards-compliant, and we're not just talking Microsoft standards, if Steven Sinofsky is to be believed.

My take was that if I could just get it to stop crashing, that would be a good start. All the problems I have had with Internet Explorer have resulted in me installing virtually every browser out there, including Safari, FireFox, Opera, and, more recently, Google Chrome. Actually, IE8 is much better now on Windows 7, but I have been fishing for something else for a while.

Google Chrome Browser 

Yes, for those of you that are not aware of it, Google has its own browser, too, called Google Chrome, and it is available for all Windows platforms. There have been 30 million downloads of the software and I have been using it now for quite a while. It works well on Windows 7, too.

Actually, Chrome is my favorite browser, largely because it works with everything and it is much faster than any of the others. The pages on my DSL line at home are there instantly. I have not found anything that Chrome does not do… very well.

Google Chrome OS

The reason Chrome is so interesting is because of Google's announcement in July that it was entering the Operating System market. Google firmly believes that the future of computing is in the cloud. Their operating system, to be named Chrome OS, is intended to run on netbooks and the Chrome Browser is intended to be the interface that is used to do everything. Applications will be hosted in the Chrome Browser as web apps, and the operating system will be free and open source.

On Thursday, Google released the code for Chrome OS as open source and announced more information about it. It's being based on Linux and will be released to consumers a year from now.  From the post, Google is trying to address 3 issues with Chrome OS:

1. Simplifying user experience by making everything a web app and avoiding the need for users to have to install and manage programs;
2. Improve security by running everything inside the Chrome browser; and
3. Significantly improve performance by improving startup speed to a matter of seconds.

Is Chrome OS Already Tarnished?

Tom Krazit of CNET attended the announcement meeting and posted a detailed account of the meeting. One aspect of his post raised some concerns. According to Krazit, Google is going to specify components for Chrome OS netbooks and existing netbooks will not work. Furthermore, Chrome OS will not run on hard drives; it needs solid state drives. That means that you can forget running Chrome OS on your existing notebook. 

Bottom line: You have to buy a brand new netbook to run Chrome OS. 

In this economy, Google expects us to go out an buy new hardware to run their OS when many of us have gone through upgrade processes recently to support Vista/Windows 7? That makes no sense. My kids, my wife and I would all probably switch to Chrome OS on netbooks if it was supported on existing hardware. We are all at least 3 years from buying new hardware so Chrome OS will have to wait.

Of course… I will get a new netbook with Chrome OS because I am a technology junky, but my point is that I don't believe the market can bear this right now. 

The Timing of Microsoft's Announcement

I started out this post talking about Internet Explorer 9 and how I thought Microsoft's announcement is half-baked. They showed up at their Professional Developers Conference in LA and Steven Sinofsky was demonstrating IE9 without the normal fanfare that is associated with a new product launch.

It was only when I read Tom Krazit's post that it suddenly dawned on me why this was so important. Microsoft is still on its heels with the internet. Microsoft never took the internet seriously when it first started because they never saw it as a viable mechanism for making money. They woke up to that late in the 90s and built Internet Explorer to fight Netscape because they saw Netscape as a potential threat to their dominance on the desktop.

Remember: Microsoft makes money out of two products: 1) Windows and 2) Office. Everything else is chump-change, comparatively speaking. Threaten Windows or Office revenue, and Microsoft has serious worries.

Google is not just threatening Windows with Chrome OS; They are also threatening Office. If their operating system will store everything remotely and all apps are web apps, Microsoft has a serious problem if Chrome takes off.

Google made it clear in July that this announcement would be coming. They also indicated they were communicating with partners about hardware.  Microsoft has to be worried because no one there thought that Google would still be a serious internet company in 2010, but Google is very much there, and growing, albeit much more slowly than earlier. 

The fact that Chrome OS is going to require new hardware is exactly the reason that Microsoft made what is going to prove to be a very, very important move. If IE9 is able to do all that Steven Sinofsky says it will, especially in terms of the standards compliance, Google could be in trouble. At least with IE9 I will be able to use my existing machine. With Chrome OS, I have to buy new hardware. Microsoft may just have been given the Get-Out-Of-Jail-Free card it needs. You can bet they will use this time to get ahead and Google will be left playing catch-up.

Machines

We have 4 Windows boxes at home. Three are HP 32-bit notebooks and the other one is an HP 64-bit machine – mine. We bought all 4 machines during the course of this year and all came with Windows Vista. We have had no end of trouble with Vista. The machines work fine, but a lot of applications generate exceptions and hang under Vista that work fine on my XP box. So I decided to believe Microsoft's advertizing (probably a big mistake) that indicates that Windows 7 has been thoroughly tested. 

Preparation

My experience with Microsoft's upgrades have been patchy, at best. So I left this task as the very last task that I would perform before I start class on Monday. I figured on doing a complete reinstall if I needed to. Past exeperience, especially moving from NT to XP, taught me that a reinstall was a very likely possibility. That meant I needed to have everything else taken care of before I started.

I have a lot of stuff on my machine. My local drive has 195GB of programs and data on it. I am fastidious, though, about keeping myself up-to-date with the latest versions of software. This means that I did not need to do much in terms of getting the latest versions of software. Norton 360 does my backups for me so I did not need to do a new backup before I did the upgrade. So once I got the DVD, I could go ahead and install.

Upgrade

I started the upgrade on my 64-bit HP Pavilion Entertainment PC at around 4pm on Friday afternoon. I had to deauthorize my iTunes account as one of the preconditions to the install, but that was the only thing that the upgrade process identified as a potential problem. Once that was done, the process started and ran… and ran… and ran… and ran…

Around 10:00pm (6 hours later!) the install utility asked me for the product key, rebooted, and the upgrade was complete. I immediately did the on-line activation and ran Windows Update to get any updates that were necessary.

Windows Update installed several updates (I believe it was 38) and I restarted the machine again.

All told, the upgrade took about 7 hours, which is an insane amount of time.

Outcome

I spent most of Saturday morning testing everything and I had no problems at all. Now that things have settled down, I am very happy with the upgrade. Internet Explorer is working whereas before it was giving a lot of trouble. My machine is performing much better and all the applications I have installed work properly.

As I write this, I have DIRECTV's SuperCast software running with today's football games streaming and it works fine.

I spent Saturday afternoon and evening upgrading the other three machines. None of them has as much stuff on as mine, so they averaged about 4 hours total for the upgrade – still a lot of time. As with mine, they are all performing better and they have also stopped some of the exceptions that were happening.

Things I like

All four machines are performing better and seem more stable. We're not seeing the exceptions we saw before.

Another thing I was worried about is that I was told that a lot of applications would not work with Windows 7. None of my existing applications are affected by that. Everything works fine.

I like the new task bar. It is more organized and it has some useful options.

Networking with the other notebooks on the network is much easier and I have had no problem doing all the Unix stuff I do from my PC.

Things I don't like

This upgrade took a long time. 19 hours of upgrade time across 4 machines is ridiculous.

I was very frustrated that the Quick Launch toolbar now no longer exists and although you can pin things to the taskbar, none of the Quick Launch stuff was pinned to the taskbar for me. That was a pain.

Summary

For the most part, this upgrade went smoothly even if it took an inordinate amount of time. The machines are more stable than they were before and they seem to be faster. Internet Explorer performs much better and even Firefox is behaving pretty decently.

So far so good. I'll follow this up in a week or two with more on how this goes.

It took me a while to get this done, not so much because of the code, but because the documentation that accompanies it is pretty extensive and I have been in the middle of some significant career changes.

This post is long primarily because I walk through the highlights of the what the code does and how this bolsters what I was saying in my earlier post.

Inside the zip file are 2 zip files and 3 PDF files:

• DynamicOpenClientJar.zip is the compiled version of the code. It contains a jar file, the input.xml, a batch file, and the Progress source code.
• DynamicOpenClientJar.pdf contains setup instructions to set it up and run it.
• DynamicOpenClientSrc.zip is the source code.
• DynamicOpenClientSrc.pdf contains the instructions that that tells you how to set the source code up to work with Eclipse.
• DynamicOpenClient.pdf is a detailed tour of the code and describes how it works.

This is Sample Code

Before you dig into the code and say "Wow!! This code sucks!!" it is important to understand that this is sample code. There are a lot of things about it that are ugly. Some of the object model needs serious refining. There are cleaner ways of doing the XML parsing and it is nowhere near as defensive as it should be. There are those who believe that bad code samples lead to bad code in production, but there is another line of thought that goes that if you don't recognize those bad examples, you should not be coding to start with. The point with this code is that it demonstrates concepts and that's what it was intended to do.

Code Limitations

For the sake of brevity, I have deliberately not covered stuff like supporting supporting ProDataSets and all of the different Progress data types. I have covered the most common ones and temp-tables. ProDataSets are really an extension of temp-tables and you can feel free to go and look at the code in a generated proxy to see how they work. I also stopped short of supporting the building of temp-tables from an input XML file. The extra code to do this did not seem like it would really add that much to the example. This code example also does not support persistent procedures because they are a lot more complicated than this code will allow.

Set it up and try it

Having said all of that, I wanted to spend some time in this post elaborating on the comments that I made in the earlier post about why Dynamic OpenClient is such a powerful technology, using the example code that I am presenting here. So I am going to assume for the rest of this article that you have at least set up and run the example and that you have the source code accessible to follow along.

How it Works

The Dynamic Open Client code takes an XML file and parses it for AppServer connection parameters, R-Code signatures and calls that need to be made to the Progress/OpenEdge R-Code files. The sequence diagram at right (click on it for a full-size image) shows the process.

Once the XML file has been parsed, the utility executes each of the calls and serializes the results of the call's execution to an internal XML document. Once all the calls have been executed and serialized, the results are written out to another XML file that is specified in the input.xml file. More information on the XML file's format is in the DynamicOpenClient.pdf file.

The Main Components

To understand how this utility works, you need to understand the core of the class model. So let me start by dividing the class model into its major areas.

You can pretty much ignore the com.tsg.common project. It contains an interface - INamedItem – used by a few classes that simply has a getName() method declaration. INamedItem is implemented by some of the classes in the com.tsg.dynamicopenclient project. This interface is specifically used for objects that may be stored in a com.tsg.common.collections.OrdinalList – a specialized list that is ordinal like an ArrayList, but expects uniquely named items in the list. OrdinalList is used for things like field lists and parameter lists where the fields need to be in a specific order, but the names have to be unique.

The com.tsg.dynamicopenclient project contains three packages:

• com.tsg.dynamicopenclient - This package contains the code that does most of the work;
• com.tsg.dynamicopenclient.data - This package contains the class hierarchy for parameter and other data element definitions;
• com.tsg.dynamicopenclient.valueholders - This package contains the class hierarchy for all the value holders that are used to contain the values of input and output parameters.

Data Types

One of the most important aspects of the communication between the OpenClient and the AppServer, is the mapping of data types from Java to Progress. To make sure that this is done consistently, there is a DataType enumeration in com.tsg.dynamicopenclient. If you have not worked with Java 5, enumerations may be a new concept to you and this one is particularly more so than others. An enumeration is a great way to deal with hard-coded constants and it is particularly useful where a map of constants is necessary. In this particular case we have to map an OpenClient numeric constant to a string representation of the data type, a Java class that can be used to map to that type and a valueholder class that can be used to contain the Java type. The following definition of the INTEGER data type demonstrates the mechanism:

INTEGER
  (Parameter.PRO_INTEGER, // Progress numeric constant
   Parameter.PRO_INTEGER_NAME, // Progress character constant
   "java.lang.Integer", // Java class to be used to map
   "com.tsg.dynamicopenclient.valueholders.IntegerValueHolder"), // Dynamic OpenClient valueholder

The DataType enumeration has several methods associated with it to retrieve a constant based on the string name of the data type or to obtain the Java class, value holder class or Progress data type constant. It also contains code that will instantiate an object of either the Java class to contain the data type or the value holder. This enumeration truly is at the core of the code.

Data Elements

The com.tsg.dynamicopenclient.data package contains a set of classes that define the behavior of data elements. A data element is any item that has a name and a datatype associated with it. Thus, fields and parameters are all data elements. Data elements only store the definition of the element. They do not store the value. The value is stored in a value holder. The abstract base DataElement class contains all the behavior for parsing parameter and field definition information from an XML node.

The Parameter class extends it by providing support for parameter modes (INPUT, INPUT-OUTPUT and OUTPUT) which are mapped in an enumeration called ParameterMode in com.tsg.dynamicopenclient.

The TempTableParameter class extends the Parameter class further by providing support for parsing temp-table definitions from the source code and supporting the construction of ProDataGraphMetaData objects that are used to build the ProDataGraph to transport temp-tables between AppServer and client.

Value Holders

The com.tsg.dynamicopenclient.valueholders package contains a set of classes and an interface that are used to standardize the way that data types are dealt with. Looking at the class model, the value holder hierarchy is to the right of the diagram. This hierarchy leverages the concept of generics that was introduced in Java 5.

The IValueHolder interface is the base of the hierarchy and the ValueHolder abstract class contains the generic behavior for value holders. These classes provide support for the Progress UNKNOWN value as well as reasonable default values that match the Progress defaults for its data types.

Value holders are used to set the value of input parameters and to contain the values of output parameters.

DynamicOpenClient Class

The DynamicOpenClient class in com.tsg.dynamicopenclient contains the main() method - the entry point to the utility. It starts out by parsing the parameters to determine where the XML file is that contains the signatures and input parameters for the calls. The input.xml file's structure is detailed in the DynamicOpenClient.pdf file that accompanies the source code. In essence, though, there are 4 types of nodes that are important:

• dynamicoc – This is the root node for the document and it contains an OutputFile attribute that has the name of the file that should be used for the results of the calls.
• appserver – This node contains the signature and call nodes and a set of attributes that define the connection parameters for the AppServer.
• signature – This node contains the signature of a call that will be executed against the AppServer. The signature node may contain a set of parameter nodes which will be all of the parameters for a procedure. These parameters must be specified in the order that they are specified in the ABL source code. If the parameter's DataType attribute is TABLE, the node will contain child nodes that are the field and indexes for the table.
• call – This node contains a list of calls that need to be executed against the AppServer. Each of them should refer (by means of the Procedure attribute) to a previously specified signature. call Nodes may contain subordinate parametervalue nodes that reference a parameter in the signature by name and specify the value to be used as the input value for that parameter.

The following code extract comes from the main() method.

//Extracted from main() method.
//

//Instantiate the CallManager
CallManager manager = CallManager.getInstance();

//Parse the XML file.
try {
	parse(fileName);
}
catch (Exception e) {
	System.out.println(e.getMessage());
	return;
}
.
.
.
Iterator<Call> iter = manager.iterator();
while (iter.hasNext()) {
	Call call = iter.next();  //Get the call
	call.executeCall();   //Execute the call
	outRoot.appendChild(call.serializeResults(outputDocument));
	iter.remove();
}
.
.
.
try {
	writeResults();  // Write the XML results file out to disk.
}
catch (Exception e) {
	System.out.println(e.getMessage());
	return;
}

Before doing anything else, the code instantiates the Singleton CallManager to hold onto all the data that will be parsed from the XML file.

The main() method calls the static parse() method with the name of the XML file to be parsed. This method parses the XML document and iterates through the four element nodes mentioned above. It also sets up a DOM document that will be used as the output document for the results of the calls.

For each element, it instantiates an object of the appropriate class and passes it the XML node that needs to be instantiated. This object is then added to the CallManager where it will be retrieved later.

//Extracted from parse() method.
//
Node elementNode = null;
while((elementNode = iterator.nextNode()) != null) { // Loop through elements

	// Handle root node.
	if (elementNode.getNodeName().equalsIgnoreCase(XMLStrings.INPUT_ROOT_NODE.toString())) { 	

		// Setup the output file.
		String attrValue = XMLStrings.getAttribute(elementNode, XMLStrings.OUTPUT_FILE_ATTR.toString());
		if (attrValue != null) {
			outputFileName = attrValue;
		}
	}

	// Handle appserver node
	if (elementNode.getNodeName().equalsIgnoreCase(XMLStrings.APPSERVER_NODE.toString()) ) {
		manager.setAppServerConnection(new AppServerConnection(elementNode));
	}

	// Handle signature node
	if (elementNode.getNodeName().equalsIgnoreCase(XMLStrings.SIGNATURE_NODE.toString()) ) {
		manager.setSignature(new Signature(elementNode));
	}

 	// Handle call node
	if (elementNode.getNodeName().equalsIgnoreCase(XMLStrings.CALL_NODE.toString()) ) {
		manager.addCall(new Call(elementNode)); 
 	}
}

The CallManager implements the Iterable interface for the Call class. Back in the main() method, the next thing we do is iterate through all of the Call objects in the CallManager and we execute the call. This is where the real work happens and a description of it is below. When execution is complete, the parameter values will have been stored in the Call object and a call to serializeResults() will return an XML node that can be appended to the output document. The Call object is then deleted from the list of calls to free up the memory that any temp-tables will occupy.

Once all the calls have been executed, a call is made to writeResults() which writes the output XML document to disk.

Executing the Call

A call is actually executed by a call to executeCall() on the Call object. The executeCall() method simply builds a parameter array, calls the runProcedure() method on the AppServerConnection object, builds the output parameter value set and handles any exceptions. The thing that makes this client dynamic is the code in buildParamArray() and buildOutputValues().

buildParamArray()

In order to make a call to the AppServer, the OpenClient needs a procedure name to call and a parameter array (com.progress.openABL.javaproxy.ParamArray) for the call. The parameter array needs to contain a full description of each parameter as well as the value to be set for the parameter. The Call object has a procedure name and it has the values of the input parameters. The name of the procedure maps to a Signature object which can be obtained from the CallManager and it contains the definitions of all of the parameters that are needed for the call. Thus, buildParamArray() obtains the Signature object and builds a ParamArray object with each of the parameter definitions in the Signature object. As it attempts to add each parameter to the ParamArray, it obtains a IValueHolder object to contain the parameter's input or output parameter value. It then checks for a corresponding input value in the Call object. If it finds a corresponding value it sets the input value in the ParamArray from this value. This is how the Call information in the XML file can specify the parameter values by name in any order and only specify the ones that have values associated with them.

//Extracted from buildParamArray() method.
//

CallManager manager = CallManager.getInstance();
Signature sig = manager.getSignature(getProcedureName()); //Get the signature for this call
if (sig == null) {
	throw new DynamicOpenClientException(...);
}
ParamArray params = new ParamArray(sig.getParameterCount()); //Instantiate a ParamArray object

int idx = 0;

// Iterate through all the parameters in the signature.
for (Parameter param : sig) { 

	// Instantiate an IValueHolder for this data type.
	IValueHolder<?> valueHolder = DataType.getValueHolder(param.getDataType());
	paramValues.add(valueHolder); // Put the value holder into the paramValues list.

	// If we can find a parameter value that was set for this call,
	// set the value of the IValueHolder to the input value.
	if (inputValues.containsKey(param.getName())) { 
		valueHolder.setObject(inputValues.get(param.getName()));
	}

Now that the data we need is available (ie, the parameter type information and input values have been set), we can go about setting the values, but we need to treat the TABLE and TABLE-HANDLE types differently from the the other data types. The reason is that they need a ProDataGraph and its metadata. The code for setting the values is therefore as follows:

Object value = null;
switch(param.getDataType()) {
	case TABLE:
	case TABLE_HANDLE:
		TempTableParameter ttParam = (TempTableParameter) param;
		ProDataGraphValueHolder graphHolder = (ProDataGraphValueHolder) valueHolder;
		ProDataGraphMetaData metaData = null;
		switch(param.getMode()) {
			case OUTPUT:
				// For a table we need the table structure. TABLE_HANDLE needs null.
				if (param.getDataType() == DataType.TABLE) {
					metaData = ttParam.getProDataGraphMetaData();
				}
				break;
			default:
				value = graphHolder.getProDataGraph();
				metaData = graphHolder.getProDataGraph().getMetaData();
				break;
		}

		// Add a parameter to the ParamArray with the appropriate value.
		params.addParameter(idx, value, ttParam.getMode().getModeCode(),
			ttParam.getDataType().getTypeCode(),
			ttParam.getExtent(),
			metaData);
		break;
	default:
		// Now get the object from the IValueHolder that has the value in it.
		value = valueHolder.get(); 

		// Add a parameter to the ParamArray with the appropriate value.
		params.addParameter(idx, value, param.getMode().getModeCode(),
			param.getDataType().getTypeCode(),
			param.getExtent(),
			(ProDataGraphMetaData) null);
		break;
}

The outer switch in this code handles the difference between TABLE, TABLE-HANDLE and other parameters. So skip the first cases and look at the default case (the last 11 lines of this code block from the word "default:" on. All this code does is grab the object that is in ValueHolder and assign it to the value variable. It then adds a parameter specifying the ordinal position (idx), the value, the parameter mode (INPUT, OUTPUT or INPUT-OUTPUT), the Progress DataType Code from the DataType, the extent and a null for the ProDataGraphMetaData.

The TABLE and TABLE-HANDLE cases are slightly more complicated. For a TABLE or TABLE-HANDLE if the parameter is either an INPUT or INPUT-OUTPUT parameter, the value has to be set to the ProDataGraph that will be used to contain the return value. The ProDataGraphMetaData needs to be specified to supply the table structure. In the case of an OUTPUT parameter, a TABLE parameter requires ProDataGraphMetaData but null in the value parameter and in the case of a TABLE-HANDLE, both the metadata and the value need to be null. In both cases, the Parameter object will have been specialized as a TempTableParameter object so that it could build the temp-table structure.

Once the parameters have all been added to the ParamArray, it is returned to the caller (executeCall) and is now ready to invoke the call.

runProcedure()

The runProcedure() method call is run on the AppServerConnection object that is contained in the CallManager. The AppServerConnection class performs 2 functions:

1. It stores the AppServer connection parameter values; and
2. It executes calls against the AppServer.

The first thing runProcedure() does is call obtainAppObject(). The OpenAppObject class provides access to AppServer connections from the connection pool and supports all communication with the AppServer. The obtainAppObject() call instantiates a Connection object and then an OpenAppObject if they have not already been instantiated. This establishes the connection to the AppServer.

Once the connection is established, the runProc() method on the OpenAppObject is run with the ParamArray that was passed in and any exceptions are thrown back to the caller. If this code completes successfully, the AppServer call has succeeded.

buildOutputValues()

After the call has completed, executeCall() calls buildOutputValues() with the ParamArray that was used in runProcedure(). 

//Extracted from buildOutputValues()
//
returnValue = params.getProcReturnString();
if (returnValue == null) {
	returnValue = "null/Unknown (?)";
}
int idx = 0;
for (Parameter param : sig) { // Loop through each parameter in the signature.
	switch (param.getMode()) { // Check the parameter mode.
		case INPUT_OUTPUT:
		case OUTPUT:

			// Get the value of the parameter from the paramArray.
			Object outputValue = params.getOutputParameter(idx); 

			// Set the value of the parameter in our internal array to be the result
			paramValues.get(idx).setObject(outputValue);
	}
	idx++;
}

The buildOutputValues() method does 2 things:

1. It obtains the value of the RETURN-VALUE string from Progress; and
2. It loops through all OUTPUT or INPUT-OUTPUT parameters and sets the value in the IValueHolder from the value in the ParamArray.

The output parameter values are thus available to the Call object for serialization. 

Why this is so powerful 

That is the crux of the code in the Dynamic OpenClient Sample Utility. It's not really that complicated and although this is a crude example, it does show the relative ease with which one can build a client that invokes calls for which all signature information is obtained at runtime.

If you work through the associated document that contains a description of running the utility, you will notice how easy it is to edit the ABL code and change temp-table structures or any other signature related information, modify the corresponding signature in the XML file and re-run the utility without changing the Java code.

If you go ahead and automate the generation of the XML signatures into a post-compile operation and post it on a web-server or some other centralized resource, there is never a need to change the Java code unless you discover a bug in it or Progress adds a data type.

There's another interesting side effect to this. It would not take much effort beyond this to build an automated mechanism for dynamic WSDL generation so that you dynamically expose any ABL procedure as a WebService. Taking it further, exposing it as an EJB or J2EE container or a JMS endpoint would be fairly simple too and would mean very little would ever need to be changed in the plumbing between the client and the server. You see, as far as I am concerned, everything related to ProxyGen is plumbing that should never require a recompile unless the underpinnings change. ProxyGen forces that each time a temp-table definition is changed.

Hopefully this example is useful. I am planning a .NET equivalent later on.