Use cases

The following use cases describe some of the situations that VPE Sync can address. Note that these just build on the simple two-deployment example described in the previous section.

All of the use cases below share the following basic attributes:

A company has implemented three aPriori deployments and wants to make sure that all three deployments have access to the same VPEs. This company is US-based but has a European (EU) and an Asia/Pacific (APAC) deployment as well.

Use Case 1: VPEs maintained by single deployment

In this example, the deployment in North America is the source where VPEs are maintained and then made generally available. The other deployments do not generate any new/updated VPES.

With VPE Sync, a VPE Sync administrator in the EU deployment who has full VPE permission (CREATE, READ, UPDATE, DELETE) can log into the EU-based Enterprise Platform VPE Sync module and define a new VPE Sync subscription. As soon as this VPE Sync admin user enters the URL for the US-based Enterprise Platform installation, the EU-based server contacts the US-based server which (assuming that the user's credentials and permissions are correct) returns a list of VPEs to which that user can subscribe.

The user then selects the VPE(s) of interest and enters additional information such as a name for the new subscription and an interval when the EU-based server will check for updates.

When the subscriber service detects updated VPEs on the source site, it imports them to the local (subscriber) VPE schema.

An APAC VPE Sync administrator would do the same thing.

With this configuration, any new VPEs delivered by aPriori (or developed/modified internally by the company) would be published to the USA deployment via the VPE Manager. These updates would then be automatically visible to the EU and APAC Deployments within whatever interval the respective VPE Sync administrators set up.

Use Case 2: VPEs maintained by multiple deployments: hub-and-spoke

This case assumes the same deployment configuration as Use Case 1, except that each region is responsible for updating some VPES.

In this case, the designated "primary" site (the USA deployment) adds subscriptions to the VPEs that need to be synced from each subsidiary site. To continue the example above, the USA VPE Sync administrator creates a subscription for VPEs that it should fetch from the EU, and another subscription for VPEs that it should fetch from APAC.

The APAC VPE Sync admin would subscribe to the EU VPEs through the USA hub deployment, not directly from the EU deployment.” Likewise, the EU VPE Sync admin would subscribe to the APAC VPEs through the USA hub deployment, not directly through the APAC deployment.

Use Case 3: VPEs maintained by multiple deployments: peer-to-peer

This use case assumes the same deployment setup as Use Case 2.

The difference is that in this case, instead of the USA site subscribing to each region, and then each region only subscribing to the US, the regions each subscribe to other regions directly. This is a many-to-many or peer-to-peer approach.

Use Case 4: Combinations

This is a more complicated example where regional data VPEs need to be shared following the Use Case 2 ("hub & spoke") approach, but some cost model VPEs need to be shared by only two regions. For example, perhaps the USA and APAC deployments are collaborating and need to replicate a couple of VPEs among themselves. In this case, they may want not to schedule automatic updates for these shared VPEs, but instead perform periodic manual updates.