Smart Documents 7.0 - Workflow Upgrade Guide
Template creation in Smart Documents generally follows a DTAP approach. Templates go from a Development stage to Test, Acceptance and finally to Production.
In versions prior to 7.0, clients typically use a single ModelStore, in which users create and update all their models (i.e. templates), and publish to multiple PublishStores that each cover one stage in the DTAP approach. This workflow presents several difficulties. It requires a certain level of user knowledge, since users have to decide to which PublishStore their model must be published. It also makes user management quite complicated, since users may have access to their ModelStore but not to all PublishStores defined within the model.
To remove these difficulties, and to prevent Smart Documents users from starting to copy or move models manually from one PublishStore to another - which is never recommended - a new optimal workflow has been introduced in Smart Documents 7.0.
In an optimal Smart Documents 7.0 workflow, each ModelStore has a 1 to 1 relationship to a PublishStore for each stage of the DTAP setup. For instance, ModelStore Test always publishes to PublishStore Test, and ModelStore Production always publishes to PublishStore Production. Once a model is ready to go to the next DTAP stage, you promote it from the current ModelStore to a subsequent one. Depending on the configuration, the model will be published automatically to the corresponding PublishStore, or you publish it manually. Should the results of the published models be unsatisfactory, you can always degrade the models to the ModelStore of any of the previous stages. The published counterpart of the model will be degraded as well, either automatically or manually.
In sum, the new optimal workflow offers the following advantages:
- User management is simplified, since users only have access to their assigned ModelStore(s) and can only publish to the corresponding PublishStore(s).
- When publishing a model, users clearly know to which PublishStore the model will be published, since ModelStores and PublishStores now have a 1 to 1 relationship.