SAP ABAP IMG Activity SIMG_ISHCM_GD_CRIT (Explain Procedure in Critical Situations)
Hierarchy
☛ BBPCRM (Software Component) BBPCRM
   ⤷ CRM (Application Component) Customer Relationship Management
     ⤷ CRM_APPLICATION (Package) All CRM Components Without Special Structure Packages
       ⤷ NBAS (Package) Appl. development Hospital System master data, catalogs
IMG Activity
ID SIMG_ISHCM_GD_CRIT Explain Procedure in Critical Situations  
Transaction Code S_KK4_74000449   IMG Activity: SIMG_ISHCM_GD_CRIT 
Created on 19990816    
Customizing Attributes SIMG_ISHCM_GD_CRIT   Explain Procedure in Critical Situations 
Customizing Activity    
Document
Document Class SIMG   Hypertext: Object Class - Class to which a document belongs.
Document Name SIMG_ISHCM_GD_CRIT    

IS-HCM: How to proceed in critical situations

These procedures are only relevant if you are using IS-HCM.

The object of the following documentation is to describe how to best proceed in critical situations when IS-HCM is active in your system. Please refer to the corresponding sections for information on the following situations:

  1. System start
  2. System stop
  3. Release upgrade
  4. Transfer of legacy data
  5. Number range upper limit (almost) reached
  6. After power failure, system crash, etc.
  7. After communication interrupts, communication crashes, etc.
  8. Deleting a system consistently
  9. Euro conversion

________________________________________________________________________

  1. System start

After SAP system power-up, you should always check whether the background jobs scheduled to execute periodically in your system are effectively scheduled and running. The manner in which the system last stopped may have caused periodic job scheduling settings to be lost. Re-schedule missing jobs for periodic execution. The use of a standard naming convention enables you to quickly identify the HCM programs in the job overview (transaction SM37).

Checking the HCM job log after system start also provides a thorough means of analysis. You should check whether problems with individual partner systems were recorded in this log. When jobs are interrupted, a situation can arise, in particular when data is being transferred to the IS-H System, which can only be corrected by taking active measures.

A known problem situation is the existence of .tmp files from previous transfers of data. The procedure for scaling down this problem is described under After communication interrupts, communication crashes in this document. In case of other inconsistencies, please contact SAP via OSS. Make a backup copy of the .tmp file under a different name so as to avoid data loss. Please do not simply rename the file, since otherwise HCM may start again without gaps in data being able to be filled.

  1. System stop

Background processes running in your system are terminated abruptly in the event of a system stop, causing programs to terminate at different undefined points in processing. When the system is next started, the database is usually restored to the last committed status. Unfortunately this does not prevent data inconsistencies within communication.

It is therefore strongly recommended to cancel the scheduled background jobs (in question) and let all active background jobs complete before stopping or restarting the system.

  1. Release upgrades

As described in the upgrade guide, all scheduled background jobs must be cancelled before a release upgrade is carried out. You have to re-schedule these jobs after the upgrade.

Recommendation: the message formatting program should be run again immediately prior to the action (after all application transactions have completed) to format all existing dispatch orders as messages.

  1. Transfer of legacy data

You have to deactivate HCM Dispatch (in the institution-specific control parameters) before transferring legacy data into the IS-H System. If you do not do this, while legacy data is being imported into the IS-H System, it is read from the IS-H database, re-formatted and transmitted to all partner systems. This is unnecessary and adversely affects performance, since legacy data transfer becomes slower as time goes by. It is practical to (re-)schedule your background jobs after legacy data transfer.

You re-activate HCM Dispatch after legacy data transfer.

  1. Number range upper limit (almost) reached

Number ranges ISH_NC02 and ISH_NCI0 are used within HCM to assign (internal) numbers consecutively to the messages. These numbers are the basis for chronological sorting, in particular with HCM Dispatch (number range ISH_NC02). Problems arise when the internal number range upper limit is reached and the system starts assigning numbers from the number range lower limit again. This violates the chronological order of messages when they are transmitted.

