|
Purpose
This report synchronizes the key fields for clinical order types fromtwo different systems, primarily between the quality assurance system (Qsystem) and the production system (P system).
Please note that you must run the report if you have already implementedthe Clinical System before release 4.72 and are now upgrading to 4.72 orhigher. If you are only implementing the Clinical System from release4.72, you do not need to run the report.
You must run the report once for each client installed in the systembefore you can use the transport function in the master data transactionfor maintaining order types. During a release upgrade, you migrate eachsystem in the system landscape independently of the others. Whenperforming an initial upgrade from a release lower than 4.72 to 4.72 orhigher, you must migrate the old preregistration types to order types.During this process, the system generates technical key fieldssemi-automatically for the newly created objects. These key fields aredifferent from system to system, which means it is not advisable totransport this data, since this would lead to consistencies.
The report synchronizes these different key fields as a backwardsynchronization to ensure the integrity of the production data. Backwardsynchronization means that the data for the order types is transferredfrom the P system to the Q system and is then transferred back to the Psystem along with the additional data already customized in the Q systemby means of a transport request. During this process, the keys from theQ system are replaced by the keys from the P system. Prerequisites
Preregistration types were migrated to order types during an upgrade torelease 4.72 or higher. See also reports RN1UTL49 and N1_MIGPRG.
The following settings must be the same in both systems:
- Client numbers
- Status profiles
- Organizational units
- Hierarchy of organizational units
- Contexts (tables NCXTY and NCXTYT)
In one specific case, synchronization is not possible: Report RN1UTL49is executed during the release upgrade to migrate old preregistrationtypes to order types or new preregistration types.
According to the standard settings, a "Request" context entry isassigned a key comprising the prefix "RQ" and a sequence number. If thiskey already exists, the system assigns a new key with the nextsequential number. This means the keys may be different in the twosystems for which synchronization is taking place.
However, this can only happen if the context definitions whose keysbegin with "RQ" have not been maintained synchronously (due to manualchanges).
- Institutions
- Request types
- Registered service definitions for the object type Clinical Order Type
(table N1WSASSOC)Features System Landscapes Supported
It is only possible to synchronize key fields for order types, and thusconnect the clinical order types to the transport system, between twosystems (for example, P system and Q system, or Q system and developmentsystem (D system)) with the same client number. The function is notsupported for other system landscapes (for example, P client, Q clientwithin a system) or transport tracks (for example, between clients withdifferent client numbers in different systems or between clients in thesame system). General Process Flow of the Report
The report must run for each client in the system and for all systemsbetween which a transport track is defined (for example, Q system and Psystem).
- When the report starts, it first checks the validity of the entries on
the selection screen. (Validity of RFC destination, validity ofpath/file specification)
- When you execute the report, you are asked to enter a transport request,
which is used for the return transport to the P system. If the targetsystem in the transport request you select is not the same as the systemin the RFC destination specified, the system cancels processing.
- The system also cancels processing in any of the following cases:
The two systems have already been synchronized.
The system in which the report is running is a production system.
An error occurs when setting up the connection to the P system.
- Adjustment process
Adjustment of the design elements from the P and Q systems as follows:
The program transfers the keys from the P system for all design elementsthat exist both in the P system and in the Q system (same technical keysor same name in association with the same design element type -one-column, two-column). All design elements that only exist in the Psystem are transferred to the Q system. All design elements that onlyexist in the Q system remain unchanged and are not transferred to the Psystem when the subsequent initial transport to the P system takesplace. Due to the changes to the keys in the Q system, the entries intable N1CORDTYPA (Structuring tab page - assignment of designelement to order type) must also be adjusted in the order types thatonly exist in the Q system.
Adjustment or order types with all dependent data
The adjustment of the order types is split into three stages (from theperspective of the P system).
Order types with the same technical key (migrated preregistration types)
Order types with different technical keys but the same short description
Order types only exist in the P system
The adjustment of the order types and dependent tables basically alwaysinvolves the same procedure:
For data that exists in both systems, the data is taken from the Qsystem (more up to date) but the keys are taken from the P system. Datathat only exists in the P system is simply replicated to the Q system,and data that only exists in the Q system is not changed, unless theforeign keys change (for example, order type ID changes as a result ofpoint 2 above).
This adjustment strategy is used for all tables apart from tableN1CORDTYPA (assignment of design elements/components to order type).This is not possible due to technical restrictions, since the programwould have to search for any design elements that were exchanged. Forthis reason, the program adopts the structure from the P system so as tosafeguard the integrity of the production data. This overwrites anysettings that have already been made on the Structuring tab pagein the Q system. In the worst case, this can lead to inconsistencies inthese order types/preregistration types (for example, there are stillstatus-dependent methods defined but the component is no longer assignedto the order types/preregistration types), which you have to correctmanually later.
Note: There are two ways to avoid this - either byperforming a manual preliminary synchronization in the P system, or byrepeating Customizing in the Q system after synchronization and thesubsequent transport have taken place.
Table N1CORDTSTA, which contains the status profiles that are assignedto the order types, represents another special case. If an order type isassigned a status profile in the P system and is no longer assigned tothe same order type in the Q system, the order type may be inconsistent,since it might now contain two status profiles with overlapping validitydates.
Note: To avoid such inconsistencies, you must make surethat the status profiles that exist in the P system also exist in the Qsystem.
The special adjustment strategy that is used for table N1CORDTYPA isthen also used for table N1COMPCON (component configuration), since thistable depends directly on table N1CORDTYPA.
When adjusting tables N1CORDTWS, N1CORDTPL, and N1CORDTPLT, the systemtransfers any data that exists in the P system and removes the existingdata from the Q system. If there is no data in the P system, the data inthe Q system is retained in the case of table N1CORDTWS. Entries intables N1CORDTPL and N1CORDTPLT in the Q system are removed if the keysof the order types are different.
- Once the adjustment process is completed, the order types that
previously existed in the P system are transferred to the transportrequest that was created beforehand, along with all dependent data.
- Creation of a log file that logs the database changes in the Q system,
as well as the data transported to the P system. You specify thepath/file name for the log file on the selection screen.
- Actual update of the changes in the Q system.
Synchronization in a System Landscape Comprising a D System, QSystem, and P System
You have set up transport tracks from the D system to the Q system andfrom the Q system to the P system. To synchronize all systems, you mustproceed as follows:
You start by carrying out synchronization from the Q system to the Esystem. You run the report in the D system. The table keys aretransferred from the Q system to the E system.
As preparation for using the clinical order, you set up new order typesor modify existing order types in the Q system.
You perform synchronization from the P system to the Q system. You runthe report in the Q system.
You finish synchronizing the systems by carrying out a furtheradjustment between the Q system and the D system. You can only repeatthe synchronization report between the Q and D systems if you delete theentry identifying the two systems for synchronization in database tableN1SYNC_SYSTEMS.
Note: Due to backward synchronization, the table keys aretransferred from the production system to the quality assurance systemin this last step. This can result in the loss of Customizing settingsmade for order types in the Q system.Selection
You must enter the following data for the report on the selectionscreen:
- Source system
Enter an RFC destination that constitutes a connection to the P system.This RFC destination must be maintained beforehand in transaction SM59.You do not need to define a separate RFC destination for each client,since the report processes the data in the current client automatically.
|