TURNOVER SYNCHRONIZING- is the process were a form promotion can be copied so that the objects on that form can be automatically duplicated and published to a sideways environment.
TURNOVER EXPLOSION is a core Softlanding function that allows us to explode (or push files) into other environments. This process is called exploding – we simplify and extend this function with TRNSYNC adding the ability to sync to as many other environments as we wish to define.
TRNSYNC creates complete forms for all objects on your original form. These forms can be run at your leisure.
Define Sync Environments
The TRNSYNC (TURNOVER SYNCHRONIZE) command is the front end screen, letting us define environments (or destination libraries) as spawning environments:
When sync applications are defined TURNOVER’s Exit Point function is used to run the exit point processor built into Projex4i Tools. Define the Exit point *API handler (PROJEX4I/TRNX01API) and mark it ACTIVE:
The TRNSYNC command defines all sync environment forms that will be created when the exit point handler runs.
What is the SYNC process?
The sync process will create new forms automatically, based on the form that is running.
These new forms will be created at run time
- These new sub-forms (“synced forms”) will be copies of the form that is running, the only difference being the new application, level or target libraries and the function defined at each line level
- Synced forms can be run manually or automatically
- Synced forms can be setup to need authorization by Change Management Admin
- Synced forms can be defined to run on the local machine or the remote machine
Synced form will allow us to automatically push duplicates of promoted objects into other environments, or to delete those objects from other environments.
This will also allow us to perform clean-up on levels lower in that environment… for example, we could define a synced environment for all level 20 promotions to delete the same objects from the level 10 (QA).
How to Define a Sync Form
Using the command (TRNSYNC) will show us the sync applications maintenance screen.
If we define TRNSYNC on the local (ie: DEV) machine then the spawn form will be created on this machine only.
If we define TRNSYNC on one of the remote machines (ie: TST, PRD) then the spawns will be created on those machines only. This gives us granular control on each environment on the different nodes in our development machine network.
TRNSYNC – Front Screen
The main screen shows all the applications that have been defined as spawning applications. These can be enabled or disabled – allow us to control if the spawning process should happen on or not:
In this example – we can see several sync applications defined with the following conditions:
TECH(0.0) – this application is defined to sync subforms for TURNOVER app(TECH.00.00) level(10) so that any forms that run with this level will atomically spawn a sync form to duplicate these objects into library(LITTENN) replacing the existing objects. Note: the status is DISABLED which means this spawning application will not run until we active it.
TEST(0.0) – The TEST.00.00 application is setup to create three spawned forms: one for level 10 and two for level 20:
We can see the any level 10 forms will spawn a new form to duplicate into libs (TESTT2*) replacing any objects already in there.
We can also see that any level 20 forms will spawn DELETE forms the for the TEST T2 environment. These could be distinct and different libraries. For this example we will update these library names to show the process deleting from both T1 and T2 when the level(20) production forms run.
TEST(1.0) – The TEST.01.00 application is setup to create one form for level 10:
Note: this level uses a specific *LIBL code which could be used to scope *LF differently.
How to define a new spawned application
Creating, or changing, spawned level can be either F6(Create) from front screen or changing an existing level from the main screen (2=Change):
In this case we have changed the library names to point at the T1 environment.
Because we have selected a replacement type of D(Delete) this means that when a form for TEST.0.0(20) runs it will spawn a new form that will contains the same Form Lines but they will be trying to delete the same objects from the TESTT1SRC, TESTT1OBJ and TESTT1DTA libraries.
This is a typical QA library clean-up process for production forms.
This scenario might be defined on the DEV and QA machines – obviously it would not need to be defined on PROD since the TESTT1* libraries do not exist on that machine.
The email address is defined so that we can use TURNOVER standard processing to email the user details of the forms that are created.
Spawn Form Creation Process
Example Scenario:
We create a promotion form to goto TEST.00.00(10)
Our TRNSYNC definition says that a synchro form will be created to spawn duplicates of these form objects into libraries
- Source Library …….: TESTT2SRC TEST Level 10 Library
- Object Library …….: TESTT2OBJ TEST Level 10 Library
- Data Library ………: TESTT2DTA TEST Level 10 Library
Field level prompting is built in to allow us to select both valid TURNOVER APPLICATION codes:
And TURNOVER *LIBL codes:
Libraries must exist and be authorised in order to add them as target libraries.
Example Promotion with Form Details
I checked out a single program (PROOF) using application TEST to level 10:
This application promotion path is *DEV -> TESTQAOBJ -> TESTPDOBJ
Because of our TRNSYNC definition, when we run this form (#622495) it should create a new spawned form which will duplcite these objects from the TESTQA* level into the libraries defined in TRNSYNC – in this case Source Library(TESTT2SRC) , Object Library (TESTT2OBJ) and Data Library (TESTT2DTA).
Run the original form:
Form Runs and finishes normally:
Form Description Appl Rl/Vr Lev Run Programmer Status 622495 testing to main PARE TEST 10 5/14/19 LITTENN FIN-OK
If I change my FORMS filter to view forms created by me – I can see a new form has been spawned:
This new form has the next sequential form number:
But we can see the new target location is to duplicate into th
When we run this form it will FIN with WARNING – this is because the objects are not checked out to this environment. We want this, because we do not want to mess with our original checkout from the master form level.
We can see that the object (PROOF) has been correctly duplicated from TESTQAOBJ into TESTT2OBJ – we can also see the TURNOVER FORM archive object still living in T0622495D in case we want to rollback:
We have quite a bit of flexibility with this technique – and opportunity for future development.