Order search service – Change data capture vs. events
Explore pros and cons of using events vs. change data capture in IBM Sterling Order Management.
Note: Growing order data – Is it really an issue? This blog is Part 5 in a series.
Previous entries in this series provided implementation approaches using events and change data capture techniques. This blog highlights certain pros and cons of using events vs. change data capture with respect to order search service implementation in IBM Sterling Order Management.
Change data capture approach
- No code changes are needed in the Order Management application to track changes in data.
- Minimal impact on the database; transaction logging must be enabled to track transactions.
- Transaction log can show a complete replay of updates to the data.
- Data tables can be enabled/disabled for transaction log, allowing for the ability to control the data footprint for lookup and search.
- Contents of transaction logs are proprietary to the database management system; a change data capture tool is needed to interpret them.
- Dealing with changes in data definitions are difficult for the consumer, so customization and product upgrades need revisiting.
- Creation of order data in a format needed for search and lookup from the output is complex and a staging area is needed for data processing.
- Reprocessing of a record via transaction logs is not straightforward.
- Increased solution complexity; additional tools and technologies are added.
- Tightly coupled to database; with modularization of Order Management application, it may be difficult to apply this process to different databases.
- Although this method needs programming the application to track transactions, this provides an accurate picture of data needed for order search and lookup.
- Many events are pre-defined in Order Management and need configuration changes to enable them.
- Pre-established data integration pattern uses an event-based data integration solution with other cloud solutions like IBM Watson® Order Optimizer and IBM Watson Order Insights.
- Reprocessing of an event is easier because each event is tracked and stored.
- Solution complexity is low and hardware footprint is small.
- Easily upgradable.
- Changes in data definition does not affect this approach because all data is present in the order object.
- Application extension/customization/configuration may be needed.
- Increasing the data footprint needs a new application release.
- Event processing consumes resources from the application, although this can be optimized via asynchronous processing and combination of mirror database to some extent.
To summarize, it is difficult to say which approach is better. Software designers should consider the pros and cons of both the approaches with respect to their existing solution boundaries and technical environment prior to selecting one of them.