It is therefore recommended to make these number range intervals as large as possible from the start. If your initial system configuration has not allowed for this, you can create a correspondingly optimized number range by carrying out the actions described below. Proceed as follows, before the upper limit of the number range is reached:

Restart the system and transmit and process all HCM data. Do not allow users to create new data until you are finished. You have to transmit all data that has accumulated up to this point and is awaiting dispatch. For this, it is not necessary to deactivate HCM Dispatch nor cancel scheduled background jobs, since users cannot enter new data (this condition is essential for error-free processing). To process all HCM data for dispatch, manually start program RNCBLD00 followed by program RNCSND01 (in this order). These programs must execute error-free. The program logs must indicate that all data has been successfully formatted and transmitted.

After all outstanding data has been formatted and dispatched, you can change the number ranges. Reset the number range intervals (ideally to '0'). Save these changes to the number range.

You can now allow users to start working again with the IS-H System. After a period of productive operation, check that everything is functioning correctly.

  1. After power failure, system crash, etc.

The same applies here as for a system start. In particular, abnormal system statuses can occur within HCM, which do not enable normal operation to resume after a system start. In such cases, you should carry out a thorough analysis of the jobs and their logs.

  1. After communication interrupts, communication crashes, and so on.

Communication interrupts or crashes are often initially overlooked. You are made aware of them only by later symptoms (e.g. data missing in subsystems, overflow of tables/files, HCM Monitor messages).

When such situations arise, IS-HCM attaches the greatest importance to avoiding data loss. This explains why the system does not attempt to carry out data transfer if the communication environment is not correctly configured. In turn, this results in large data sets being built up in the system. You have to carry out individual actions to clear these 'backlogs'.

The most common reason for not being able to start the asynchronous HCM functions is the existence of a .tmp file from a previous transfer. Should this message/diagnosis be issued, it is recommended to proceed as follows:

  1. Always begin by making a copy of the existing .tmp file under a different name. Do not simply rename the file, otherwise it may not be possible fill the data gap when HCM restarts.
  2. In general, these problems are not critical for HCM Dispatch. You should check which message is first or last in the files NTISH.tmp or NTHL7.tmp. You must now find these messages in the dispatch log file.
    3. This is particularly simple for messages in the SAP-HCM Version 1.2 standard, since the header segment HEA contains the dispatch reference number of the sending system. You can select the dispatch log directly by specifying this dispatch message number. For HL7 messages or SAP-HCM messages with customer header segments without this number you have to analyze a number of logs (the last ones for this communication partner).
    If both messages are not in the dispatch log file, you can check whether they are still in table NC02. This should be the case. There is no doubt about the cause of the problem now: termination while creating the file .tmp; the data to be transmitted is queued for dispatch. The error correction is simple: just delete the file .tmp. The backlog of data is then transmitted in chronological order to this partner system when the dispatch program is next executed. The time required for transfer varies in relation to the size of the data set.
    If either or both message(s) is (are) in the dispatch log file you have to find all messages that are in the file .tmp and in the dispatch logs (the chronological sequence is of great advantage here). You have to retrieve each of these messages from the dispatch log file by means of the utility RNCUTL18. You can then delete the .tmp file. The outstanding messages together with those retrieved from the log file are transmitted in chronological order to this partner system when the dispatch program is next executed. The time required for transfer varies in relation to the size of the data set.
  3. The consequences of an error are more critical for HCM Receipt. The following problem conditions can occur:
    4. i) If data was
Business Attributes
ASAP Roadmap ID 306   Establish System Administration 
Mandatory / Optional 2   Optional activity 
Critical / Non-Critical 2   Non-critical 
Country-Dependency A   Valid for all countries 
Assigned Application Components
Documentation Object Class Documentation Object Name Current line number Application Component Application Component Name
SIMG SIMG_ISHCM_GD_CRIT 0 I010004207 O I010004232 O I010004233  
Maintenance Objects
Maintenance object type    
History
Last changed by/on SAP  19990816 
SAP Release Created in