4GL Triggers

[agarwalk]

Hello,

I am new to Progress world and trying to implement the below:

Whenever any update / delete / insert is happening on OpenEdge database, send a message to messageQueue.

I am using Stomp adapter to connect to Message Queue. I am able to send basic messages using triggers.

Now what I want is to put the new and old data (in case of update) in a string format and then send to MessageQueue.

Am facing the below challenges:

1. Getting the Old / New objects properly (It comes null I dont know why)
2. Convert them to a string or a JSON Object.

Can some one please help me in getting this done.



Basically what I need is a trigger example for create & write and a method to convert them to String or JSON string.


--------------------------------------------------------------------
Below is a initial set what I am doing --

My trigger calls the below code passing {2} as CREATE/WRITE and {1} as table name MORTGAGE
------------------------------------------------------------------------------------------------
{javax/jms/MessageSender.i}


TRIGGER PROCEDURE FOR {2} OF {1}
&IF "{2}" = "WRITE"
&THEN
NEW BUFFER {1}
OLD BUFFER OLD{1}
&ENDIF .


&IF "{2}" = "WRITE"
&THEN
RUN QueueSender ("{1}","{2}",NEWDATASTRING.OLDDATASTRING).
&ENDIF .

&IF "{2}" = "CREATE" OR "{2}" = "DELETE"
&THEN
RUN QueueSender ("{1}","{2}",NEWDATASTRING."").
&ENDIF .
-------------------------------------------------------------------------------------------

Here I don't want to hardcode the column names and need to build a generic way to read the bufferand put that in a string or JSON.

Any help is deeply appreciated.

Thanks

 

[tamhas]

I would step back and think about what you are trying to do. There are some of us who think that triggers for anything is a bad idea. They were created back before we had any kind of N-tier architecture to move some processing to the server, but we have had good N-tier architectures for some time now. If they have a role at all, it is for some kind of very lightweight auditing or relational integrity check. The idea of including a call to stomp in one is just way over the top.

 

[agarwalk]

Thanks for the reply.

Basically this is a startup for us to move out of Progress. I want to communicate changes to a Message Queue where I will build a Java consumer and will put data in some other database. May be MySql or Oracle. Applications which are connecting to Progress can be slowly migrated to this new database.

Since the main application is very big we cant migrate it quickly so for based on some decisions we want to take this route. You can suggest me if any other way of transferring data in REALTime is there. I dont want to put much load on existing Progress database but wilth little compromise i want to make a parallel copy of DB (with hetrogeneous table structure).

Thanks for your valuable time & expert opinions

 

[tamhas]

One would have to know a lot more about your current architecture.

Of course, the first wrong decision is moving away from Progress ...
Is there any good reason for doing so?
Is it a home-grown or purchased app?

 

[agarwalk]

Its homegrown but there are some decisions on top level which is forcing.

I am at a very junior level and trying to build out a POC proving out the above mentioned things.

May be if you can help me out in doing so and also listing down if any other alternatives are there.

 

[tamhas]

I think a connection to a messaging service in a database trigger is just flat out a wrong design for anything. What happens when the messaging service is down, for example? The whole application comes to a halt?

There are lots of ways to replicate across technologies. The best solution depends a lot on your architecture, about which I know nothing so I can't make recommendations.

There are also lots of ways ... some good, some bad ... for doing a progressive migration from one technology to another.

There are also a lot of bad reasons for people to decide to migrate off of Progress and few arguably good ones. So, one has to feel that the whole premise is flawed.

I would take a step back, bring in a consultant to assess the situation, evaluate your reasons for moving, judge how well founded those reasons are, consider whether there are alternatives you haven't considered, and come up with a plan for how to get from where you are to where you want to be. Once you have the overall plan, then come back to the details of how to implement it.

The operative phrase for this Proof of Concept is "Don't Do That"™