Broadcast Pattern

Broadcast pattern is moving data from one source system to many target systems. Data flow is usually one way sync in nature where target system will only receive the data and don’t provide response to the source system. This pattern is used in near real time sync approach where we want to send data from source system as and when it change to destination system with minimum delay.

Below example shows the broadcast pattern where if any sales happen in Customer portal then CRM, Inventory and Analytics applications should be updated in real time. Target systems don’t have to send any response back to the Source system.

We can define Broadcast pattern in following steps

• Source system/application where data change result into a notification/event – Case 1 and 2 and Case 3 when integration go and check the Source system for change data.
  • Source system can send the notification including actual data – Case 1
  • Source system can send only the notification without actual data – Case 2
  • Integration layer will check the Source system for any change data – Case 3
• Integration layer
  • Case 1 – Integration will receive the notification along with actual data
  • Case 2 – Integration will receive the notification and pull the actual data from the Source system
  • Case 3 – After certain scheduled interval Integration will check the source system for change data
• Target systems will receive the source system data in their desired format

Case 1 – Source system send notification along with data

Case 2 – Source system send only notification and MuleSoft will pull the actual data from the source system

Case 3 – Scheduler will invoke the MuleSoft integration after certain time interval and MuleSoft will pull the actual change data from source system

Every case has his pros and cons, let’s see

Case 1 – Source system send notification along with data

• Pros
  • Reduce API call between MuleSoft and Source system
  • MuleSoft don’t have to check for the change data
  • If MuleSoft is down then data can be lost
    • To overcome this problem Async approach is taken like introducing JMS queue between MuleSoft and Source system
• Cons
  • Notification and data creation logic lies in Source system
  • MuleSoft will not know in case Source system is down or any issue in Source system

Case 2 – Source system send only notification and MuleSoft will pull the actual data from the source system

• Pros
  • Light weight notification
  • Segregation of logic for pulling data from source system
• Cons
  • Notification creation logic lies in Source system
  • MuleSoft will not know in case Source system is down or any issue in Source system

Case 3 – Scheduler will invoke the MuleSoft integration after certain time interval and MuleSoft will pull the actual change data from source system

• Pros
  • Reliable approach as MuleSoft will know if Source system is down
  • Pull logic is within MuleSoft
  • Better approach in case changes are high as in one go it will pull all the change data
• Cons
  • More calls even in case there is no change of data in Source system

MuleSoft API led approach in Broadcast

As the Broadcast is between system and there is not point of exposing any interface to outer world. We can have below API Led approach for Broadcast

Case 1:

One Process Layer application which will hold following

• Interface to receive change data from source system
• Sync call – Source system can call the REST APIs exposed by the process application
• Async call – Source system can send message on JMS queue which can be listen by the process layer

Three System Layer applications

• Target System API – call the target system to insert/update the data

Case 2:

One Process Layer application which will hold following

• Interface to receive notification from source system
  • Sync call – Source system can call the REST APIs exposed by the process application
  • Async call – Source system can send message on JMS queue which can be listen by the process layer
• Call the System API to get the change data

Four System Layer applications

• One Source System API – to provide the change data
• Three Target System API – call the target system to insert/update the data

Case 3:

One Process Layer application which will hold following

• Scheduler to trigger the MuleSoft integration or process application in regular interval of time
• Call the System API to get the change data

Four System Layer applications

• One Source System API – to provide the change data
• Three Target System API – call the target system to insert/update the data

Reference blog – data-integration-patterns-broadcast