Although IFS/Constraint Based Scheduling transaction management mechanisms run in the background without any user intervention, it is helpful to understand how they operate.
The IFS/Constraint Based Scheduling system is composed of at least three separate computer systems:
The data for scheduling is stored in both the Oracle database and the Scheduling Server. It is very important to keep these copies consistent to ensure that the dates generated by the scheduling process are based on the current status of the IFS shop orders, operations, resources, etc. Maintaining this consistency is the responsibility of the CBS transaction management software.
In the Oracle database, data consistency is maintained by executing a commit statement when a series of creations, updates, or deletions is successfully completed. The series is called a transaction. For example, first a shop order is created, then its operations are created and finally a commit is performed to finalize the new data. If there is an error at some point in the transaction all of the modifications are reversed as if they had never happened. This is called a rollback. For example, if an error occurs while creating an operation, all of the operation creations and the shop order creations are reversed by the rollback. This ensures either that all of the necessary data for a shop order is present if the transaction is successful or that none of it is present if there is an error.
When data associated with a CBS site is modified, the data used for scheduling must be changed on the Scheduling Server as well. For example, if a shop order and its operations are created in the Oracle database, they must be created in the Scheduling Server and scheduled, then the resulting dates passed back to the Oracle database. Likewise, if a shop order due date is changed, it must be changed in the Scheduling Server. If an error occurs in the Oracle processing, the data must then be removed from the Scheduling Server. The transaction management system assures that the commit or rollback consistency is extended beyond the Oracle database to include the Scheduling Server.
In IFS Applications, every time you enter data that will be used by the Scheduling Server, that transaction is registered with the CBS Transaction Manager. A Resource Lock Listener process is started that will listen for the end of the transaction and forward the final commit or rollback. A unique lock is set to signal the end of the transaction, and a test record is inserted to signal that a commit was executed. The transaction then continues with its processing, which may include many creations, updates and deletions, some of which will involve sending data to the Scheduling Server. For example, when a shop order is created, the transaction is registered and the shop order creation is duplicated in the Scheduling Server. The transaction usually includes creating one or more operations, which are also duplicated in the Scheduling Server. In addition, the transaction usually includes creating material requirements for the shop order, but these are not needed for scheduling and are therefore not duplicated in the Scheduling Server.
When the transaction completes, the Resource Lock Listener is notified, because it can acquire the lock that was held by the registered transaction. The Resource Lock Listener then checks the test record. If the transaction was committed, the record will exist. If the transaction was rolled back, the record will not exist, since it was undone along with the rest of the transaction modifications. After the test record check, the Resource Lock Listener signals the Transaction Manager regarding how the transaction was completed. Finally, the Transaction Manager forwards the commit or rollback to the Scheduling Server via the CBS communication system.
Because the transaction management system must listen for either commits or rollbacks while not being affected by them, it is executed as separate Oracle processes or logins. The Transaction Manager and Resource Lock Listeners are PL/SQL packages that are executed from the CBS Bridge. The Bridge executable is a Windows program that runs continuously on a PC. It is normally installed on the same PC that is running the Scheduling Server.
Communication between the user transaction, Resource Lock Listener, and Transaction Manager processes uses specially named Oracle pipes, similar to those used by the CBS communication system.
The transaction management actions can be traced in two places:
The CBS transaction management system assures data consistency among distributed data storage locations without requiring special software or techniques in the Oracle database. It is a fundamental component of the CBS feature of the IFS/Manufacturing solution.