I need to come up with a design for real-time data update from a COTS product (a Point of Sales system) to a custom-built .NET application (an Inventory Management system).

Particularly, any sales transaction happening in POS system needs to update the inventory database (present in Inventory Management system) immediately (in real time). The only way any other system can communicate to the POS system is via its API exposed as web services.

I have thought about introducing a Service Bus (or any such EAI tool) in between the two systems and taking advantage of the publish-subscribe model so that any sales depletion happening in POS system will trigger data update to the IM system via the service bus. My questions are:

  1. Is it a good/feasible solution?
  2. Do you have any other suggestions for such real-time data synchronization between different systems?
  • 1
    Would you clarify a few things? I read this as saying: their is a single instance of a PoS system and a single instance of a Inventory Management (IM) system running. No other systems need to be integrated. The only transactions you are interested in need to come from the PoS system to the IM system. Is that accurate? You say "The only way any other system can communicate to the POS system is via its API exposed as web services". Has the IM system access to the PoS system via a different API? What does "immediately (in real time)" mean, µs? Aprox. what is the throughput, i.e. Txns/second?
    – gbulmer
    Aug 12 '14 at 22:13
  • The core POS system is hosted in a server and has many thin clients (say, about 4-5) accessing it from POS terminals. As of now, I am only interested in data coming from POS system to the IM system - no other systems integration is in scope. The POS system being a commercial 3rd party software, the IM system has to access it via the POS API (web services).<br/> Aug 13 '14 at 5:39
  • Immediately (in real time) means the sales transaction would update the IM database as soon as possible (throughput can be 5-25 txns/min). The reason I mentioned real time is I am not inclined towards batch updates via scheduled jobs (though that can be one near real-time solution if run very frequently) but it would also need some kind message queuing I believe. Aug 13 '14 at 5:48
  • In computing 'Real-Time' means programs must guarantee response within strict time deadlines. If you can't define the absolute maximum time allowed, then there isn't a Real-Time requirement. Real-time is typically within a few ms, or less. "as soon as possible" is not an engineering definition. 25txns/min is valuable to know. Are you familiar with the term ACID transaction?
    – gbulmer
    Aug 13 '14 at 15:35
  • It appears that you are asking for is consultancy that would typically cost ~$1000/day of a system integrator. It would take a few days to a few weeks to do the research and analysis necessary to get an adequate answer. I'll try to find time to write an outline answer, but I am a bit too busy and hungry right now. I would strongly advise you to not add more pieces of technology. Do not use a message queue. Ask yourself this, "how will the software know that the PoS transaction is properly in the queue?" Then, "how will the PoS transactions recorded in the queue update IM?". See?
    – gbulmer
    Aug 13 '14 at 16:47

First, as the comments point out, you aren't really talking about realtime here -- that has a pretty strict definition and implies lots of stuff that isn't really on the table. You are talking about connecting two systems in a near realtime sort of manner.

Anyhow, yes, the best bet would be some sort of message queueing solution here. The POS system would push updates into the queue and the inventory system would read the queue. Pub/sub could come into play here as well depending on how you want to do things on the back-side.

The reason you want message queuing and not some really hard, realtime sort of dependency is because you probably don't want to stop taking transactions if/when the inventory management goes down for whatever reason. Rather you can record things (message queue) and then replay them when it comes back up.

The real question is does that POS system have the ability to push data out somehow or are you reduced to some sort of middleware polling solution grabbing transactions and stuffing them into the message queue.

  • Excellent post! Could not vote you up, as I am new here. Even though I was thinking of introducing a service bus/message queue, I am daunted by the POS system's limitation to push data to the message queue. Modifying the COTS product for this purpose is the last option in my mind. Can you please suggest some middleware polling solution which can do this job? Also, if the POS system does not expose any event API for transaction, will such solution work? For example, for the pub-sub model of ESB to work, my POS system needs to publish its "transaction occuured" event to the service bus, right? Aug 14 '14 at 7:37
  • By middleware I really meant "your messaging code built on solid infrastructure components." A good default choice for message queues would be rabbitmq these days but beyond that it is hard to get into specific recommendations without more details on what the stack is. You might well need to write some scriptable program to poll the POS server and push things into the queue for instance if it can't publish the event but it is hard to say for sure. Aug 14 '14 at 13:03

I think there are several ways to make synchronization between two system and I guess it is similar with that how to share memory in clustering.

You may sync data in system as below ways

  1. share memory using memcached
  2. share memory using DB
  3. update data to the IM right away.
  4. Save data only in one system and either system use the data just by calling API you may be getting timing issue if you use 3 or 4

If you want to reduce timing issue, I recommend you'd better use way 1 or 2

  • 1
    Unfortunately, none of these options will help in achieving real-time data synchronization for my scenario. The POS system being a COTS product, modifying it or accessing its database or sharing its database is not an option. As I mentioned, only way to access its data is via the web services exposed by it. Aug 13 '14 at 15:05

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.