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_EXTPROG | Explain Programming of Partner Programs |
| Transaction Code | S_KK4_74000452 | IMG Activity: SIMG_ISHCM_EXTPROG |
| Created on | 19990816 | |
| Customizing Attributes | SIMG_ISHCM_EXTPROG | Explain Programming of Partner Programs |
| Customizing Activity |
Document
| Document Class | SIMG | Hypertext: Object Class - Class to which a document belongs. |
| Document Name | SIMG_ISHCM_EXTPROG |
Information on Programming HCM Partner Programs
This documentation provides a detailed explanation of how the HCM transceiver is used within HCM Dispatch and HCM Receipt with partner system connections to the Hospital Communications Module (HCM).
For an introduction to the functionality of these HCM components and to obtain an understanding of the methods and techniques used, please refer to the IS-HCM Function Description. Familiarity with these methods and techniques is the prerequisite for the programming and installation of HCM partner programs used for such partner system connections.
Contents
- Program flow for module PUT_TAB
- Program flow for module GET_TAB
- Program flow for module GET_RESP
- Program flow for module SEND_TAB
- File locking mechanism
- File structure
- Miscellaneous, general
- Program flow for module PUT_TAB
The program is started indirectly from the SAP system by the SAP gateway and a PUT_TAB script. It first checks whether all the required environment specifications have been made. This is necessary to be able to store the data to be transmitted. All messages from IS-H to the partner system are written in chronological order to the file NTISH.dat. To do this, the following environment variables must be set in the PUT_TAB script:
- INTERF_NTISH must specify the directory in which the file NTISH.dat is to be created (the interface directory for this partner system).
Example: setenv INTERF_NTISH /usr/ISHCM/labor
- INTERA_NTISH must be set to '1'. This environment variable controls transceiver file handling in the following way:
- 0 An existing file is overwritten when new data is transmitted. This is the default value. It should not be used with HCM since data loss can occur.
- 1 At a new file transfer, the new data is attached to the existing file. This reorganization lies within the responsibility of the partner system. This is the only practical mode for HCM. SAP recommends you delete the file when you have successfully completed the processing.
- 2 An existing file cannot be changed by the HCM transceiver, in other words, the subsystem must first delete the respective file before a new transfer. This is not practical for HCM, it can lead to a data backlog in IS-H.
Example: setenv INTERA_NTISH 1
If the environment variables are set, the HCM transceiver receives the data in 8k blocks. It transmits an interim acknowledgment to the SAP system after transmitting 10 such blocks. HCM continues transmitting data only on receipt of these interim acknowledgments. If an interim acknowledgment is not received, transmission is considered to have failed. No more data will be (unnecessarily) transferred. The The transceiver's "ready to receive" state is terminated when all data is transferred or CPIC_ERROR occurs.
The data received is first stored in a temporary file. (Note that the name of the temporary file depends on the operating system. For the sake of simplicity, it is referred to as .tmp file hereafter). The actual data file (NTISH.dat) is generated from this file once successful transfer has completed. Before the data file is created from the file .tmp, the interface status file SS_STAT.dat is locked. The file .tmp is now transferred to the file NTISH.dat (in relation to the INTERA_NTISH variables). The file .tmp is deleted. A timestamp and the NTISH specification is stored in the file SS_STAT.dat and the file SS_STAT.dat is then released.
Example SS_STAT entry: NTISH19981231235958
Once all data has been transferred from the SAP system, the system issues a positive acknowledgment (RCVOK) if the number of data records tallies. If the number of records sent does not correspond with the number of records received, the system transfers a negative acknowledgment FALSE to the SAP system. If transfer was faulty, or if an error occurs during .tmp file generation, the HCM transceiver performs a rollback, which means that the .tmp file is deleted and transfer is terminated with an error code.
Before terminating, the PUT_TAB program searches for another shell script (or command file with OS/2 and MS Windows NT) named NTISH.sh (or NTISH.cmd with OS/2 and MS Windows NT). It searches for this script in the subdirectory put_tab.d, where put_tab.d is a subdirectory of the directory containing the PUT_TAB script. SAP recommends this to be a subdirectory of the HOME directory of gateway user c41adm (~c41adm/put_tab.d/NTISH.sh). This requires that the PUT_TAB script be located in the HOME directory of the gateway user (c41adm).
The partner program which continues processing of the NTISH.dat file must lock SS_STAT.dat file in the same way. Do not work with the original file NTISH.dat for an extensive time period since, during this time, the SS_STAT.dat is locked and new data cannot be transmitted. This is why the partner program continuing the processing may only lock SS_STAT.dat for as long as it takes to rename NTISH.dat (but not as NTISH.tmp since this name may be used by the PUT_TAB program). After the file has been successfully processed by the partner system, the renamed file can be deleted. Should problems occur during processing, the file should be combined with a new NTISH.dat file in an original file, in order to prevent loss of data.
- Program flow for module GET_TAB
The program is started indirectly from the SAP system by the SAP gateway and a GET_TAB script. The program first receives information on which file is to be retrieved. This involves transmitting the table name <tname>, a five-digit file name, which combined with the suffix .dat forms the complete file name.
The GET_TAB program first checks whether all the required environment specifications have been made. This is necessary to be able to retrieve the requested file. All messages from the partner system to IS-H must be made available in special files classed by message type. At present, the transfer of the following data is supported by HCM Receipt:
- Case-related diagnoses (file NT021.dat)
- Case-related services (file NT102.dat [or NT101.dat <LSld])
- Surgical data (file NT104.dat [or NT103.dat <LSld])
- Organizational unit-related services (file NT150.dat)
To ensure the corresponding file can be read and processed, the following environment variable must be set in the GET_TAB script:
- INTERF_<tname> must specify the directory in which the <tname>.dat file is made available (the interface directory for this partner system).
Example: setenv INTERF_NT102 /usr/ISHCM/labor
The GET_TAB program renames the .dat file to be transferred as a .tmp file and transfers this file to the SAP system. If a .tmp file for a previous transfer exists, the system issues an error message and aborts.
After all the data has been transferred to IS-H, IS-H system acknowledgment is expected. If acknowledgment is positive (RCVOK), the GET_TAB program (and the connection) is terminated. The .tmp file is retained until acknowledgment of processing is received from the SAP system via the GET_RESP program.
If acknowledgment is negative (FALSE), the .tmp file is turned back into the .dat file. If a new .dat file already exists, the data from the .tmp file is added. This causes the transaction to fail and the initial situation to be restored, whereby new data that may have occurred was taken into account.
The .dat file is locked by the GET_TAB program before access to the file, so that access is exclusive. The partner program which creates the file to be transmitted must also apply this locking mechanism.
Before terminating, the GET_TAB program searches for another shell script (or command file under OS/2 and MS Windows NT) named <tname>.sh (or <tname>.cmd under OS/2 and MS Windows NT). It searches for this script in the subdirectory get_tab.d where get_tab.d is a subdirectory of the directory containing the GET_TAB script. SAP recommends this to be a subdirectory of the HOME directory of the gateway user c41adm (~c41adm/get_tab.d/<tname>.sh). This requires that the GET_TAB script be located in the HOME directory of the gateway user (c41adm).
Note that after the GET_TAB program terminates (when the <tname>.sh script starts) only the transmission of the file is acknowledged and not its processing. The latter is carried out by the GET_RESP program. In most cases, there is therefore little point in having the <tname>.sh script initiate processing of any kind at this GET-TAB event.
- Program flow for module GET_RESP
The program is started indirectly from the SAP&#
Business Attributes
| ASAP Roadmap ID | 899 | not to be assigned |
| Mandatory / Optional | 3 | Nonrequired 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_EXTPROG | 0 | I010004232 | Communication with Systems Inside the Hospital |
Maintenance Objects
| Maintenance object type |
History
| Last changed by/on | SAP | 19990816 |
| SAP Release Created in |
