Patent Publication Number: US-2004057454-A1

Title: Network component management system

Description:
FIELD OF THE INVENTION  
       [0001] The present invention relates to a management system, and in particular to a system for managing a network of nodes or devices wherein the behaviour of individual nodes or devices may be controlled by configurable parameters. More specifically, the system interprets and schedules business rules in order to manage complex systems. For example, the system may be used to manage a telecommunications network, in which individual exchanges represent the configurable nodes.  
       BACKGROUND OF THE INVENTION  
       [0002] The dynamic management of systems with complex scheduling requirements can be particularly challenging. For example, telecommunications networks need to respond to the rapidly changing demands of the network, and exchange switches need to be continually reconfigured according to dynamically changing loads, physical path availability and route costs. The complex interdependencies and needs of heterogeneous components of a network, and the continual expansion of the network, make this an extremely difficult task. The management of such systems may be defined by a set of business rules which define all of the steps necessary to manage the system. These business rules typically require interactions between a number of diverse systems, including human beings. This makes it difficult to manage business operations in an integrated fashion. Furthermore, it may not be straightforward to change the business rules once they have been defined without reprogramming and coordinating a large number of interacting systems. It is desired, therefore, to provide a system for managing complex systems by scheduling and executing business rules, or at least to provide a useful alternative.  
       SUMMARY OF THE INVENTION  
       [0003] In accordance with the present invention there is provided a management system for a network of components, including:  
       [0004] an interface for use in selecting at least one operation to be performed on at least one component of said network, and creating a request that said operation be executed;  
       [0005] an engine for processing said request and executing said at least one operation; and  
       [0006] a scheduler for scheduling execution of said at least one operation by said engine, based on resource constraints of said network.  
       [0007] The present invention also provides a scheduler for scheduling execution of rule requests by a rules engine, based on resources required by each request and an estimated time that each resource is required.  
       [0008] The present invention also provides a management system for network components, including:  
       [0009] a rules engine for executing a rule to perform an operation on at least one of said components, and adapted to save an execution state of the engine during execution of a rule and send a notification concerning resuming execution of the rule; and  
       [0010] a scheduler for receiving said notification and causing resumption of execution of said rule at said execution state.  
       [0011] The present invention also provides a management system for a network of components, including:  
       [0012] a rules engine for executing a rule defining an operation to be performed on at least one of said components, said engine being adapted to detect process exceptions, and in response, save the state of execution of said rule; and  
       [0013] an interface for examining and adjusting said execution state and allowing continued execution of said rule.  
       [0014] The present invention also provides a programming language, stored on computer readable storage medium, for defining business rules, including commands for transmitting and receiving data from network nodes.  
       [0015] The present invention also provides a component management system, including:  
       [0016] a rules engine for interpreting change requests and executing component change modules to submit changes to respective components; and  
       [0017] a scheduler for controlling the timing of execution of said component change modules.  
       [0018] The present invention also provides a management system for a network of components, including:  
       [0019] an engine for processing a request for at least one operation to be performed on at least one component of said network; and  
       [0020] a scheduler for scheduling execution of said at least one operation by said engine, based on resource availability. 
     
    
    
     BRIEF DESCRIPTION OF THE DRAWINGS  
     [0021] A preferred embodiment of the present invention is hereinafter described, by way of example only, with reference to the accompanying drawings, wherein:  
     [0022]FIG. 1 is a schematic diagram of a preferred embodiment of a management system connected to network components;  
     [0023]FIG. 2 is a schematic diagram of the message flow in the management system;  
     [0024]FIG. 3 is a schematic diagram of components of the management system; and  
     [0025]FIG. 4 is a schematic diagram of components of a real-time part of the system. 
    
    
     DETAILED DESCRIPTION OF PREFERRED EMBODIMENTS OF THE INVENTION  
     [0026] Many real-world systems require the coordination and scheduling of events or processes. The management of such systems can be extremely challenging if the processes execute concurrently and have complex interdependencies.  
     [0027] A prime example of such a system is a telecommunications network. These networks are built around switching systems which accept a variety of different data types and protocols from heterogeneous network nodes and route them to other network nodes. They may also provide data, protocol and signalling conversion, information database services, advanced intelligent network features, and transaction-based accounting and billing. Switching systems should respond rapidly to changing conditions, including data load (eg, to distribute traffic evenly across different data links), link availability, and route cost (eg, selecting the cheapest route to a given destination). Due to changes in the requirements of a network, the network data within exchanges must be continually modified. Within the applicant&#39;s network, some 3000 such network data changes are designed and implemented each month, giving rise to approximately 10000 exchange data changes per month. Moreover, telecommunications networks generally include a variety of switching systems from different vendors with different data requirements. Managing these heterogeneous systems in an efficient, reliable and responsive manner is an extremely complex task.  
     [0028] A management system  2 , as shown in the Figures, includes a rules engine  4  and a scheduler  6 . The rules engine  4  is able to execute a number of business operations defined in a set of rules developed according to a structured business rule language. The engine  4  includes an interpreter  64  to process the rules of the language, and other components described below. The rules engine  4  operates with the scheduler  6 , which manages the scheduling of a large, scalable, number of elements  10  and other activities required by the business rules. In conjunction with the rules applied to the rules engine  4 , the scheduler  6  allocates time slots for activities and manages priorities where necessary.  
     [0029] For the example of a telecommunications network, network configuration activities may be broken down into a number of steps which can be defined by a set of rules. Rule dependencies can be defined to ensure that configuration activities occur in the correct order, and the configuration process can be automatically executed by the system. Using a rule-based approach to network management provides a number of benefits, including the ability to easily modify existing rules or add new ones without the need to modify the system itself or to rely on specialised technical staff. On occasions where network field staff need to intervene or control certain events in an interactive manner, this can be accommodated by providing an interactive interface to the rule-based system which allows field staff to interact with or coordinate certain rules.  
     [0030] A Business Management System (BMS)  2  is a software and hardware implementation of the management system which is used to manage a telecommunications network, including network elements  10  in particular switching systems, as shown in FIG. 1. The network may use a diverse array of equipment, such as Nortel DMS, Ericsson AXE and Alcatel System  12  switching systems.  
     [0031] The BMS  2  takes design level requests for changes to the network (Job Requests) and automatically performs the business process required to implement the change within the affected exchanges. This involves the generation and loading of the necessary exchange commands, possible interaction with installation staff, and interaction with other systems. Because the business process for implementing network data changes, and even the types of changes that can be performed, are continually evolving, the BMS  2  provides a highly structured but flexible mechanism for defining the processing performed for each type of network data change (Job Request Type) it supports.  
     [0032] The BMS  2  is based on the rules engine  4  that executes a formally specified business process for each type of network data change. The business process can be changed and refined without changes to the BMS  2  application itself. The rules engine  4  has a range of facilities for interaction with exchanges, the outside world and other information technology (IT) systems, thus giving business process definers considerable flexibility in the definition and refinement of the business process used for each type of network data change (Job Request Type).  
     [0033] The BMS  2  also provides the scheduler  6  that manages the execution of all data changes so that they meet their required by dates, given restrictions on the use of exchange access ports, and the types of data that can be changed at various times during the day.  
     [0034] The BMS  2  provides HTML user interfaces, available over the Internet and/or an Intranet  12 , for staff  14  creating Job Requests, and the field staff  28  that interact with the application while performing installation activity. The more complex business rule exception handling interface is supported by a java applet ‘windows’ interface.  
     [0035] The specification of the business processes is performed within or outside the BMS  2  with the resulting business rules being loaded into a BMS database  62 .  
     [0036] As shown in FIG. 2, the BMS  2  has two major components: a client-server system  5  for handling user interaction, and a real-time system  3  that communicates with exchange switches  30  via mediation computer systems  7 . The client-server system  5  uses HTML and Java interfaces to communicate over an Intranet or Internet  12  to real-time operators  18 , job request operators  14  and rule developers  16 , as shown in the table below. The system supports large numbers (eg, 500) of concurrent users by using Java multi-threading and a CORBA logical three-tier architecture. CORBA is also used to interface the client-server system  5  with the real-time system  3 .  
                       TABLE 1                       User Group   Description   No. Of Users                  Job-Request   User interfaces for submission, tracking,   100       Operators   and manipulation of Job Requests.   10 Concurrent       Real-Time   User interfaces for interaction with    20       Operators   production system during execution    5 Concurrent           of the business rule for a particular           request. These operators monitor for           exceptions encountered in execution of           the business rules, and perform the           interventions necessary to enable           execution to resume.       Field-Staff   User interfaces for booking specific   360       Operators   business operations and for interacting   50 Concurrent           with the business process during           execution. E.g., the rule may allow           the field operator to provide input data           or select one of a number of options           offered by the business rule at           particular points in its execution.       System Rule   User interfaces to enable development and    20       Developers   execution of the language of    2 Concurrent           the BMS system 2.                  
 
     [0037] The real-time system  3  includes the rules engine  4  and the scheduler  6 , and provides the core functionality for implementation of the rules. The real-time system  3  dynamically responds to a number of external and internal inputs, including job completion, responses from external systems, job scheduling activities, and network elements. The system architecture is based upon a multi-CPU concurrent processing environment, and is designed to run continually.  
     [0038] The business rules which the BMS  2  uses to manage the network are software modules written in a BMS language by rule developers  16 . These modules constitute a library of available business operations, and are used to manage the network, and in particular the network elements  10 . The BMS  2  manages network elements  10  in response to Job Requests sent to the BMS  2  by the Job Request operators  14 . The Job Requests indicate which business operation from the library is to be run, and what data is to be supplied. For example, a business rule for the telecommunications network might be “Add new route between exchanges”. The input data for this request would specify which exchanges are affected, the type of route and the number of circuits to be provided by the route, and scheduling information such as the time window in which the operation must be carried out. Concurrency and exclusivity requirements of this rule with other business rules is specified by the business rule as a property of the business rule itself.  
     [0039] The rules engine  4  processes the Job Requests submitted by Job Request operators  14  using data from a variety of sources, including customer data  24 , routing data  26 , and data from other reference databases  20 . When a job is submitted, the scheduler  6  checks whether the constraints of the job can be satisfied. This requires use of the ‘estimates’, which are estimated times required for particular business operations to complete. If the timing requirements of the job correspond to the minimum lead time requirements of the business process, then the system accepts and commences execution of the request, using a Job Module.  
     [0040] To provide structured rule implementation, and to support other operator determined functions, rules are structured in the BMS  2  as layered ‘module’ types. The business rule modules contain high level rules for managing the network elements  10 , but are not specific to any particular vendor or technology. Job Modules invoke a number of subtasks called Exchange Job Modules (EJ modules) which implement operations specific to individual switches in order to realise the initial job request.  
     [0041] A Job Module commences execution when a request is accepted by the system. Job modules contain the highest level definition of a business process. Typically a Job Module validates the input data for the request (calling validation modules to do so), determines what exchanges (network nodes) should be affected, creates an instance of execution of the business rule module for each affected exchange (network node) specifying what lower level business operation should be performed on each (that is, what Exchange Job module should be executed), waits for these to all reach completion, performs any clean up work and then completes. In the “Add route between exchanges” example, the Job Module would check that the two exchanges exist, check that the route type applies to them, and create an instance of the interpreter  64  to perform the work on each.  
     [0042] Exchange Job (EJ) modules contain the highest level definition of the business process to be performed on an individual exchange (network node). It would typically lodge estimates for each of the necessary resources including exchange access time, then call the required Fundamental Exchange Operation (FEO) Modules to interact with any field operators installing the physical equipment and enter the exchange or node commands to configure the new equipment. EJs lodge their set of resource requirements and necessary data for each at the beginning of the business process, then as the business process executes they ask for each of the resources that they declared they would use at the beginning. If the resource is available immediately execution continues else it stops and waits for the scheduler to grant the resource.  
     [0043] FEO Modules define the business process for the individual operations that can be performed on the exchanges (network node). These are discrete business level operations that are used by Exchange Job modules to achieve the required business function. For example, Set route supervision, Configure route multiplexer, Enable route, etc.  
     [0044] Support modules define low level support operations that are used by a variety of different modules in the system. These are typically called by many other modules to perform routine tasks, such as extract the 10th parameter from this list of parameters.  
     [0045] Validation Modules are used to perform validation typically on input data, but can be used on any other sort of data within the system. These perform checks on the information and raise an exception if it does not comply with the requirements of the checks performed.  
     [0046] The BMS language provides a flexible and versatile way to implement business processes, including telecommunications support and communication with other jobs and systems that are concurrently running within the BMS system. The BMS language is powerful, yet is sufficiently simple to allow rule developers with basic programming skills to create new modules. The language supports a small number of data types (including arrays), conditional branching, looping, functions, variables and variable substitution into text strings. The latter is important because data is ultimately sent to switches as text strings. The language also supports interactivity, such as the ability to request and accept data from a terminal. The ability to postpone execution of the remainder of a module is also supported. Since the defined business process may encounter an error during execution (for example, the connection to the node fails), the BMS  2  is adapted to allow operators to view the current point of execution within the business process and perform a range of corrective actions including shifting the point of execution and changing the data being used by the business process. Errors are detected by the engine  4  as a process exception, and in response, the engine  4  saves the execution state of the rule for the process. The state may then be examined and adjusted using an operator interface. A number of built-in functions are also provided to transfer data between the real-time system  3  and the switches. Further details of the BMS language are provided in the Appendix.  
     [0047] The scheduling of job modules can be extremely complex. For example, EJ interdependencies need to be correctly handled, and a number of exchange jobs may need to be loaded into their respective switches within a specified timeframe. Some jobs may even have to run concurrently across the network, or there may be embargo periods for one or more network elements. The scheduler  6  supports such flexible job scheduling, providing Implement After and Implement By dates. Profiles and Constraints are set for individual or groups of network elements to specify when jobs of various types can be implemented, including concurrent execution requirements. Users can interact with the scheduler  6  to determine suitable time windows. The scheduler  6  also provides ‘time lapse protection’ to ensure that network element configuration changes have adequate time to settle before further changes are made.  
     [0048] The set of modules that make up the real-time system  3  and the dominant data flow interactions are shown in FIG. 4. The real-time system  3  includes the scheduler  6  and all of the components of the rules engine  4 .  
     [0049] A Job Request manager  58  of the system  3  manages the creation and user interface initiated life cycle state transitions of the Job Requests, Job Modules, Exchange Job Modules. It also manages “long held” transactions implemented within the system  3 . The state changes made by the manager  58  are persisted in the database  62 .  
     [0050] The scheduler module  6  is responsible for a number of high level functions, such as maintaining the proposed schedule of execution for all non-complete Exchange Jobs. This schedule is based on the scheduling profile defined for each of the exchanges, the estimates submitted by each of the Exchange Jobs, and other scheduling constraints. Estimates provide the expected duration of an operation or type of operation to be performed as defined by the BMS language. The scheduler module  6  initiates the execution of Exchange Jobs by creating Interpreter instances  64  in accordance with the current schedule for that exchange, and determines the effects of proposed changes to the current schedule. The scheduler  6  also detects cases where Exchange Jobs will not be implemented by their required Implement By date and time based on the proposed schedule.  
     [0051] Completion of each business process requires execution of the corresponding high level module or rule. Most modules cannot be executed without having to wait for various services to take place or for access to exchanges or other resources. Thus, execution of the module is broken into multiple “execution sessions” during which the interpreter  64  is actually executing module code. Execution of a module typically requires a number of execution sessions separated by periods of time waiting for other events to take place.  
     [0052] The scheduler  6  assumes that execution of module code that does not require resources takes no time. Thus only waiting for, and execution of, code using resources requires consideration in the scheduling process. Table 2 describes the language elements, corresponding to resources, that are considered in the scheduling process, the parameters that determine when they can be scheduled, and how long should be allowed for them.  
     [0053] At the beginning of its business rule, Exchange Jobs create an estimate for each of the resources required to complete the required business process. The scheduler  6  constructs the predicted schedule from these estimates.  
                       TABLE 2                       Language Element   Description   Parameters                  Exchange Session   These provide access to the exchanges.   Expected               Iterations               Session type               Concurrency type               Expected duration               Followon period       Interactive Session -   These wait for an operator to conduct the   Expected       Non exchange   session or for expiry of the conduct timeout.   Iterations               Expected duration               Conduct Timeout       Interactive Sessions -   These wait for an operator to conduct the   Expected       Exchange connected   session at a time when an Exchange Connect   Iterations           Session can be scheduled, or for the conduct   Session type           timeout to expire.   Concurrency type               Expected duration               Conduct Timeout               Followon period       External Service   These wait for the external service response   Expected       responses   to be available or for the timeout to expire.   Iterations               Timeout value       Wait   These wait for the specified period of time.   Expected               Iterations               Wait period       Implement By point   Contained in the estimate as a marker point   None           for the Implement By date in the schedule.       Implement After point   The marker point for the implement after   None           time for this module. Execution of the           module will stop at this point until the           implement After date and time arrives, and           any predecessor Job Request completes.       Exchange Job Block   This resource is used by Job Modules. It   Expected           causes the Job Module to wait at an   Iterations           END_EJBlock statement until all of the   Expected duration           Exchange Jobs created within that block           have completed.       Synchronise   This is used to synchronise two or more   Expected           Exchange Jobs. When all required Exchange   Iterations           Jobs have reached a synchronise point, they   Timeout           will resume execution. If the time out           expires, an Exception will be raised.       Shared Data   This is used to suspend execution until data   Expected           is supplied by another Exchange Job. If the   Iterations           time out expires, an Exception will be raised.   Timeout                  
 
     [0054] When execution of the module requires any of the estimated resources, it requests the resource giving the estimate entry number returned when the estimate was created. If execution must wait for the resource to become available, the resource estimate is moved to a Requested State and execution suspended until the scheduler grants use of the resource. The resource estimate state is updated allowing the schedule to reflect the actual remaining resource estimates required for the Exchange Job.  
     [0055] A parser  66  is responsible for checking module code syntax and building all the necessary intermediate module code and data structures required for execution of the intermediate module code by the Interpreter  64 . The Interpreter  64  is a key element of the system, and is responsible for executing intermediate module code implementing all of the functions invoked from the executed module. Each interpreter module instance  64  executes a single module, but concurrent execution of a number of interpreter instances allows many individual modules to be executed simultaneously. Although the interpreter  64  is normally invoked by the scheduler  6 , it may also be run independently. This provides the ability to execute module code interactively under the control of real-time operators  18  using debugging facilities such as set execution point, step, inspect variable contents, etc. Static module tests may be generated by interacting with the Interpreter  64 , providing a mechanism for testing a single module in isolation from other modules, production database records, the exchanges, and external systems.  
     [0056] As shown in Table 3 below, the BMS system  2  provides interfaces  68 ,  70 ,  72  to a number of external systems  7 ,  20  over TCP/IP, using application services such as HTTP, FTP, and SMTP, along with IBM&#39;s proprietary MQ (Message Queue) for high-level middleware interfaces.  
                       TABLE 3                       Interface   Technolgy   System                  Users   HTTP,   Browser Interface, eg Internet Explorer           Java       Data   FTP   CHARMS and DPM requests               and responses.           MQ   Requests to databases               (eg CRIS, CIRCOM)       Network Interface   MQ   Via NECH to NEAS               (and ultimately NEM).           FTP   NART       Reporting   SMTP   Notification and Reporting to external               organisational entities.                  
 
     [0057] These external systems  7 ,  20  include a Code Routing Information System (CRIS)  17 , which supplies data to the BMS system  2  to assist in the generation of exchange data. The BMS system  2  distributes tasks to operations field staff via an Activity Information Management System (AIMS)  15 . As an example, this is used to request field staff to change exchange backup disks. A Circuit Commissioning System (CIRCOM)  19  interface is provided to allow external systems to create Job Requests. The BMS system  2  also communicates with a Charge Record Maintenance System (CHARMS)  21  to manage transaction-based billing. The actual switch data is sent to exchanges via a Network Element Manager (NEM)  23 . A NEM interface  68  is responsible for all communications between the Interpreter  64  and the NEM system  23 , and intermediate systems (such as NECH, NEAS and NART) may be used to transfer the communications.  
     [0058] An External Services module  70  is responsible for supporting the external services required by the Interpreter instances  64 . It creates and transmits service requests and then monitors for the corresponding responses. Once a response is received, the scheduler  6  is notified so that the associated Exchange Job can resume execution. The External Services module  70  incorporates interfaces for a SMTP Email Gateway  40 , FTP gateway, and IBM&#39;s proprietary MQ (message queue) for the middleware interfaces. A system input interface  72  supports MQ to allow other systems, such as CIRCOM  19  and CRIS  17 , to create Job Requests.  
     [0059] A Reporting module  74  is responsible for generating reports. Operators have a defined set of reports from which they can select. To request a report, the operator specifies the report type and the time interval to be included. The BMS system  2  prepares the report and makes it available for collection via the HTTP interface within 24 hours. The 24 hour response time for reports allows the BMS system  2  to run the report at a time when it will not impact system performance, rather than when the operator requests it.  
     [0060] A Schedule variations module  76  handles the creation and submission of the Job Requests that record, or, in some cases, implement, temporary variations to a predetermined schedule.  
     [0061] A data access module  78  provides access to the database  62  for all components of the real-time System  3 . This ensures that all database access code is contained in a single module rather than spread throughout other modules, and ensures the transactional integrity of all database accesses by providing complete transactions that can be called by other modules.  
     [0062] In addition to the client-server system  5  and the real-time system  3 , the BMS system  2 , as shown in FIG. 3, also includes an Integration Management System (IMS)  60  and the database  62 . The client-server system  5  uses the NetDynamics Application Server platform from Sun Microsystems to provide user interfaces to client workstations via HTTP. For Java user interfaces, the remote method calls to the NetDynamics business objects are implemented using IIOP (Internet Inter-Orb Protocol) encapsulated by HTTP. Within the NetDynamics environment framework, the client-server system  5  utilises business and data objects to separate the business logic from the data access functionality, providing a logical three tier application architecture with the presentation layer provided by the client workstation using both HTML and Java applets. The client-server system  5  provides interfaces for interacting purely with the database  62  for the creation and maintenance of the controlling data of the system. The user interfaces that allow operators to interact with the real-time functions, such as scheduling and management of exception conditions during the execution of Job Requests, use the services of the real-time system  3 . These are accessed via the Integration Management System (IMS)  60  which makes the real-time system  3  appear to the client-server system  5  as a set of business objects.  
     [0063] While many facilities of the real-time system  3  are controlled by rules and data held by the database  62  that can be maintained by the client-server system  5 , the database  62  is not used as a real-time communication mechanism between the client-server  4  and real-time  3  systems. Real-time interaction between these two major sub-systems is provided by the Integration Management System (IMS)  60 . Because the real-time system  3  operates outside the NetDynamics environment, a bridge from the HTTP/HTML Java domain within NetDynamics to the CORBA/C++ domain of the real-time system  3  is required. The IMS  60  provides this bridging point.  
     [0064] The IMS  60  is implemented within the NetDynamics environment as one or more NetDynamics PAC adaptor objects. PAC adaptors are the facility within NetDynamics which provides access to business functionality that is implemented outside the NetDynamics environment.  
     [0065] While a number of the real-time system modules implement functionality that is accessed by the client-server system  5 , the real-time system modules run and perform processing activities without direct initiation from the user interface. This independence from the user interface forces this set of business functionality to be implemented outside the NetDynamics environment. NetDynamics environment processing commences with a HTTP request and completes when the HTTP response is given.  
     [0066] The core hardware of the real-time system  3  is a Sun Microsystems Enterprise 4500 server with six 366 MHz Ultrasparc CPUs. The system includes 2 gigabytes of RAM and approximately 60 gigabytes of (SCSI-3) disk storage, configured in mirrored disk pairs.  
     [0067] Many modifications will be apparent to those skilled in the art without departing from the scope of the present invention as herein described with reference to the accompanying drawings.  
     Appendix: BMS Language  
     [0068] 1. BMS Processing Library  
     [0069] This library provides procedures and functions for performing BMS specific operations.  
     [0070] 1.1 Resource Estimates  
     [0071] Resource estimates allow BMS to schedule the usage of resources that will be required by jobs. Before resources are used an estimate must be submitted specifying the type of resource that is required and any relevant details for the resource type. Resource estimates have the following information.  
     [0072] (i) A unique identifier  
     [0073] (ii) The resource type  
     [0074] (iii) Any related information to the resource type.  
     [0075] 1.1.1 General Description of the Scheduling Process  
     [0076] Completion of each Exchange Job requires execution of its corresponding module. Most modules cannot be executed without having to wait for various external events to take place or for access to exchanges or other resources. Thus execution of the module is broken into multiple “execution sessions”.  
     [0077] An “execution session” is when the BMS language interpreter is actually executing the module code. Execution of a module typically requires a number of execution sessions separated by periods of time spent waiting for other events to take place.  
     [0078] The BMS scheduling process assumes that execution of module code that does not require external resources takes no time and thus only waiting for and execution of, code using these resources requires consideration in the scheduling process.  
     [0079] As the execution of a Module reaches the point requiring access to any of the estimated resources, it makes a request for the resource detailing the corresponding estimate entry number from the estimate. The making of such a request moves the corresponding entry to the Requested state.  
     [0080] The Schedule is initially populated with the best estimate of the pattern of resource usage. This should be updated if more accurate estimates must be made during execution. The adequacy of this scheduling process relies on the quality of the estimates and the relatively sparse nature of the schedule. To assist in estimate quality improvement, the comparisons of estimated values to actual used values are kept for analysis.  
     [0081] Estimates are submitted using the EstimateCreate procedure and can be updated with the EstimateGetDetails and EstimateUpdate procedures (eg. When the language module is able to provide a better estimate for the amount of time it will require an exchange connection for). Resource estimates are known uniquely by their estimate identifier, which cannot be modified other than through estimate library calls.  
     [0082] During the processing of the job, the state of resources will change to reflect the current state of execution and resources still required by the job. This is facilitated by storing a “resource state” whose value will be changed automatically by calling language constructs or library calls which use the estimate. The valid values for resource state are described in Table 1.  
               TABLE 1                          Resource State                     Resource State   Description               Pending   Use of the estimate entry has not yet been requested.           Initial value when estimate first lodged.       Requested   Use of the estimate entry has been requested but           the request has not yet been satisfied.       Processing   The estimate entry is currently being used.       Used   The estimate entry has been requested and the request           used. Processing as a result of the granting of the           request has been completed.       Completed   The estimate entry is now completely finished with.       Blocking   When in this mode the follow on period (section 1.1.2)           prevents one of the concurrency type&#39;s simultaneous           sessions being used, if one is available within the           scheduling framework. The follow on period does not           need the currency type to be available in the scheduling           framework but blocks one unit if it is available. The           concurrency types associated with time lapsed           protection normally allow only one simultaneous           session so the blocking mode effectively prevents           another connect session of the same concurrency           type occurring.       Nonblocking   When in this mode the follow on period has no effect           on the concurrency type. It is equivalent to a wait           until event. The event in this case is the expiry,           termination, or reversion of the time lapsed protection.           The only use of this mode is so the Gantt chart view           of events will correctly show that the connect           session is still waiting on the time lapsed protection.                  
 
     [0083] 1.1.2 EstimateCreate  
     [0084] 1.1.2.1 Synopsis  
     [0085] This procedure is used to declare a single estimate. Details of the parameters and their specific application to each resource is given in the associated section as specified in Table 2.  
     [0086] 1.1.2.2 Interface  
     [0087] EstimateCreate(WRITE EstimateId: ESTIMATE; ResourceType, IterationCount, SessionType, ConcurrencyType, ExpectedDuration, TimeoutValue, FollowOnPeriod: VAR)  
                   TABLE 2                       Parameter   Description                  EstimateId   The unique EstimateId associated with this           resource. This id must have an ESTIMATE type           (refer to section 1.1.1).       ResourceType   The resource name which is requested. The value           given must be a valid scheduling resource name           constant (refer to Table 4). Details of the parameter           and their specific application to each resource is given           in the associated section as specified in Table 4.       IterationCount   The maximum number of times that this resource will           be used. Can be in the range 0-65535.       SessionType   The type of session required. This value must           be valid for Exchange Sessions and interactive sessions           with exchange connections.       ConcurrencyType   Concurrency type is used by the scheduler to limit           the number of concurrent sessions of each type.           This value must be valid for Exchange Session           estimates or interactive sessions with           exchange connections.       ExpectedDuration   An estimated duration for the resource. The legal           duration range is 0 to 30 * ONE_DAY. This is a           percentage value for the Implement By resource.       TimeoutValue   Duration of time before a timeout of the current           resource will occur. This must be a valid value for           interactive sessions. The legal timeout range is           1 * ONE_MINUTE to 30 * ONE_DAY.       FollowOnPeriod   Defines the expected period following loading           during which special scheduling conditions apply.           The legal follow on period range is           0 to 30 * ONE_DAY.                  
 
     [0088] 1.1.2.3 Estimate Use Contexts  
     [0089] Function names are shown in italics in the following table.  
               TABLE 3                          Estimate Use Contexts                             Resource Type   Function/Construct                       Exchange Session   Exchange Session block           Interactive Session   Interactive session block without an               exchange connection           Interactive Session   Interactive session block with           (exchange connection)   exchange connection           Service Get Reply   ServiceGetReply           Wait   Wait           Implement By Point   Implemented           Implement After Point   WaitForImplementAfterPoint           Exchange Job Block   Exchange job block           Synchronise   SynchroniseWait           Shared Data   SharedDataGet                      
 
     [0090] The following table shows the parameters applicable to each Resource Constant.  
               TABLE 4                          Resource Type Parameters                     Resource Constant   Parameters Used               RES_EXCHANGE_SESSION   IterationCount,           SessionType,           ConcurrencyType,           ExpectedDuration,           Optional FollowOnPeriod       RES_INTERACTIVE_SESS_NON —     IterationCount,       EXCH   ExpectedDuration,           Timeout Value       RES_INTERACTIVE_SESS_EXCH   IterationCount,           SessionType,           ConcurrencyType,           ExpectedDuration,           Timeout Value,           Optional FollowOnPeriod       RES_EXTERNAL_SERVICE —     IterationCount,       RESPONSE   Timeout Value       RES_WAIT   IterationCount,           ExpectedDuration       RES_IMPLEMENT_BY   Optional ExpectedDuration       RES_IMPLEMENT_AFTER   —       RES_EJBLOCK   IterationCount,           ExpectedDuration       RES_SYNCHRONISE   IterationCount           ExpectedDuration       RES_SHARED_DATA   IterationCount           ExpectedDuration                  
 
     [0091] 1.1.3 EstimateGetDetails  
     [0092] 1.1.3.1 Synopsis  
     [0093] This procedure will return the current estimate settings for the estimate specified by EstimateId. Any fields which are not required for the estimate resource type specified will return the empty string, “ ”.  
     [0094] 1.1.4 EstimateUpdate  
     [0095] 1.1.4.1 Synopsis  
     [0096] This procedure will update the current values for the estimate specified by EstimateId.  
     [0097] 1.2 Exchange Commands  
     [0098] These procedures are invoked within an active Exchange Session  
     [0099] 1.2.1 ExchCmd  
     [0100] 1.2.1.1 Synopsis  
     [0101] This procedure sends a command to the exchange using the current exchange connection and returns the exchange&#39;s response to the command. The characters that get sent to the exchange will only contain valid characters in the language and the text formatting constants TAB and NEWLINE.  
     [0102] 1.2.3 ExchCmdReturnErr  
     [0103] 1.2.2.1 Synopsis  
     [0104] This procedure sends a command to the exchange using the current exchange connection and returns the exchange&#39;s response to the command. If an error occurs as a result of the exchange command, execution continues and the module developer should test for and handle the error. On occasions the spontaneous output of SYSTEM RESTART or ERROR INTERRUPT will be returned and must be handled.  
     [0105] 1.2.3 ExchGetSpontaneous  
     [0106] 1.2.3.1 Synopsis  
     [0107] This procedure returns any spontaneous output from the exchange. It is used for expected spontaneous output.  
     [0108] The following values can be returned from the exchange when querying for spontaneous output.  
     [0109] (i) SYSTEM RESTART  
     [0110] (ii) ERROR INTERRUPT  
     [0111] (iii) Any other exchange ouput without a pending command.  
     [0112] 1.2.4 ExchSessionDetails  
     [0113] 1.2.4.1 Synopsis  
     [0114] This procedure returns the current Exchange Session details.  
     [0115] 1.2.5 ExchSessionModify  
     [0116] 1.2.5.1 Synopsis  
     [0117] This procedure updates the current Exchange Session details.  
     [0118] 1.3 Interactive Session  
     [0119] Interaction with the operator during an interactive session is provided through the procedures ISStep Value and ISStepSelection.  
     [0120] 1.3.1 ISStepValue  
     [0121] 1.3.1.1 Synopsis  
     [0122] This procedure is used in an interactive session block to display information to and request a response from the operator. The operator response is provided through Value.  
     [0123] 1.3.2 ISStepSelection  
     [0124] 1.3.2.1 Synopsis  
     [0125] This procedure is used in a interactive session block to display information and request a response from the operator. The operator response is provided from the selection of an option from a fixed list, OptionList. Empty string elements in OptionList will not be displayed.  
     [0126] 1.4 Services  
     [0127] These library functions &amp; procedures support the interaction between the Exchange Job, external systems and organisations.  
     [0128] 1.4.4 ServiceRequest  
     [0129] 1.4.1.1 Synopsis  
     [0130] This function is called to request the specified service. Once the request has been made execution will continue (The interpreter does not wait for a response from the external system). A unique service identifier is returned by the call. This is used to obtain the reply using ServiceGetReply.  
     [0131] 1.4.2 ServiceGetReply  
     [0132] 1.4.2.1 Synopsis  
     [0133] This procedure places the service response data for the request, ServiceRequestId, into ResponseData. If the service request has not completed when this procedure is called, execution will suspend until the service request is completed or the timeout is exceeded.  
     [0134] 1.4.3 ServiceGetReplyReturnErr  
     [0135] 1.4.3.1 Synopsis  
     [0136] This procedure places the service response data for the request, ServiceRequestId, into ResponseData. If the service request has not completed when this procedure is called, execution will suspend until the service request is completed or the timeout is exceeded. If the timeout specified in EstimateId is exceeded, result will be set to SERVICE_TIMEOUT and ResponseData will be undefined.  
     [0137] 1.5 Accessing Stored Exchange Data  
     [0138] 1.5.1 AttribGetValue  
     [0139] 1.5.1.1 Synopsis  
     [0140] This function is called to return attribute data that is stored for an exchange. If AttributeName exists but has no value for the specified exchange, the empty string is returned.  
     [0141] 1.5.2 AttribExchList  
     [0142] 1.5.2.1 Synopsis  
     [0143] This function returns a list of exchanges which have a specified attribute set to the value, Attribute Value.  
     [0144] 1.5.3 AttribSetValue  
     [0145] 1.5.3.1 Synopsis  
     [0146] This procedure sets the value that is stored for an exchange attribute.  
     [0147] 1.5.4 AttribDelValue  
     [0148] 1.5.4.1 Synopsis  
     [0149] This procedure deletes an exchange attribute.  
     [0150] 1.6 Exception handling  
     [0151] 1.6.1 ExceptionCondition  
     [0152] 1.6.1.1 Synopsis  
     [0153] The effect of ExceptionCondition depends on the contents of the Exception parameter, the Job Request state, and whether the Job Request was submitted by an operator or an external system. Table 5 shows the conditions and corresponding actions.  
     [0154] In normal use Validation Modules only call ExceptionCondition if validation has failed, and Job Modules call it with exception set to TRUE once all validation checks have been successfully performed.  
               TABLE 5                          Job Request Exception Actions                             Job Request   Submitted               state   By   Control   Action               Validation   Operator   FALSE   The Validation Result HTML page                   is displayed to the operator. This                   page indicates that validation was                   successful, and displays message.                   The operator may proceed with or                   withdraw the Job Request. An                   execution history record is created.       Validation   Operator   TRUE   The Validation Result HTML page                   is displayed to the operator. This                   page indicates that validation                   failed, and displays message. The                   operator acknowledges the page                   and the Job Request is withdrawn.                   An execution history record is                   created.       Validation   External   FALSE   The Job Request is moved to the           System       submitted state, the External                   System is notified that the Job                   Request has been accepted and                   execution continues. An execution                   history record is created.       Validation   External   TRUE   The Job Request is withdrawn, the           System       External System is notified that the                   Job Request was rejected and                   execution terminates. An execution                   history record is created.       Any state   All sources   FALSE   Execution continues. No execution       except           history record is created.       validation       Any state   All sources   TRUE   An execution exception is       except           generated. An execution history       validation           record is created and the Exchange                   Job state reason is set to message.                  
 
     [0155] 1.6.2 ExceptionSetState  
     [0156] 1.6.2.1 Synopsis  
     [0157] This procedure sets the state that an Exchange Job enters if it encounters an exception.  
     [0158] 1.6.3 ExceptionGetState  
     [0159] 1.6.3.1 Synopsis  
     [0160] This function returns the exception state.  
     [0161] 1.7 Synchronisation  
     [0162] If an action must be performed by one Exchange Job (or set of Exchange Jobs) before other actions are performed by another Exchange Job (or set of Exchange Jobs) then synchronisation can be performed using the synchronisation procedures. Initialisation of the synchronisation service involves a call to SynchroniseSet specifying a unique identifier and the number of Exchange Jobs that will “wait” for synchronisation. Once the synchronisation counter has been setup, each Exchange Job can call SynchroniseWait to cause execution to pause until the number of Exchange Jobs specified have all called Synchronise Wait.  
     [0163] To prevent accidental access to the same synchronisation counter from other jobs that are running in the BMS system (including other jobs using the same job module), each synchronisation counter is identified by Job Request Id, Exchange Job Id and a name.  
     [0164] Table 6 shows how these two calls are used to ensure that re-routing of numbers can only occur once the number range has been setup on the destination system.  
     [0165] Table 7 shows the execution sequence of each Exchange Job using synchronisation.  
               TABLE 6                          Synchronisation Example Psuedo-Code                         Exchange Job   Stmt.           Purpose   Ref.   Pseudo-Code Example               Job Module   JM-1   Submit Estimates.....           JM-2   SynchroniseSet(JRGetIdentifier( ),               NULL_EXCHANGE, “Reroute”,               n);           JM-3   SynchroniseSet(JRGetIdentifier( ),               NULL_EXCHANGE,               “SetupNumbers”, 2);               EJ_BLOCK           JM-4   CREATEEJ EJ1           JM-5   CREATEEJ EJ2           JM-6   CREATEEJ EJ3...EJn           JM-7   END_EJ_BLOCK               ....       Exchange Job 1   EJ1-1   Submit Estimates...           EJ1-2   Setup Destination Numbers on B           EJ1-3   SynchroniseWait(EstId,  JRGetIdentifier( ),               NULL_EXCHANGE,               “SetupNumbers”);               ....       Exchange Job 2   EJ2-1   Submit Estimates...           EJ2-2   SynchroniseWait(estid,  JRGetIdentifier( ),               NULL_EXCHANGE,               “SetupNumbers”);           EJ2-3   Reroute Calls from A to B           EJ2-4   SynchroniseWait(EstId,  JRGetIdentifier( ),               NULL_EXCHANGE,               “Reroute”);           EJ2-5   Remove Numbers from A               ....       Exchange Job   EJx-1   Submit Estimates...       3 . . . n   EJx-2   SynchroniseWait(EstId,  JRGetIdentifier( ),               NULL_EXCHANGE,               “Reroute”);           EJx-3   Reroute number ranges to point to B               ....                  
 
     [0166]               TABLE 7                          Synchronisation Example Possible Execution                                 Exchange       Exchange       Job Module   Job 1   Exchange Job 2   Job 3 . . . n                                                     JM-1                                   JM-2       JM-3       JM-4               EJ1-1       JM-5       EJ1-2                       EJ2-1       JM-6               EJ2-2   Wait                           for EJ1       JM-7   Wait                   EJx-1           for EJ&#39;s               EJ1-3   No           EJx-2   Wait for                   Wait               EJ2               . . .       EJ2-3                       EJ2-4   No                           Wait                       EJ2-5       EJx-3                       . . .       . . .                    
     [0167] 1.7.1 SynchroniseSet  
     [0168] 1.7.1.1 Synopsis  
     [0169] This procedure sets the synchronisation counter specified by JobRequestId, ExchangeName and SynchroniseName by Number.  
     [0170] 1.7.2 SynchroniseWait  
     [0171] 1 . 7 . 2 . 1  Synopsis  
     [0172] This procedure decrements the synchronisation counter specified by JobRequestId, ExchangeName and SynchroniseName and if the counter reaches zero allows all Exchange Jobs waiting on the counter to resume execution.  
     [0173] 1.8 Shared Data  
     [0174] The Shared Data facilities enable the transfer of data between Exchange Jobs within the BMS system. Typical use of these procedures is for one Exchange Job to extract some data from an exchange or external system and write the data to a shared data area for another Exchange Job to read. The Exchange Job waiting for the data will park until the data becomes available at which time it will resume execution.  
     [0175] To transfer information between Exchange Jobs one must know the Job Request identifier and exchange name of the other and both must know the name of the data item. This interaction can be sourced from external systems entry data or other sources.  
     [0176] To prevent accidental access to the same shared data from other jobs that are running in the BMS system (including other jobs using the same job module), each piece of share data is identified by Job Request Id, Exchange Job Id and a name.