The Abort Transaction command stops the processing of the current EDI transaction/message and proceeds to the next one. This command is generally used with conditional logic (error-checking or business logic) to end the processing of an EDI transaction/message based on the presence or absence of specific conditions.
Every time ECMap reads or writes an EDI transaction/message (or an interchange or group envelope), it saves the location of current processing in all open output files. If an ODBC database is being used, it does a commit. (commit signals a successful end-of-transaction, letting the system know that all of the updates in the logical unit of work that has just been successfully completed can be made permanent. Any time before a commit occurs, the system can perform a rollback operation. rollback signals an unsuccessful end-of-transaction, telling the system to undo all of the updates made by the logical unit of work.)
When ECMap encounters an Abort Transaction command, the program uses the results of the saved location to know where to begin processing or where to place the next output. If an ODBC database is being used, the program performs a rollback to the last commit.
X12, EDIFACT, and HL7 all have interchange level envelopes, group level envelopes, and transactions/ messages. In X12, an ST/SE segment is a transaction/message. In EDIFACT, a UNH or UIH segment is a transaction/message. In HL7, an MSH segment is a transaction/ message.
On inbound maps, when neither the user nor the system halts the processing of an EDI transaction/message, the program reads the current input EDI transaction/message and maps data to the output file as it is being processed. ECMap then reads the next EDI transaction/message. When the new transaction/message is read, the location of processing within the open output file is saved. If the program encounters an Abort Transaction rule, it halts processing of the current transaction/message and sends it to the BAD file. The program backs up to the previously saved location of processing in the output file, and a new transaction/message is read. If data was mapped to the output file before the Abort Transaction command was encountered, the program overwrites the data associated with the aborted transaction/ message. The program continues to read and process new transactions/messages, either mapping them to the output file or moving them to the BAD file. (The directory structure and creation of the BAD file depends on the runtime switches that were set.)
On outbound maps, when neither the user nor the system halts the processing of the application data, the program maps the current application record and writes it to the EDI output file as it is being processed. ECMap then reads the next application record. Whenever the program writes a new EDI transaction/ message, the location of processing within the open EDI output file is saved. If the program encounters an Abort Transaction rule, it halts processing of the current application record and backs up to the previously saved location of processing in the output file. A new application record is read and the program begins overwriting any EDI data associated with the aborted transaction (if data was mapped and written before the Abort Transaction command was encountered). The program continues to read and process new application records, mapping them to the output EDI file if no user- or system-generated halts occur.
When the program has finished processing files, it makes sure that all bad data in text files has been overwritten, by checking to see whether the file size is larger than the current location. There is no need to check ODBC files since data is not actually saved to an ODBC database until a COMMIT is encountered. In addition, the program checks all interchange and group level envelopes to make sure that they contain at least one transaction/message. Empty envelopes are not processed.
The Abort Transaction command is usually used in response to conditional logic that has detected an undesirable situation.
