Section 8 of the manual – “Using the Open Client .NET OpenAPI to Directly Access the AppServer” – is all about dynamic OpenClient.

I have an example written in Java that I am almost ready to release. I am just finishing off some of the documentation on the sample.

I plan to make the same sample available in .NET within the next month or so.

As far as getting the signature from the rcode file is concerned, there is no way to do it without parsing the rcode file manually. The PGRCodeParser class does not work for any purpose other than generating the proxies. Don’t waste your time chasing that down.

The RCode file structure is actually not that complicated to parse. I have a parser that I wrote myself that I am working to finalize that I plan to make commercially available through my company, Intangere, LLC, in the near future.

The only documentation I can recall seeing is on the use of the proxy generator. I can and have opened up the generated .dll (.NET proxy) in reflector and looked at the calling code and have on occasion wrote my own as a stop-gap measure, but I don’t remember seeing anything from Progress guaranteeing that this will be supported in the future; nothing to stop them from completely changing the internals in a future release and leaving your code out in the cold. I’d be delighted if you can show me I’m wrong?

Also how can I dynamically discover the parameters, their types, and their i/o mode of a procedure? If I have a persistent procedure I can call the GET-SIGNATURE method on it, but obviously it needs to be running first and that doesn’t help you with its main parameters. Again I can fire up reflector and look in proxygen.exe and notice that there’s a class “PGRCodeParser” which with casual inspection would seem to do what I need, but again, what’s to stop Progress from completely changing it in the future (especially since this is presumably a closed, internal tool)?

First off, the proxies are Java or .NET proxies so there is no testing done until runtime.

Second, in my experience, the generated proxies are normally just given to the Java/.NET developers to include in their code. There is no real testing of the proxies themselves as the Progress engineers don’t know how to write Java/.NET code and the Java/.NET engineers don’t care much about the Progress back-end code.

So really, I would venture a guess that in most cases, the problems associated with changes to the back-end procedures will only show up at run-time anyway.

You are right about the heavy lifting in the code, but I would contend that that is code that is written once and built with a strong suite of unit tests. Once it works properly, it is reliably re-usable.

Using the dynamic interface is a good option if your worried about lots of changes to the data structure or the parameters to pass in and out, but there is a lot more heavy lifting in the coding and (from memory) any coding issues will be seen at run time. The advantage of dynamic calling is of course that you can call any procedure not just the ones that proxies have been generated for.

Good article, look forward to reading more!