Repository Synchronization is a feature that allows changes made to a LANSA for i Master Repository to be propagated to Visual LANSA Slave Repositories in order to maintain current object and system information in the Slave Repositories. For example, if a Visual LANSA developer checks in a new field to the LANSA for i Repository, the list of fields shown in other Visual LANSA Repositories would need to be updated in order to match the LANSA for i Master System.
Repository Groups are set up in LANSA for i to reflect how the Visual LANSA repositories are connected to the IBM i repository so that information can be automatically propagated from the IBM i to the Visual LANSA repositories. The propagated information consists of changes to task tracking and partitions on the IBM i, updated information checked in to the IBM i by a member of a work group, and any user initiated requests from the main development environment "work with" panels on the IBM i.
Not all types of changes to objects made by a developer on the IBM i are automatically propagated, but the changes may be manually propagated. For example, if a field is created by a developer using LANSA for i, this new field is not automatically propagated to Visual LANSA. Also, when a developer using Visual LANSA creates a field, it is not automatically propagated. But when a Visual LANSA developer checks-in a new field to the LANSA for i Repository, this change is automatically propagated to other Visual LANSA Repositories. Repository synchronization is based upon a Visual LANSA centric development model where LANSA for i hosts the master repository but all development work is performed using Visual LANSA workstations. (Refer to 6.3.4 Rules for Repository Synchronization.)
A change is propagated by automatically sending a check out for read-only transaction to a slave workstation. Note that if an object is checked out for update in a Visual LANSA Repository, the propagation still overwrites this object. Thus, it is recommended that only one user updates an object at any one time. (Refer to 6.2 Using Task Tracking in LANSA and Task Tracking and Repository Synchronization for more information.) A user on this Visual LANSA Repository would need to check the object out for update again in order to be able to modify it. Remember, check out is always partition-specific. Objects are only checked out to the allowed partitions defined in the PC definition of the member.
A manual developer option also exists in LANSA for i to propagate changes. Refer to Propagating Objects from the IBM i in the LANSA for i User Guide and the Host Monitor in this guide.
Also Sees
LANSA PC Development in the LANSA for i User Guide.
