A multischema deployment is another
version of a single instance deployment, but with multiple database
schemas. Enterprises can share the same Configuration schema but have
different Transaction schemas, one for each set of enterprises. Note
that each enterprise-specific Transaction schema is further associated
with a Colony ID.
Note: For more detailed information about colonies,
multischema tables, and how multischema features are implemented by
Sterling Selling and
Fulfillment Foundation,
see
Multischema Overview.
The following multischema deployment example shows
three colonies:
- Colony_A = Configuration E1 + Transaction E1 schemas
- Colony_B = Configuration E2 + Transaction E2 schemas
- Colony_C = Configuration E3 + Transaction E3 schemas
In this type of deployment, the Configuration schema
is shared by all three enterprises, but each enterprise has its own
Transaction schema.
Following are the advantages and limitations of this
multischema deployment.
Advantages
- Central
point of control because it is a single-instance deployment.
- You can run one agent server that will process data
across colonies.
- You do not need to synchronize Configuration data,
such as hub-level pipelines, that is shared by two colonies.
- Colonies can upgrade independently. However, if
an enterprise that was inheriting rules from another enterprise is
upgrading, the Configuration schema of both enterprises needs to be
upgraded. If an enterprise upgrades, its participating organizations
should also upgrade. These include nodes, inventory organization,
capacity organization, catalog organization, and so on.
- Enterprises in different colonies can share the
same Configuration schema, but because they are in different colonies,
they can still be upgraded independently.
- Enterprises in different schemas can inherit rules
from a common organization. For more information, see Using Template Organizations.
- Two different Transaction schemas can inherit some
configuration rules.
- Compared to a single-instance deployment, enterprise
growth can be handled by adding smaller-sized database nodes, rather
than expanding monolithic databases. Compared to a multiple-instance
deployment, the capacity of the application server is better utilized.
- Enterprises can benefit from the isolated Configuration
schema when using the CDT, and at the same time, be able to deploy
Configuration data across multiple colonies. For more information,
see the Configuration Deployment Tool.
Limitations
- Enterprises
that belong to different colonies cannot share inventory, capacity,
items, customers, and vendors.
- In the Configuration Deployment Tool (CDT), you
can compare and migrate Configuration data all at once. But to migrate
Master Data, you must point the CDT to each colony and migrate on
a per-colony basis.
- Enterprises that belong to different colonies cannot
participate with the same ship node. All participating organizations,
including ship nodes, have to share the same Transaction schema.