CODEWITHSUNDEEP
wso2esbwso2-esb
Plain Ol' Human
Plain Ol' Human

Reputation: 45

WS2ESB: Store state between sequence invocations

I was wondering about the proper way to store state between sequence invocations in WSO2ESB. In other words, if I have a scheduled task that invokes sequence S, at the end of iteration 0 I want to store some String variable (lets' call it ID), and then I want to read this ID at the start (or in the middle) of iteration 1, and so on.

To be more precise, I want to get a list of new SMS messages from an existing service, Twilio to be exact. However, Twilio only lets me get messages for selected days, i.e. there's no way for me to say give me only new messages (since I last checked / newer than certain message ID). Therefore, I'd like to create a scheduled task that will query Twilio and pass only new messages via REST call to my service. In order to do this, my sequence needs to query Twilio and then go through the returned list of messages, and discard messages that were already reported in the previous invocation. Now, to do this I need to store some state between different task/sequence invocations, i.e. at the end of the sequence I need to store the ID of the newest message in the current batch. This ID can then be used in subsequent invocation to determine which messages were already reported in the previous invocation.

I could use DBLookup and DB Report mediators, but it seems like an overkill (using a database to store a single string) and not very performance friendly. On the other hand, as far as I can see Class mediators are instantiated as singletons, therefore I could create a custom Class mediator that would manage this state and filter the list of messages to be sent to my service. I am quite sure that this will work, but I was wondering if this is the way to go, or there might be a more elegant solution that I missed.

Upvotes: 1

Views: 85

Answers (2)

Malaka Silva
Malaka Silva

Reputation: 142

Since esb 490 you can persist and read properties from registry using property mediator.

https://docs.wso2.com/display/ESB490/Property+Mediator

Upvotes: 0

Rajeev Sampath
Rajeev Sampath

Reputation: 2757

We can think of 3 options here.

  1. Using DBLookup/Report as you've suggested
  2. Using the Carbon registry to store the values (this again uses DBs in the back end)
  3. Using a Custom mediator to hold the state and read/write it from/to properties

Out of these three, obviously the third one will deliver the best performance since everything will be in-memory. It's also quite simple to implement and sometime back I did something similar and wrote a blog post here.

But on the other hand, the first two options can keep the state even when the server crashes, if it's a concern for your use case.

Upvotes: 1

Related Questions