Talking to a Java application?

[Elod]

Hi all,

Do you have any suggestion on how one should talk (both-ways) to a Java server based application from Progress? The Java back-end communicates with the user interface through web services. This application needs to be integrated with the Legacy Progress application.
Yet there is no message bus in use, but there will be on in the future (it hasn't been chosen yet).
Any suggestion, or did anyone worked this way, has some documentation?

Kind regards,
Elod.

 

[RealHeavyDude]

You don't mention your Progress/OpenEdge version ...

Your best option is the Java Open Client technology that was introduced with OpenEdge 10. This technology allows you to build java proxies which are essentially remote procedure calls on the OpenEdge AppServer. With a reasonably recent version (OpenEdge 10.1+) you can exchange ProDataSets which map to Java SDO pretty well.

Actually right now I am leading a project utilizing the Google Web Toolkit talking to Java servlets deployed on TomCat which talk to the OpenEdge AppServer utilizing the Java Open Client technology. Until now everything works without a fuzz ...

If your database is sitting on Progress V9 you could make use just of the OpenEdge 10 AppServer connecting to the Progress V9 database.

BTW, forgot to mention that I would not recommend use of JDBC to talk with the Progress/OpenEdge database as it is not an SQL database in the first place ...

Heavy Regards, RealHeavyDude.

 

[Elod]

Hi, first of all thanks for the quick reply.
We are talking about OE 10.1C.
Java Open Client can be used both ways, not just sending data from java application to Progress 4GL?

 

[RealHeavyDude]

Yes you can!

As far as I have seen the Java Open Client technology provided a Java object for each INPUT, OUTPUT or INPUT-OUTPUT parameter we've used in our 4GL procedures running on the AppServer.

In a nutshell ( what we do ):

• We retrieve ProDataSets from the OpenEdge AppServer. In the Java servlet they are mapped to a data graph object ( which is part of the Java SDO implementation that is shipped with the OpenEdge product's Java Open Client technology ).
• We then switch the logging on on the data graph object and change its contents from the changes we were provided with from the client UI ( GWT in our case ).
• When we're done changing the data graph object we take the change summary object populated during logging was on and extract the data graph from it that contains only the changes.
• Next we send the changes back to the AppServer. In the 4GL we will have a ProDataSet containing only the changes which we then save to the database using the ProDataSet's standard methodology.
• Last, but not least, we need to reconcile the changes that where applied on the AppServer ( the business logic might have applied additional changes ) into our original data graph object
• Send the result back to the client and we're done.

You might want to have a look into the PDF documentation which contains a book "Java Open Clients" in the Open Client section. I found it very helpful as it explains everything you need in detail.


Heavy Regards, RealHeavyDude.

 

[Elod]

Well it's a bit of a confusion here, yes that is correct, Java Open Client is a good solution if you try to access progress code from outside.

What about a situation when you want to access Java code triggered by a db update in Progress?
Let's say a record has been saved in the db and we want to replicate that in a Java based application, how can something be triggered in the Java code (or anything else)?

 

[RealHeavyDude]

That sounds like a different story.

In which case there are many ways depending on your point of view. Is the point of view a set of specific business transactions or is the point of view generic replication on the database level with no dependency on specific business transactions?

Heavy Regards, RealHeavyDude.

 

[Elod]

It's a case of specific business transaction that can be scaled in the future.

 

[RealHeavyDude]

The bad news is that there is no solution available that you can just use because there are so many ways to implement something like this.

Generally I would not try do to anything on the database level, instead I would trigger the "replication" from within the business logic on either side. Regardless on which side you are, I would call a service from the other side. From Java you are able to directly access the OpenEdge AppServer and let it save the "data to replicate". But you could also have the OpenEdge AppServer sit behind a WebService. For the other direction I would provide the Progress side with a WebService. With the introduction of OpenEdge the 4GL contains the ability to invoke WebServices ...

Still there are some issues that need attention:

• How loosely should this be coupled - does the replication need to be online?
• How fault tolerant should it be?
  • What should happen to a business transaction on one side when the service from the other side is not available or does not respond as expected - should the transaction go through and be replicated at a later point in time?
  • How would you cache "replications" that did not go through so that they can be replicated at a later time?
• How would you handle conflicts, when the same set of data is changed by business transactions on both sides at almost the same time?

In the end you need to design you own solution. I would say that all the bits and pieces needed are there and it's a matter of your design how you "glue" them together.


Heavy Regards, RealHeavyDude.