Mostrar / Ocultar Avisos

How to Return a Generic .Net DataSet from the OpenEdge AppServer

Recently at work we needed a good, and easy, way to get data stored in our massive ERP system running an OpenEdge database to some of our .Net apps. At first, we just had ASP.Net connect directly to the database through ODBC which was good enough for our prototype. However, if we were to continue using this method it would require our Microsoft developers to learn a totally new and convoluted schema. Plus, they would have to use embedded SQL statements like…

** dbBroker and GetDataTableBySQL are part of our in-house framework but you can get the idea.

Embedded SQL is a code maintenance nightmare in my opinion. I’ve never liked mixing languages like this. Fortunately, OpenEdge comes with a better way call the Open Client Toolkit (sorry, no link). To quote the product literature the Open Client Toolkit is used “to generate .NET, Java, and Web services proxies for accessing business logic.” In our case we used it to create DLLs which we can reference in our Visual Studio projects.

[I will post another article on the specifics of using ProxyGen from the Open Client Toolkit to create .Net DLLs]

This process works much better as our MS developers can just make a call to the methods in the DLLs (I’ll write about this is another article) and not have to worry about the ERP’s crazy schema while our Progress developers can actually create real business logic procedures to aggregate data. The only problem with this scenario is that every time we want to add to the AppServer code we must regenerate the DLLs and make the .Net apps reference them properly. Talk about a pain in the ass.

Here is how we I solved this problem.

The first issue was to find a way to relieve the pain of regenerating and referencing the DLLs. After some experimentation I found that only the procedures called directly from C# needed to be built into the DLL. So we came up with the follow program to act as a broker to all of the other code on the AppServer. Now the proxy DLLs only need to be recreated if this one file is modified. And all the .Net team needs to know is the name of the process they wish to call and the input parameter. What they get back is a DataSet containing one or many tables and their corresponding relationships.

Pretty simple. I kept it that way to make sure we never have to change it again. (Which we will since the current process only extracts data. Soon we will need a was to insert and update data.)

The following procedure is the guts of our little AppServer broker. It attempts to find the called process and run it. If there is any kind of failure it will return a DataSet willed with information about the error.

This is the code for creating the Error DataSet.

Here is an example of a method to return a specific customer. For you Progress people out there it is using the Sports200 database.

**I did not include the source for the helper.i file as the other function used is validParams() which just checks to make sure the comma delimited list of parameters contains the expected number of parameters.

2 Responses

  1. Phillip Molly Malone Says:

    Hey,
    Love the article, its always great to hear how people are using OpenEdge. Not sure if this helps at all or if you were aware of it, but in the 10.1A release an OpenAPI was introduced and this allows you to call Procedures on your OpenEdge AppServer without creating any proxy. I am not sure if this works better for you, but if you are interested, it is discussed in Chapter 8 of the “OpenEdge Development: .Net Open Client” manual“.

    HTH, and can’t wait for the next post
    Molly
    PS. Like the handling of Errors, very smart.

  2. Sam Says:

    Thanks for the link Molly!

    I was not aware of that, but will look into it. I think we started this with 10.0B. I’m going todo two more posts; one for the proxygen and one with the C# code just to round out this article series.

Leave a Reply