Data source connector mapping

Mapping for testing

Suppose you have a server group named Test. You might want to use one set of State History and Outcome tables with the Test server group in one workspace, and another set of State History and Outcome tables with the Test server group in another workspace.

You can do this by changing the mapping of the data source connector on the Data Source Mapping tab for the deployment configuration.

On the other hand, you might want to use the same State History table for several different test workspaces, to reduce the number of State History tables and data source connectors that you need to create.

Mapping for ramp-up

In Opportunity Detect, ramp-up is the process of accumulating State History data for Container and Pattern components. This enables the system to produce meaningful outcomes quickly, rather than waiting for the history to accumulate over time.

For example, trigger system designers often need to introduce a new trigger system into a production workspace that already includes multiple trigger systems. Suppose that the production workspace consists of 10 trigger systems that have been in production for several months. When a new trigger system is introduced, its history can be ramped up by running it in its own workspace against historical transactions, using the same State History table used for the production workspace.

Because the new trigger system is run in isolation, running it against historical transactions does not affect any of the history of the 10 triggers already in production. After ramp-up, the new trigger can then be copied to the production workspace.

To use this technique, you must mark the State History table Sharable in the server group.

Having multiple workspaces run against the same State History table has this limitation: the application does nothing to guard against simultaneous access of the same history record. This means that if two workspaces use the same State History table and process the same set of customer IDs, it is possible for each workspace to access the same history record simultaneously. If two workspaces access the same State History record at the same time, the application does not fail, but some data may not be saved.

If the risk of losing data is small, then you could run two sets of triggers simultaneously for the same set of IDs, one with real time feeds and the other with batch feeds.

The application provides a way to guard against inadvertent access of two workspaces against the same State History table. If a table is not marked Sharable in the server group, it can be mapped only on the Deployment tab of a workspace, and it can be used by only one deployment configuration at a time.