New electronic data capture requirements frequently involve certain system constraints. These constraints are either:
- platform constraints i.e. systems are designed to run on a certain database platform; and/or
- database schema constraints i.e. if the database is structured to accept data into certain fields, you cannot add fields or change what goes where without system modifications; and/or
- business rule constraints i.e. a system makes certain assumptions about user requirements which apply at the time the system was built. For example, if you are issuing a Sales Invoice, the system knows that it has to apply sales tax to the net total because this is what it has been designed to do. If, however, additional taxes are to be collected at the point of sale, the system designer would not have known at the time to make provision for this.
Requirements, however, do change and organisations are forced to either make system modifications or find ways to meet the new requirements while keeping the existing systems. Let us look at an example:
Your organisation uses an SQL Server based system and has decided to outsource their data capture to a shared service provider that uses an Oracle based system. Even if both parties happen to use an SQL Server platform, the database schema is unlikely to be the same and certainly the front-end system is not going to have the same business rules unless they both have the same system. Short of asking the Shared Service Provider to data capture directly into your system (which may defeat the economy of outsourcing) the ways available for data to be captured in one system and to be updated in another are:
Depending on requirements each of these has both advantages and drawbacks. The one drawback they all have, however, is true system integration. You cannot, for example, search one system to determine if a record exists to avoid duplication and you cannot interact with a system using the information entered in another system. All the existing solutions wait for an event to be completed before they can do something with it. There can be no interaction, while the event is taking place.
The recent launch of the Replicator from Single Click Solutions changes this landscape. Essentially, the Replicator is an SQL Server transaction log reader that operates as a windows service in the background and when certain operations are carried out on a SQL Server database (the WHEN part), certain actions are taken in response (the DO part).
Figure 1 – WhenDo Replication
Apart from the ability to take specified actions in one system in response to certain operations taking place in another system (WhenDo Replication) the REPLICATOR has the ability to trigger additional systems into action in real-time and use data from one to take action in another
Figure 2 – Complete System Integration
Replicator- Configuration form:
1: Configuring source and Destination details:
Similarly, you please select destination server and destination database. And select the destination table from the other tree view. After that please click add button under source data and destination data to add the details into mapping grid.
In mapping grid, you can adjust source and destination details by using “Move Up” and “Move Down” buttons (buttons are in green color). In sql query text area you can add sql query corresponding to the mapping details.
After providing all the details you please click on “Save Mapping” details. After saving the details you can see the mapped details on right top grid “Replicator Mapped Details”.
To apply changes to the Replicator destination tables, Please select on the database and
Source table. Depending upon your table selection all the events corresponding to that particular table will be displayed in events combo.
To execute a particular event please select the event from the combo, so that the data will be replicated to the corresponding destination tables.
Even you can enter any other sql query in sql command text area and can click execute button.
Whenever an event occurs, the event details will be saved in Replicator Log.