common problem : FIFO and resiliant messages between 2 applications

, ,
#1

Hello, I want help for this very common problem :
my Application1 sends messages (msg1, msg2, msg3) to my Application2.
This messaging system must be fifo : Application2 must receive first msg1 then msg2 … and no message can be lost
Application2 may be down sometimes (for adminstration tasks : upgrade, backup, …) so this messaging system must be asynchronous

I began to create a system :

  • Application1 sends messages by calling a IS service1.
  • IS service1 sends a message to the IS brocker so it can givesynchronously a return to Application1.
  • Than an IS service2 triggered to the message forwards it to Application2. But how this service2 can manage if Application2 is down and to respect fifo ?
    Is there an code exemple in SAG website ?
    Can you give me the good way to create my IS service2 ?

thanks a lot

I use Webmethods v9.8

#2

Hi Bruno,

define the trigger as concurrent with one processing thread (or serial if app2 is clustered).
These settings will guarantee the fifo approach.

When app2 is going down for maintenance suspend the trigger under "Settings → Messaging" and activate afterwards.

Regards,
Holger

#3

I set the 2 trigger properties that you’ve said.
but I don’t know when app2 is going down so I can’t suspend manually the trigger. I think I’ve found the good way :

  • I set the trigger property "Resource monitoring service / Resource monitoring service " with a new service that verify if App2 is up. You confirm this way ?

thank you

#4

Hi Bruno,

the Resource Monitoring Service is a handler service for checking the status of the trigger.

More likely you will have to implement two services for enabling and disabling the trigger when app2 goes up or down.
These services should be called by app2 according to status change.
This can also be done by assigning these services as Startup-/Shutdown-services to the package.

See IS Built-In-Services Guide for pub.trigger-Services.

Regards,
Holger

#5

If I don’t disable the trigger when app2 down, what will it happen ?

  • the trigger launch the service1
  • the service1 contains a repeat on an other/final service. The repeat is on failure/timeout. So the service1 don’t return until the app2 is up
  • the queue of the trigger will increase until the max (max is defined in property : Trigger queue / Capacity)

what else :slight_smile: ?

#6

Hi Bruno,

can you explain how you do publishing?

When it is just pub.publish:publish, your service is not waiting for app2 to respond.
When it is pub.publish:publishAndWait, then app1 will block until app2 is functional again.

There is no maximun on the queue, it is just limited by the file size of the broker storage.
The Capaciity only describes how many documents the IS (where app2 resides) will prefetch from the Broker locally before processing them.

Regards,
Holger

#7

the other/final service doesn’t use a message published but an adapter service for app2 (jdbc or other) that return exception or error timeout

in introduction I don’t explain my system :

  • app1 and app2 are connected with an IS through Adapters (jdbc or other)
#8

Hi Bruno,

how does app2 detect that there are new messages to be processed?
Listeners/ListenerNotifications?
These are usually publishing their documents to messaging from which they are retrieved by triggers.

Regards,
Holger

#9

it’s adapter service that call a remote function with the data of msgs

#10

Hi Bruno,

can you provide an overwiew picture of your environment which shows how everything is connected to each other?

Regards,
Holger

#11

Hello @Holger_von_Thomsen,
I am looking for a way in which a ‘bad document’ can be moved to a RETRY.Q.
Subsequently, the document is retried after n-hours for m-attempts.

Eventually the ‘bad document’ is moved to a DEAD.LETTER.Q.

Is there a way this can be done?

Best Regards,
Franklin

#12