hub

 The hub in the root node in the Enterprise Hub section of the configuration file

 connection

connection is a reference to the database connection in the <connectionsString> section of the configuration file

 route

under the <conection> section in the repository, a number of routes for replication can be configured e.g.
<routes>
    <route to="repo" />
</routes>

schedule

section in the config file for jobs

job

Jobs are scheduled activities that supplements the real-time event-driven replication with regular batch synchronization.

The timestamp of the last load is maintained in both source and destination databases to ensure that even database-restore does not result in missing updates.   Whilst the initial load jobs are scheduled on regular basis, the last-load timestamp ensures that the job id not rerun:

·        Load Job /Fastload Job
These job provide for the initial load of repositories

·        Change Job
This regular job performs the same function as realtime replications, but ensures that updates are replicated regardless of whether the notification addin is enabled

·        Delete Job
Best practice with a distributed environment is not to delete content, but mark it with the status ‘Archived’ so that knowledge is never lost – this job ensures that content that has been deleted at source does not become orphaned in lifecycle/stakeholder views, by deleting diagrams/packages/elements from dependant repositories.  The connections property of job can be used to ensure that t is only run for non-archive repositories

·        Reload Job / FastReload Job
The Enterprise Hub is designed to support real-time replication of connect, and bulk initial load -  this job exists to enable changes to the status or element-type rules result in catch-up replications.

trigger

Triggers are the actions to perform in response to changes (within the <connection .. /> section or for a whole repository within a <job><trigger ... /></job> section

Change Job

The Change Job is designed to run intraday to supplement the real-time event driven replication of for situations where the desktop addin is not enabled.  The “only modified” parameter ensures that the recursive replication does to synchronise elements that have not been changed through the desktop client (typically this only applies when data is loaded through a tool that does not update the modified date of content)

The fast-load threshold parameter of the Hub is used to switch from recursive replication when a very large number of objects have been updated, and fast-load would be quicker

Delete Job

Best practice with a distributed environment is not to delete content, but mark it with the status ‘Archived’ so that knowledge is never lost – this job ensures that content that has been deleted at source does not become orphaned in lifecycle/stakeholder views, by deleting diagrams/packages/elements from dependant repositories. The connections property of job can be used to ensure that t is only run for non-archive repositories

FastLoad Job

The Fast-Load Job can be significantly faster than the recursive load of element at a time, but at the cost of holding most of a source model in memory during replication, provided the server has at least 16gb of memory

FastReload Job

 The Fast Reload job re-replicates any changes to all elements, and is particularly useful if the filter rules have been changed.

 We recommend that it is only run at weekends, when other modelling is unlikely to be running

 LoadJob

 The Load job provides for initial load of models (using the same recursive replication as the Change Job).

 The job only runs if there is not a change replication date, which it creates after initial run

ReloadJob

 The Reload job re-replicates any changes to all elements, and is particularly useful if the filter rules have been changed.

 We recommend that it is only run at weekends, when other modeling is unlikely to be running, and only if there is not enough memory to run fast reload