# Workflow

## Prepare a Workflow for Replication

| ### Replication of metadata If Agile e6 is used in a distributed environment on different sites, metadata stored in the database can also be saved redundantly in a local database. In such a replicated environment an own database, Agile e6 server, fileserver and business service is installed on server side. The content of the database is replicated asynchronously in defined time intervals. There are different replication variants: 1. Master-Maser All tables are accessible with "update", "insert" and "delete" functions. 2. Master-Snapshot As a general rule, the configuration tables in a snapshot datbase are only accessible as "read only". As a matter of fact, this may have an effect on single modules. Please consider the following characteristics when replicating the database: 1. The allocation of C_IDs is carried out site-specific via database sequences from disjunctive areas. This has to be configured site-specifically. 2. Number generators are configurated site-specifically as well (different entries in the number generator table). 3. An automatism to correct update conflicts is implemented 4. Every table contains additional system columns which have to be maintained with every "Update" and "Insert" operation (Master database server, inserting and changing database server, unique Repl-id). This has some consequences for the workflow: During a running workflow process, the work item masks, fields, menus and selections are created and deleted at runtime. Every time a new activity is started that requires an user interaction, new entries are created and the predecessor entries are deleted.
| Therefore, replication groups have to be modified, if needed, so that the dataview tables for masks, fields, menus and selections are defined as "updatable". This is a necessary prerequesite in order to use the workflow functionality on a location with a snapshot database. Presently, the following limitations apply for the workflow in replicated environments: - Groups, roles and distributors with users from different locations are only usable in a limited way. Distributors for approvals are fully usable. - Work items are only usable site-specifically since in case of update conflicts (several user of different locations modifiy the same record) the regular workflow behavior (the first one wins) can't be mapped accordingly. A prerequesite for the operation of the business service is a correct configuration of the database for the replication. For every environment the following parameters have to be configured: Configuration of the environment Usage of the C_ID generation based on sequences Identification of the database location for the maintenance of the additional replication fields Database dump (sequences, additional system fields, replication objects and packages)
| Changes for the business service: In the file tpl_ABS_env.ini in the directory <ep_root>\axalant\ini the following changes have to be made:
| In the module [Adapter4Objectwarehouse] the following entries have to be made: [Adapter4Objectwarehouse] (...) DB_SRV_ID=<repl_id> ReplSeqStart=1000000001 ReplSeqStop=1999999999 (...) means: existing entries (can be different from customer to customer).
| The replication id is the location identification of a database location. This means that here the same replication id as for the appropriate database is entered. The start and stop values (the values indicated above are only exemplary - use your own values) of the particular replication environment have to match each other. In other words, the start and stop values of the C_ID sequence have to be the same as in the corresponding database. Intersections between different locations are not allowed! If environments have already been created for the business service, these changes have to be repeated in the ABS_<environment>.ini file in the directory <ep_root>\build\applicationServer\<appl_server_name>\deploy\<application_name>\xml\war\. With these settings the workflow is configurated for a replicated environment.