here - Enterprise Integration & Modeling
Contents
1. changes in oepr application oe pr detect update detect delete detect insert time patter month day year hour minute 28 Oracle 7 provide facilities for database triggers and allows user to define procedures that can be implicitly executed when an INSERT UPDATE or DELETE statement is issued against the associated table Oracle92 Oracle 7 treats the triggers as stored procedures and the triggers are stored in the database which are separated from their associated tables The Oracle 7 trigger has three basic parts which are 1 a triggering event or statement 2 a trigger restriction 3 a trigger action So basically mapping our data trigger defined in Babin92 into Oracle 7 s database trigger should be straight forward The information in change in oepr can be mapped into the Oracle trigger statement the rule condition can be mapped into the Oracle trigger restriction and the rule action can be mapped into Oracle trigger action In addition our current rule system only support single trigger it is suggested to extend the syntax to support multiple triggers In order to fully take advantage of the Oracle 7 the syntax of change in oepr should also be extended to include more things such as data items for monitoring the changes on a specific data item in the table 3 2 Local Rule Implementation Our current system can generate the Oracle SOL view for creating the factbase and Oracle Pro C code for the rule2. 31 3 For each rule with rule id of rulexxx three files will be generated for each rule and they are rulexxx mgl which stores MOL views rulexxx sql which stores SOL view and rulexxx pc which stores the Pro C code Example suppose you create two rules in the ruletext doc with rule id to rule007 and rule101 then the following files will be generated rule007 sql store the SOL views for factbase of rule007 rule007 pc store the Pro C code for rule007 rule101 sql store the SOL views for factbase of rule101 rule101 pc store the Pro C code for rule101 4 Compile all your pc files being generated for your rules 5 For those time triggered rules just type timer to start the timer system to check and trigger those rules 6 You can also execute the rules by typing its rule id and call the generated Pro C function for the rule in your own application program If you create new rules you can also put the Pro C function in the action list of your rule to realize the rule chaining 4 2 2 Global Rule Decomposition The global rule decomposition is actually incorporated into the ROPE message generation so what you are using is actually the ROPE message generation 32 1 You can type get rule to retrieve all the global rules from Metadatabase and these rules are stored in ruletext doc You can also create your own global rules but the data items and routines used in your rules should have al
3. The rula2a example for EXEC SQL FETCH factbase INTO fetch data from factbase one tuple each time val QUANTITY val S ADDR val CUST ID val sum0 COST val S ADDR arr val S ADDR len 0 val CUST ID arr val CUST ID len 0 if val QUANTITY gt 10 amp amp val sum0 COST gt 100 condition evaluation strepy val S ADDR arr send notify val S ADDR len strlen send notify notify operator call user defined routine EXEC SOL UPDATE OPS CUSTOMER update local table SET S_ADDR val_S_ADDR 22 WHERE CUST ID val CUST ID 2 1 7 Local Rule Trigger Current local rule implementation can support the following types of trigger events 1 time trigger when time is a specific time has been reached every time after a specified time interval 2 program trigger Application programmer can directly call the generated Pro C code from his program to execute the specified rule 3 rule trigger or rule chaining Rule A can trigger rule B by putting the rule identifier of rule B in its action list just like calling the user defined routines so the rule B will be fired following the execution of rule A 4 user trigger User can execute the rule at any time because the executable code has been generated Current implementation does not support the data trigger which will fire the rule when some database content has been modified database monitor This kind of
4. nvalue IOI STATUSI alias IAI oepr IORDER ITEMI ntype ICONSTANTI valuetype ISTRINGI nvalue IIN ENGI ntype IOPERATORI valuetype IASSIGNI nvalue 1 nb children 21 ntype IITEMI valuetype IIDENTI nvalue IROUTINGI alias IBI oepr IPLANI 44 ntype ICONSTANTI valuetype IINTEGERI nvalue ll ntype IOPERATORI valuetype IASSIGNI nvalue 1 nb children 2 ntype IITEMI valuetype IIDENTI nvalue IPLANSTATUSI alias IBI oepr IPLANI ntype ICONSTANTI valuetype ISTRINGI nvalue IWORKINGI ntype IUPDATE DIRECTIVEI valuetype II nvalue II executed in IPROCESS PLANI sysnames 0 IPROCESS PLANI ntype UPDATE DIRECTIVEI valuetype II nvalue II executed in IORDER PROCESSINGI sysnames 0 ORDER PROCESSINGI REVERSE ADJUST APPLO TREE ntype IRULEI valuetype IRULEI nvalue PREPARE NEW PLAN RII sysnames 0 IPROCESS PLANI sysnames 1 IORDER PROCESSINGI nb children 71 ntype IIFI valuetype IIFI nvalue IFI nb children l11 ntype IOPERATORI valuetype IANDI nvalue ANDI nb children 121 ntype IOPERATORI valuetype IEQI nvalue nb children 121 45 ntype IITEMI valuetype IDENTI nvalue IOI STATUS alias Al oepr ORDER ITEMI ntype ICONSTANTI valuetype ISTRINGI nvalue IDESIGNEDI ntype IOPERATORI valuetype INOTI nvalue NOTI nb children 11 ntype IFN NAM
5. typedef struct ttFinal char itemname the item name of the data item in the final factbase char iformat the data format of the data item in the final factbase int ilength the length of the data format char oeprname the oepr name of the data item tFinal tyoedef struct ttFinalBase char viewname the view name for the independent query base view tFinal itemlist all final factbase data items which belong to this independent query or base view tBase The functions for constructing the above final factbase are stored in the factbase c file and the major functions are build final determine final items build final from Itab build final from Iagg Add updated oepr key into final etc 12 2 1 3 Generation of the MOL Queries The Metadabase based Ouery Language MOL Cheung 91 is employed to represent the creation of factbase for the local rule The advantage of using MOL for local rule is 1 MOL is independent from local DBMS system guery language 2 there exists some modules which were developed for MOL guery processing and Global Ouery System GOS but they can also be re used by local rule implementation this will be explained later in 2 1 4 The generation of MQL queries for local rule follows the same procedures of ROPE message generation Babin 92 page103 The difference is 1 the identifier for view name and aggregate functions are customized for
6. IPLANSTATUSI alias IBI oepr IPLANI 47 ntype ICONSTANTI valuetype ISTRINGI nvalue IWORKINGI ntype IUPDATE DIRECTIVEI valuetype II nvalue II executed in IPROCESS PLANI sysnames 0 IPROCESS PLANI ntype UPDATE DIRECTIVEI valuetype II nvalue II executed in IORDER PROCESSINGI sysnames 0 ORDER PROCESSINGI LAST REARRANGED TREE ntype IRULEI valuetype IRULEI nvalue PREPARE NEW PLAN RII sysnames 0 IPROCESS PLANI sysnames 1 IORDER PROCESSINGI nb children 7 ntype IIFI valuetype IIFI nvalue IF nb children l11 ntype IOPERATORI valuetype IANDI nvalue ANDI nb children 121 ntype IOPERATORI valuetype IEQI nvalue nb children 121 ntype IITEMI valuetype IDENTI nvalue IOI STATUS alias IAI oepr ORDER ITEMI ntype ICONSTANTI valuetype ISTRINGI nvalue IDESIGNEDI ntype IOPERATORI valuetype INOTI nvalue NOTI nb children 11 48 ntype IFN NAMEI valuetype IIDENTI nvalue lexistl nb children 121 ntype IOPERATORI valuetype IEQI nvalue l nb children 121 ntype IITEMI valuetype IDENTI nvalue PART IDI alias IAI oepr IORDER ITEMI ntype IITEMI valuetype IDENTI nvalue IPARTIDI alias IBI oepr IPARTREVI ntype IITEMI valuetype IDENTI nvalue IORDER LINE IDI alias IAI oepr IORDER ITEMI ntype IOPERATORI valuetype IASSIGNI nvalue
7. ROPE message generation for generating messages to each local application system shell for further processing to realize the final execution of the global rule Each partition is used for generating a subrule in the ROPE message generation 27 Part 3 Limitations and Suggestions 3 1 Rule Triggers Current local rule implementation can support the following event triggers they are 1 time triggered the rule can be triggered at a specific time or at a specified time interval 2 user triggered user can executed any rules which are stored in the rulebase at any time 3 program triggered application programmer can directly call the Pro C function defined for a rule in his application program 4 rule triggered rule A can put rule B in its action list and trigger it just like calling a user defined routine It can also use the combination of time trigger and some conditions such as checking the SUM on a data item or COUNT on some kinds of tuples or checking whether EXISTS a specific tuple to monitor the changes to a table but this methods have its limitation So basically current local rule implementation can not fully support data trigger to monitor the table changes such as INSERT DELETE UPDATE etc Oracle 7 provide us some possibilities to implement the data monitoring trigger which is defined in current TSER rule grammar for monitoring the OE PR changes The syntax of the data monitoring trigger is defined as following Babin93
8. VIEW existK AS SELECT FROM existK a UNION 19 SELECT FROM existK b For the COUNT aggregate function there is some difference Let s suppose we have the following function in the rule COUNT lt condition gt b g assuming the condition involves two independent queries a and b The semantic meaning of it is 1 join the view a and view b through the lt condition gt 2 for the new view count how many tuples in each set grouped by b g CREATE VIEW countK b count result g AS SELECT count g FROM b a WHERE lt condition gt GROUP BY b g CREATE VIEW countK a count result g AS SELECT 0 g FROM b WHERE NOT lt condition gt GROUP BY b g CREATE VIEW countK count result g AS SELECT FROM countK a UNION SELECT FROM countK b 4 Generate the final factbase Let s assume the rule contains the following independent queries such as alias1 aliasK 20 and contains the following aggregate functions as aggl aggJ Also we have determined all the data items which will be in the final factbase at 2 1 2 let s say these final data items are item1 item M CREATE VIEW factbase lt item 1 gt lt item M gt AS SELECT lt item 1 gt lt item M gt FROM aliasl aliasK aggl agg J WHERE lt join conditions through group by items in the aggregate functions gt 2 1 6 Generation of the Pro C Code Step 1 Get the detailed information about user defined
9. char operator like UNION EXCLUDE set opertator between views tfunction function record functions like SUM EXIST GROUPBY etc int nb items nb op the number of items and operations tview typedef struct ttguery the detailed information of the query char viewname the view name for this guery char appl the application name char msg id un used for local rule char reply id un used for local rule tselect select the where clause of the query titem items the list of items in the query int nb_items the number of items tquery 2 1 5 Generation of the SQL Views We should generate the SQL views for 1 independent queries or base views or main views 2 aggregate functions views 3 the final factbase view 1 For each independent queries we will generate the SQL view as follows CREATE VIEW alias name lt item1 gt lt itemN gt AS SELECT lt loc_table_il item1 gt local table im itemN gt FROM lt loca table il gt lt loc table im gt WHERE lt join condition 1 gt 17 AND lt join condition 2 gt AND lt join condition k gt The local table name can be determined by the oepr name and the application name and this information has already been stored in the Metadatabase The join conditions for the independent guery have been determined in 2 1 4 Let s see what the local independent query looks like f
10. in depth understanding of the existing systems and ideas such as TSER data structures and modeling methodology Metadatabase system Global Ouery System and Rule Oriented Programming Environment and it involves database rulebase modeling and processing algorithm analysis and implementation software engineering and information integration in the heterogeneous distributed environment etc Therefore this project is appropriate for a Master s project 1 3 Summary The projects purpose is to implement the rules in the Two Stage Entity Relationship Model to allow the rule execution in addition to the rule modeling and rule storage This project has successfully implemented the local rules and can automatically generate the local fact base and the executable code for the local rule execution This project also has implemented the global rule decomposition algorithm for supporting the Rule Oriented Programming Environment ROPE to execute the global rules The results and the underlying methodology of this project could be used for supporting the enterprise information systems with large amount of business operation rules which need to be modeled managed and used In addition combined with the existed Metadatabase technology and ROPE shell technology it can even support the evolution and integration of the different data and knowledge systems in the autonomous distributed and heterogeneous environments The implemented systems have been tes
11. local rule implementation 2 the creation of final distinct view final factbase for local rule implementation is different and it does not contain any un necessary data items The final MOL factbase generated by local rule implementation for rule2a is as follows Distinct From view rule2a main get OUANTITY S ADDR CUST ID From view rule2a sumo get COST For DATE SCHED of view rule2a main DATE SCHED of view rule2a sum0 13 The gen mgl c file contains the functions for generating the MQL queries 2 1 4 Generation of the Local Oueries Current local rule implementation is targeted to Oracle DBMS system and its methods and codes can be easily transported to other local DBMS system As we mentioned in 2 1 2 each independent guery defined by the rule modeler contains data items which are directly or indirectly related to each other in the structural model OER model and it may involves multiple OE PRs When the rule modeler create the rule he may not explicitly specify the join conditions between the OE PRs which are involved in the same independent guery and also such specification would reguire detailed understanding of the OER model Anyway it is obviously not user friendly to reguire the rule modeler to explicitly specify those join conditions In order to release such burden from the rule modeler the local rule implementation needs to generate those join conditions which are not explicit defined in the rule Fortunately
12. most of the functions for local rule implementation and global rule decomposition these functions are stored in the following c or pc files as following rule pc factbase c gen mgl c local pc gen sgl c gen pc c getmdb pc timer c arrange c part c rule tree This file contains the main function for the local rule implementation This file contains functions for determine independent gueries aggregate functions and the data items in the final factbase This file contains functions for generating the MOL views This file contains functions for parsing the MOL file finding the physical data to retrieve and call the local code generation routines This serves as the interface to the local system and it also re use most functions stored in mgl c qproc c which are not listed in this program listing This file contains functions for generating the Oracle SOL views This file contains functions for generating the Oracle Pro C code This file contains functions for getting detailed information from Metadatabase This file contains functions for parsing the trigger information and trigger the local rules according to their event time The modules re used the lexical analyzer of ROPE shell which is stored in lexshell c This file contains functions for re arrange the global rule tree to obtain a set of condition and actions processed in a single system This file contains functions for partitioning the nodes of t
13. operator For the local rule implementation the rule text being manipulated is reversed from Metadatabse and the item identifier becomes lt view specifier gt lt application name gt lt item name G lt oepr name gt because we can determine the OE PR from the metadata at this point The lt view specifier gt is used for defining the independent gueries to relate some data items in some particular fashion Without it we can not precisely model some semantic meaning by the rule Babin 93 The data structure for the node of the rule tree is defined as typedef struct ttnode tptr nvalue int ntype int valuetype int nb_children struct ttnode children char sysnames char executed_in char applname char alias char oepr char func_id tnode the value of the node the type of the node such as constant data item etc the type of the value of this node the number of children of this node the children list of this node un used for local rule un used for local rule the application name the alias for independent queries the OE PR name for this node the function identifier for aggregate function The rule parser also extracts the trigger information from the condition of the rule the trigger information is defined as part of the condition of the rule in the current TSER rule syntax using the special trigger operator removes tri
14. routines in the rule from the Metadatbase such as location and include the file where the routines located at the beginning of the Pro C code For example if the rule used a user defined routine notify operator which is located at u mdb unix ops opsutil c then the Pro C code should contains the following include u mdb unix ops opsutil c Step 2 Generate the host variable declaration section from the final factbase which has being built at step II 1 2 At this point we need the detailed information such as data format and length for each data items which is in the final factbase For example suppose we have three data items in the final factbase such as od status cust order id quantity and the result of the aggregate function such as the sum of the cost then this declaration section generated will be as follows 21 EXEC SQL BEGIN DECLARE SECTION int val OUANTITY VARCHAR val S ADDR 41 VARCHAR val CUST ID 6 float val sum0 COST EXEC SOL END DECLARE SECTION Step 3 Generate the cursor declaration for fetching the data from the factbase For the rule2a example the cursor declaration is generated as the following EXEC SOL DECLARE factbase CURSOR FOR SELECT DISTINCT OUANTITY S ADDR CUST ID sum0 COST FROM rule2a factbase EXEC SOL OPEN factbase Step 4 For each tuple in the factbase evaluating the condition and executing the actions for the updated data items generate the Pro C update statement
15. such automatic join condition determination algorithm has been developed for GOS Cheung 91 page 76 and we can try to re use those modules for our local rule implementation The basic steps for generating the local gueries or views are as follows Step 1 Parsing the MOL file and store the information of the views being defined Step 2 Processing each view to find the physical data to retrieve here we will use the join condition determination algorithm to complete the conditions for each independent gueries 14 Step 3 Generate the guery codes for the local system Oracle SOL to provide the final local factbase for rule execution The data structures defined for GOS and ROPE Babin93 are re used for our local rule implementation and are listed as follows typedef struct ttsource I char appl char subj char oeprs char view char file char tables int nb oepr nb table tsource typedef struct ttitem I char itemname char itemcode char iformat tsource source int selected where the data item come from application name subject name oepr name view name local file name local table list number of oeprs and tables the detailed information of the data item item name item code 5 item format 5 the source where this data item belongs to whether ths item is selected in the query titem typede
16. CHED CUST NAME OD STATUS ORDER LINE ID 50 A Monday JINSONG Delayed 00011 020 10 Z Monday JINSONG Delayed 00011_021 5 PZ200 Monday JINSONG Delayed 00011_022 14 PZ201 Monday JINSONG Delayed 00011_023 SQL gt Now we can see the OD STATUS has been changed after the rule101 is executed Next we will use the local timer system for testing the above rule The above rule is triggered by time using 0 01 which means this rule should be triggered every one minute Let s see u mdb unix timer 23 timer 2 7 7 0 01 6 25 1994 16 38 21 38 6 25 1994 16 39 1 The rule10 is triggered Nothing happens if the condition is false otherwise rule101 condition is TRUE operator is notified rule101 condition is TRUE operator is notified rule101 condition is TRUE operator is notified rule101 condition is TRUE operator is notified rule101 condition is TRUE operator is notified rule101 condition is TRUE operator is notified rule101 condition is TRUE operator is notified rule101 condition is TRUE operator is notified 6 25 1994 16 39 22 AC u mdb unix timer 24 The message of rule101 condition is TRUE operator is notified is generated by the user defined routine in the rule101 which is notify operator Because the final factbase of the rule101 contains 8 tuples so this routine is called eight times 4 3 2 Global Rule Decomposition The tes
17. EI valuetype IDENTI nvalue lexistl nb children 121 ntype IOPERATORI valuetype IEQI nvalue l nb children 121 ntype IITEMI valuetype IDENTI nvalue PART IDI alias IAI oepr IORDER ITEMI ntype IITEMI valuetype IDENTI nvalue IPARTIDI alias IBI oepr IPARTREVI ntype IITEMI valuetype IDENTI nvalue IORDER LINE IDI alias IAI oepr IORDER ITEMI ntype IOPERATORI valuetype IASSIGNI nvalue l executed in IPROCESS PLANI sysnames 0 IPROCESS PLANI nb children 21 ntype IITEMI valuetype IIDENTI nvalue IPARTREVI alias IBI oepr IPARTREVI 46 ntype IFN NAMEI valuetype IIDENTI nvalue Ireguest design revision executed in IPROCESS PLANI sysnames 0 IPROCESS PLANI nb children I1 ntype IITEMI valuetype IDENTI nvalue IPART IDI alias Al oepr IORDER ITEMI ntype IOPERATORI valuetype IASSIGNI nvalue 1 nb children 21 ntype IITEMI valuetype IIDENTI nvalue IOI STATUSI alias IAI oepr IORDER ITEMI ntype ICONSTANTI valuetype ISTRINGI nvalue IIN ENGI ntype IOPERATORI valuetype IASSIGNI nvalue 1 nb children 2 ntype IITEMI valuetype IIDENTI nvalue IROUTINGI alias IBI oepr IPLANI ntype ICONSTANTI valuetype IINTEGERI nvalue ll ntype IOPERATORI valuetype IASSIGNI nvalue 1 nb children 21 ntype IITEMI valuetype IIDENTI nvalue
18. EXEC SQL ROLLBACK WORK exit 1 After compiling the above rule101 pc file we can directly run this Pro C program for the rule101 Let s look at the status of Order Processing System before the execution of this rule SQL select quantity part id date sched cust name od status order line id 2 from ops order item oi ops order o ops customer c 3 where oi cust order id o cust order id 4 and o cust id c cust id 5 and cust name JINSONG The output is as follows QUANTITY PART ID DATE SCHED CUST NAME OD STATUS ORDER LINE ID 5 A Monday JINSONG ON TIME 00011 020 10 Z Monday JINSONG ON TIME 00011_021 5 PZ200 Monday JINSONG ON TIME 00011_022 14 PZ201 Monday JINSONG ON TIME 00011_023 At this point if we execute the rule101 it will not do any actions because the SUM quantity 29 lt 40 and the rule condition evaluation is FALSE Now let s update the quantity to satisfy the rule condition SQL gt update ops_order_item 2 set quantity 50 3 where order_line_id 00011_020 1 row updated SQL gt commit Commit complete 37 Now let s run the rule101 again this time the rule condition is evaluted to be TRUE and some actions should happen let s see SQL gt select quantity part id date sched cust name od status order line id 2 from ops order item oi ops order o ops customer c 3 where oi cust order id o cust order id 4 and o cust id c cust id 5 and cust name JINSONG QUANTITY PART ID DATE S
19. GI nb children 7 42 ntype IIFI valuetype IIFI nvalue IF nb children l11 ntype IOPERATORI valuetype IANDI nvalue ANDI nb children 121 ntype IOPERATORI valuetype IEQI nvalue nb children 121 ntype IITEMI valuetype IDENTI nvalue IOI STATUS alias Al oepr IORDER ITEMI ntype ICONSTANTI valuetype ISTRINGI nvalue IDESIGNEDI ntype IOPERATORI valuetype INOTI nvalue NOTI nb children 1 ntype IFN NAMEI valuetype IDENTI nvalue lexistl nb children 121 ntype IOPERATORI valuetype IEQI nvalue l nb children 12l ntype IITEMI valuetype IDENTI nvalue PART IDI alias IAI oepr IORDER ITEMI ntype IITEMI valuetype IDENTI nvalue IPARTIDI alias IBI oepr IPARTREVI ntype IITEMI 43 valuetype IDENTI nvalue IORDER LINE IDI alias IAI oepr IORDER ITEMI ntype IOPERATORI valuetype IASSIGNI nvalue l sysnames 0 IPROCESS PLANI nb children 2 ntype IITEMI valuetype IIDENTI nvalue IPARTREVI alias IBI oepr IPARTREVI ntype IFN NAMEI valuetype IIDENTI nvalue Ireguest design revision executed in IPROCESS PLANI sysnames 0 IPROCESS PLANI nb children l11 ntype IITEMI valuetype IDENTI nvalue IPART IDI alias Al oepr IORDER ITEMI ntype IOPERATORI valuetype IASSIGNI nvalue nb children 2 ntype IITEMI valuetype IIDENTI
20. Thelmplementation of Rules in the Two Stage Entity Relationship Model by J insong Mao A Project Submitted to the Graduate Faculty of Rensselaer Polytechnic Institute in Partial F ufillment of the Requirements for the Degree of MASTER OF SCIENCE Major Subject Computer Science Approved David L Spooner Sponsoring Faculty Member Rensselaer Polytechnic Institute Troy New York August 1994 Part 1 Introduction 1 1 Background and Problem Statement In order to support the enterprise information systems integration and adaptiveness major efforts have been undertaken by the metadatabase research group at RPI under direction by Professor Cheng Hsu in the past years and the accomplishments include 1 Two Stage Entity Relationship TSER modeling methodology 2 Metadatabse model and management system including a rulebase model 3 Global Ouery System 4 Rule Oriented Programming Environment for supporting the execution of the global rule among heterogeneous distributed systems Hsu92 Bouziane91 Babin92 Cheung91 The TSER modeling includes semantic level modeling SER and operational level modeling OER The SER modeling is used for system analysis and high level design and it has two constructs one is SUBJECT which contains data items functional dependencies and intra subject rules to serve as the functional units or views of information data knowledge the other is CONTEXT which contains the int
21. alue IORDER LINE IDI alias IAI oepr ORDER ITEMI ntype IOPERATORI valuetype IASSIGNI nvalue 1 nb children 2 ntype IITEMI valuetype IDENTI nvalue IPARTREVI alias IBI oepr IPARTREVI ntype IFN NAMEI valuetype IIDENTI nvalue Ireguest design revision executed in IPROCESS PLANI nb children 1 ntype IITEMI valuetype IDENTI nvalue IPART IDI alias Al oepr IORDER ITEMI ntype IOPERATORI valuetype IASSIGNI nvalue 1 nb children 21 ntype IITEMI valuetype IDENTI nvalue IOI STATUSI alias IAI oepr IORDER ITEMI 41 ntype ICONSTANTI valuetype ISTRINGI nvalue IIN ENGI ntype IOPERATORI valuetype IASSIGNI nvalue 1 nb children 2 ntype IITEMI valuetype IIDENTI nvalue IROUTINGI alias IBI oepr IPLANI ntype ICONSTANTI valuetype IINTEGERI nvalue ll ntype IOPERATORI valuetype IASSIGNI nvalue 1 nb children 21 ntype IITEMI valuetype IDENTI nvalue IPLANSTATUSI alias IBI oepr IPLANI ntype ICONSTANTI valuetype ISTRINGI nvalue IWORKINGI ntype IUPDATE DIRECTIVEI valuetype II nvalue ll executed in IPROCESS PLANI ntype IUPDATE DIRECTIVEI valuetype II nvalue ll executed in IORDER PROCESSINGI PREORDER DETERMINE SYSO ntype IRULEI valuetype IRULEI nvalue PREPARE NEW PLAN RII sysnames 0 IPROCESS PLANI sysnames 1 IORDER PROCESSIN
22. cedence constraints among operations in the global rule Babin 93 has developed the decomposition algorithms and it needs to be implemented so that the ROPE system can really work 1 2 Project Goals and Significance The goals of this project are as follows 1 Given the local rules in TSER model and the metadata about the local application system automatically generate the executable code for the execution of the local rules based on the local DBMS 2 Implement of the global rule decomposition algorithm of ROPE to produce an equivalent set of sub rules so that the serial behavior of these sub rules is equal to the original global rules Solving the above two problems provides facilities for the execution of both the local and global rules in the enterprise containing multiple application systems For the rule modeler he can concentrate on the semantic correctness of the rules and do not need to know the coding details and even do not need to be a programmer for the application programmer he can directly use the rules and embed the rules in his programs without worrying about the possible changes to the rules and the coding details of the rules In case of executing the global rules the implementation of the decomposition algorithm can guarantee that the distribution of the rule into local shells retains the global consistency and synergism as the original model Besides the above practical significance this project reguires
23. database monitoring trigger can be implemented with the facilities provided by Oracle Version 7 and it will be discussed in Part 3 current local rule system based on Oracle Version 6 23 A local timer system has been designed for the time triggered local rule From II 1 1 we know the trigger information is extracted from the rule text by the parser and store in a trig mes doc file The time trigger information is stored as lt ruleid gt is triggered by time using lt time gt typedef struct ttrig char ruleid the rule identifier char time the lt time gt information from the trig_mes doc file int delta 5 for non absolute time trigger int triggered there may be many points it be triggered but only once int absolute check whether it is when_time_is or every_time int year month day hour minute next event time ttrig The timer first parse the information stored in trig_mes doc and store the time trigger information in the ttrig structure Then at a pre defined time interval it checks the ttrig list to see which rule s event time equal to the current local time if it match then execute the rule for the non absolute time triggered rule it will update its next event time 2 2 Global Rule Decomposition 24 The global rule contains data items and user defined routines which are distributed in different application systems so the execution of the global rule will be more compl
24. e sort and optimize 0 1 1 1 100 10000 10 100000 1 10000 10 10000 10 0101100 0010000 Flist 0 set include Flist 1 set include Flist 2 set include Flist 3 set include Flist 4 set include Flist 5 set include Flist 6 set include after sort A n f w gt PD o 0 1 1 1 100 100000 1 100000 1 10000 10 100000 1 0001000 0110100 Flist 0 set include Flist 1 set include Flist 2 set include Flist 3 set include Flist 4 set include Flist 5 set include Flist 6 set include after optimize m 0 1 2 3 4 5 Aa DW LO 0000000 0000000 0000000 000200 1 0000200 0010000 0111000 Flist 0 set include 0 4 3 2 1 Flist 1 set include 6 Flist 2 set include 5 The below is partition 0 the initial input value of operations of a partition 0 4 3 2 1 the matrix for the operations in this partition 0 1 1 1 1 10000 10000 10000 10000 the order of the operations in this partition 0 1 2 3 4 The below is partition 1 the initial input value of operations of a partition 6 the matrix for the operations in this partition 0 the order of the operations in this partition 6 The below is partition 2 the initial input value of operations of a partition 5 the matrix for the operations in this partition 0 the order of the operations in this partition 5 END PARTITION end of the program output The partitions generated by the decomposition algo
25. e tnode list int n Determine the strict precedence relationships among the direct child nodes of the root in the rule tree and the result is stored in node matrix for later portioning process The step 2 is implemented in part c and contains the following major functions Generate initial partitions F root node num Generate the initial partitions assign each node under root into a partition Sort partition tpart Flist Place the partitions in a linear seguence and maintain the original precedence relationship Optimize partition tpart Flist Try to reduce the total number of partitions to get the optimal partitions by merging adjacent partitions executed in the same application system Generate ordered list of operation tnode root int nodelist For the partition F containing operations O1 On generate the ordered list of this operations and maintain its original precedence constraints We use Matrix to store the precedence of partitions and use matrix to store the precedence of the operations in each partition 26 The following data structure is used for storing the information about a partition typedef struct ttpart int ids the list of ids of the operation nodes in this partition char apname the application system this partion belongs to int index the index of this partition in the precedence matrix tpart The arrange c and part c have been incorporated into the
26. e to process the rule at the SER level for the local rule implementation 3 3 Global Rule Decomposition Current ROPE shell technology and ROPE message generation only support the serialized execution of the global rule The global rule is decomposed into sub rules where each sub rule is related to a partition generated by the decomposition algorithm in 2 2 For any partitions or sub rule there exists the precedence relationship which is either inherited from the original rule or enforced by the algorithm It s suggested to fully exploit the potential parallelism among the operation nodes of the global rule tree in the future 30 Part 4 Test and Sample Results 4 1 System Environment The system environment this project is developed and tested is as follows 1 Oracle DBMS version 6 on a IBM RS6000 workstation CHIP located at CII 7129 2 Metadatabase System on CHIP 3 Order Processing System on CHIP We use the Order Processing System to test the local rule implementation and use the global rules defined in the Metadatabase to test the global rule decomposition 4 2 User Manual 4 2 1 Local Rule Implementation User can following the procedure described below to play with the local rule system 1 Create your local rule text and store them in the ruletext doc file In ruletext doc the format is one rule per line as follows 2 Type rule to run the program for generating the SOL view and the Pro C code
27. er subject rules to provide the control knowledge among the related information units The OER modeling is used for logical database and rulebase design and it has four constructs which are Entity Plural Relationship PR Mandatory Relationship MR and Functional Relationship FR and they can be mapped from the SER level Hsu92 Bouziane91 We can use the TSER methodology to model both individual local application systems and the global enterprise information systems The data and knowledge modeled by TSER can be populated into the metadatabase including the rulebase according to the GIRD Global Information Resource Dictionary schema We can use TSER to model the rules and use the rulebase model to store the rules in metadatabase but we also need to provide some facilities to support the execution of the rules not just representing and storing the rules For the single local application system we need to provide facilities to automatically generate the executable code for each local rules based on the specific local DBMS and the metadata about the rules For the enterprise containing multiple local application systems it s impossible to directly generate the executable code unless the real heterogeneous distributed DBMS has emerged ROPE develops the local shells technology to support the execution of the global rules but one of the key element for global rule execution is to decompose the global rule into sub rules to maintain the pre
28. ering the above basic information and are explained in details as following The ttIset structure is used for storing all the information related to a independent query typedef struct ttIset char viewname char appllist char objlist char D_of_obj char A of obj int Ind of Temp char Alias of A char D of all char Icode of all tIset the name of the independent query un used for local rule all object related to this independent query data items in each above objects the set of items modified by assignment in a obj flag for the types of update independent query the updated item belong to union of items in all D of objs 5 the itemcode for each item in D of all The following ttItab structure is used for storing the information about a data item appeared in the rule typedef struct ttItab char viewname char itemname char oeprname char applname int iskey which view this data item belong to the data item name the oepr name this item belong to the application this item belong to whether this item is a key item char itemcode char newid int status int is nil int is used int is final tItab itemcode of this item modified for local rule for item identifier whether it is Updated item or Retrieved item whether it is assigned NIL to be deleted w
29. ese functions are identify guery build set complete set and build_Iagg But for the final factbase construction we do not need to follow the same way as the ROPE message generation For the local rule implementation the final factbase will only contain the necessary data items and eliminate all un neccessary data items for the rule execution The aggregate functions in the rule may contain data items which belong to a specific independent guery or main views and if these data items only exists in the condition part of the aggregate functions we do not need to put them into the final factbase The way to build the final factbase for local rule is as follows 1 traverse the rule tree to gathering data items which do not belong to any aggregate functions and mark the is final to be TRUE in the data item s tItab structure 2 for all the updated data items we select the Primary Key of the updated data item into the final factbase 3 From the established 11 Iagg list which stores all the aggregate functions of the rule we determine one data item to be put into the final factbase for each aggregate functions During the above process for each data items which will be in the final factbase we also need to get the detailed information about these data items such as format and length from Metadatabase for later Pro C code generation The following data structures are used for storing the final factbase information
30. ex than the execution of the local rule We need to serialize the execution of the user defined routines and update directives in different systems the appropriate time Algorithms have been developed by Babin Gilbert Babin 92 page 105 page 126 in his Ph D theses and those algorithms are implemented in this project The major steps for global rule decomposition are as follows Step 1 rearrange the condition and actions to obtain a set of condition and actions which are processed in a single system Step 2 Reorder the top level operations of the above rearranged rule tree to obtain an optimal partitioning of user defined routines and update directives The step 1 is implemented in arrange c file which contains the following major functions preorder determine SysO tnode O node Traverse the rule tree in pre order to determine the set of application systems in which the operation node O node a sub tree including all its child nodes to be executed reverse order adjust AppO tnode O node For each operation nodes adjust the system where the node is executed in a reverse order serialize tnode root tnode O node int O pos 25 It contains two major function which are serialize assign and serialize operation They are used for serialize the direct child node of the root node to guarantee each direct child node under the root node will be executed in the same application system generate matrix of precedenc
31. execution In the future it is suggested to extend the current GIRD schema or the rulebase model to store the meta local rule information in the rulebase such as the view names and Pro C routine name related to specific local rule This will be helpful for the future rule management such as delete insert and update the local rulebase 29 As we mentioned in 2 1 4 the local rule implementation need to re use the join condition determination algorithm to complete the join conditions for the independent guery of the rule This algorithm have to search the whole OER model to find the shortest path for linking the related OE PRs which are involved in this independent guery It may be possible to reduce the search space if this algorithm can take advantage of the knowledge of which SUBJECT or CONTEXT this rule belongs to so we just need to search the specific set of OE PRs instead of the whole OE PRs The rule text processed by current local rule implementation is retrieved from Metadatabase so when we parse this rule text to build the rule tree we do not need to strictly check its semantic correctness such as the data type matching for assignment etc This is because we have already checked them when we populate the rule into the Metadatabase If we want to process the rule text directly from IBMS we need to add the semantic checking modules into the current rule parser In addition the rule processing needs the OER information so it s impossibl
32. f struct ttcond the condition component of the query titem iteml the first data item tptr value the result of the evaluation 15 titem item2 char operator int valuetype int is join tcond typedef struct ttselect tcond conds char ops int nb cond tselect typedef struct ttfunction char display fet char value fet char items int nb items tfunction typedef struct ttview char viewname titem items tselect select char viewl char view2 char operands the second data item the operator for the two data items the type of the value check whether it belongs to join condition the whole set of conditions for the where clause of the query the list of the condition components the list of the operations between components the number of the condition components the functions used in the query the function like group by order by etc the functions like sum max count etc the list of data items in the function the number of items the detailed information of the view the view name the set of items in the view the condition expr in WHERE clause for this view the first sub view for exists and count aggrgate function the second sub view for exists and count aggregate function the set of operators work on which items 16
33. following the next major steps Step 1 Parsing the rule text gathering the trigger information and build the rule tree for later processing Step 2 Determine all the necessary and relevant data items which will be used for constructing the factbase Step 3 Generate the MOL gueries views Step 4 Generate the local gueries Oracle SOL views Step 5 Generate the local code fro rule execution Oracle Pro C code Next we provide more detailed description of each steps 2 1 1 Local Rule Language and Parsing For the local rule implementation we re use the parser which has been developed for ROPE system and build the rule tree for later processing The original rule language Bouziane91 has been extended by Babin Gilbert Babin 92 for specifying more precisely the origin of data items etc The data item identifier in the rule will be like this view specifier gt lt application name gt lt item name amp lt determinant gt instead of just lt item name the lt defined in Babin 92 has been changed to to avoid ambiguity during parsing The following is the local rule example which will be used in the following sections rule2a IF every time 1 1 1 1 0 AND ORDER PROCESSING QUANTITY OORDER ITEM gt 10 AND sum ORDER_PROCESSING COST ITEM ORDER_PROCESSING CUST_NAME CUSTOMER maoj ORDER_PROCESSING DATE_SCHED ORDER_ITEM gt 100 THEN ORDER_PROCESSING S_ADDR CUSTOMER send notify notify
34. get OUANTITY DATE SCHED From OE PR CUSTOMER get CUST NAME From OE PR ORDER get OD STATUS CUST ORDER ID Define view rule101 sum0 sum From view rule101 main get OUANTITY DATE SCHED For CUST NAME of view rule101 main JINSONG Distinct From view rule101 main get OD STATUS CUST ORDER ID From view rule101 sum0 get OUANTITY For DATE SCHED of view rule101 main DATE SCHED of view rule101 sum0 3 The content of rule101 sql is as follows 34 create view rule101 main QUANTITY DATE SCHED CUST ORDER ID OD STATUS CUST NAME as select OPS ORDER ITEM OUANTITY OPS ORDER ITEM DATE SCHED OPS ORDER CUST ORDER ID OPS ORDER OD STATUS OPS CUSTOMER CUST NAME from OPS ORDER ITEM OPS ORDER OPS CUSTOMER where OPS ORDER CUST ORDER ID OPS ORDER ITEM CUST ORDER ID AND OPS CUSTOMER CUST ID OPS ORDER CUST ID create view rulel01 sum0 sum QUANTITY DATE SCHED as select sum QUANTITY DATE SCHED from rulel01 main where rule101 main CUST NAME JINSONG group by rulel01 main DATE SCHED create view rule101 factbase OD STATUS CUST ORDER ID sum0 OUANTITY as select rulel01 main OD STATUS rule101 main CUST ORDER ID rulel01 sum0 sum QUANTITY from rulel01 main rulel01 sum0 where rule101 main DATE SCHED rule101 sum0 DATE SCHED 4 The contents of rule101 pc is as follows include lt stdio h gt include u mdb unix ops ops util c EXEC SOL INCLUDE salca EXEC SQL BEGIN DECLARE SECTION VARCHAR use
35. gger information from the rule text so the rule tree being generated by the parser will not contain the trigger information any more Then we store the rule identifier and its trigger information in a specific file for later processing such as local timer system will use the information in this file 2 1 2 Preparation of Data Sets All data items appeared in a rule are directly or indirectly related in the structural model OER model and the system should determine precisely how these data items are related to each other If the rule modeler specify independent sets of related data items we need to generate the related independent gueries for each independent sets defined by lt view specifier gt or lt alias gt As explained in 2 1 1 the syntax for data item is alias application item C oepr name where alias is used for the independent queries After step 1 we have created a rule tree now we need to collect and organize the information such as 1 the independent queries in this rule if no alias we assume there is only one default independent query 2 The set of all data items that must be retrieved by a independent query 3 The set of items modified by assignment statement 4 All the aggregate functions used in the rule etc For the local rule implementation we re used and customized the data structures and functions developed by Yi cheng Tao for the ROPE message generation These data structures are used for gath
36. he global so that the nodes contained in each partition are executed in the same system 54
37. hether it is used before Added for local rule whether it will be in final factbase The following ttloepr structure is used for storing information about a OE PR typedef struct ttloepr char applname char oeprname char lc oeprname char key of oepr char nonkey of oepr char itemcode of key the application this oe pr belong to the oeprname the local table name related to this oepr the key of this oepr the non key items of the oepr the itemcode of the key items char itemcode of nonkey the itemcode of the non key items tloepr The following ttlagg structure is used for storing information about each aggregate functions such SUM MAX MIN AVG EXISTS and COUNT typedef struct ttlagg char viewname char Gk which independent query this aggregate function is related to itis grouped by which data items 10 char Sk condition for this aggregate function char fk the name of the aggregate funct char dk the item the aggregate function is applied on char oeprname un used char applname un used char f_dk the updated result representation int index Added for local rule for indexing these functions tlagg Four functions which were developed for ROPE message generation are re used and customized for building the above information for local rule implementation Th
38. l executed in IPROCESS PLANI sysnames 0 IPROCESS PLANI nb children 2 ntype IITEMI valuetype IDENTI nvalue IPARTREVI alias IBI oepr IPARTREVI ntype IFN NAMEI valuetype IIDENTI nvalue Ireguest design revision executed in IPROCESS PLANI sysnames 0 IPROCESS PLANI nb children 1 ntype IITEMI valuetype IDENTI nvalue IPART IDI alias Al oepr IORDER ITEMI 49 ntype IOPERATORI valuetype IASSIGNI nvalue 1 nb children 21 ntype IITEMI valuetype IIDENTI nvalue IOI STATUSI alias Al oepr IORDER ITEMI ntype ICONSTANTI valuetype ISTRINGI nvalue IIN ENGI ntype IOPERATORI valuetype IASSIGNI nvalue 1 nb children 21 ntype IITEMI valuetype IIDENTI nvalue IROUTINGI alias IBI oepr IPLANI ntype ICONSTANTI valuetype IINTEGERI nvalue ll ntype IOPERATORI valuetype IASSIGNI nvalue nb children 21 ntype IITEMI valuetype IIDENTI nvalue IPLANSTATUSI alias IBI oepr IPLANI ntype ICONSTANTI valuetype ISTRINGI nvalue IWORKINGI ntype IUPDATE DIRECTIVEI valuetype II nvalue II executed in IPROCESS PLANI sysnames 0 IPROCESS PLANI ntype UPDATE DIRECTIVEI valuetype II nvalue II executed in IORDER PROCESSINGI 50 sysnames 0 ORDER PROCESSINGI THE MATRIX OF PRECEDENCE 0 1 1 1 100 10000 10 100000 1 10000 10 10000 10 0101100 0010000 befor
39. or the example rule2a create view rule2a main COST QUANTITY DATE SCHED CUST ID CUST NAME S ADDR as select OPS ITEM COST OPS ORDER ITEM QUANTITY OPS ORDER ITEM DATE SCHED OPS CUSTOMER CUST ID OPS CUSTOMER CUST NAME OPS CUSTOMER S ADDR from OPS ITEM OPS ORDER ITEM OPS ORDER OPS CUSTOMER where OPS ORDER CUST ORDER ID OPS ORDER ITEM CUST ORDER ID AND OPS CUSTOMER CUST ID OPS ORDER CUST ID AND OPS ITEM PART ID OPS ORDER ITEM PART ID We can see the join conditions in the WHERE clause which is generated by the join condition determination algorithm 2 For aggregate functions like SUM MAX MIN AVG 18 Let s use AVG as a example for avg d condition g where d is the data item the aggregate function is applied on g is the data item the aggregate function is grouped by CREATE VIEW viewname avg d g AS SELECT avg d g FROM lt view name of the independent guery this AVG belong to gt WHERE lt condition gt GROUP BY g 3 For aggregate function like EXISTS and COUNT Let s suppose we have the following aggregate function in the rule EXISTS condition b g assuming the condition involves two independent queries a and b The following SOL views will be generated CREATE VIEW existK b exist result g AS SELECT 1 g FROM b a WHERE lt condition gt GROUP BY b g CREATE VIEW existK a exist result g AS SELECT 0 g FROM b a WHERE NOT lt condition gt GROUP BY b g CREATE
40. ready existed in the Metadatabase 2 Type rparser to run the ROPE message generation program the global rule decomposition has been incorporated into this program and for each rule it will generate one message file for each application system and you can see all the intermediate results of the decomposition process such as the rearranged rule tree the precedence matrix for the partitions being created 4 3 Sample Results 4 3 1 Local Rule Implementation The following is one of the example rules for testing the local rule implementation and this rule should first be stored in the ruletext doc file rule101 IF every time 1 1 1 0 1 AND sum ORDER PROCESSING QUANTITY GORDER ITEM ORDER PROCESSING CUST NAMEOGOCUSTOMER JINSONG ORDER PROCESSING DATE SCHEDOORDER ITEM gt 40 THEN ORDER PROCESSING OD STATUS ORDER Delayed notify operator a After running the local rule implementation program the following files will be generated 1 trig mes doc This file store the trigger information 33 2 rule101 mql This file store the MOL gueries 3 rule101 sql This file stores the SOL views for factbase 4 rule101 pc This file stores the Pro C code for the rule The following lists the contents of each files 1 The content of trig mes doc is as follows rule101 is triggered by time using 7 7 7 0 01 2 The content of rule101 mql is as follows Define view rulel01 main From OE PR ORDER ITEM
41. rithm is used by the ROPE message generation and each partition will become a subrule and stored in the message files sent to local application systems Let s see the sub rule portion of the message files generated for this rule 52 For the above global rule because it only involves two different application systems so all the sub rules generated by the ROPE message generation will be stored in the two message files related to those two application systems these two message files are mdbops0 000 and mdbpps0 000 The following just list portions of those two files to illustrate the sub rules generated from the partitioning result of the global rule decomposition algorithm INSERT PREPARE NEW PLAN RI STARTS WITH pps PREPARE NEW PLAN RIS I DECOMPOSED INTO ops PREPARE NEW PLAN R1 2 store pps PREPARE NEW PLAN RI 3 mdbops0 000 13 lines 331 characters INSERT PREPARE NEW PLAN RI STARTS WITH pps PREPARE NEW PLAN RI 1 triggered by time using 1 00 DECOMPOSED INTO pps PREPARE NEW PLAN RIS I A ITEM 102 ITEM 98 DESIGNED AND NOT exist 0 ORDER LINE ID RESULT B ITEM 66 ITEM 67 WORKING B ITEM 66 ITEM 73 0 A IT EM 102 ITEM 98 IN ENG B ITEM 55 ITEM 55 request design revision ASITEM 102 ITEM 100 ops PREPARE NEW PLAN R1 2 ppsfPREPARE NEW PLAN RI 3 store mn mdbpps0 000 114 lines 2991 characters 53 Part 5 Program Listing This section contains
42. rname 20 VARCHAR password 20 EXEC SQL END DECLARE SECTION main strcpy username arr ops username len strlen username arr strcpy password arr ops password len strlen password arr EXEC SQL WHENEVER SOLERROR GOTO sqlerror EXEC SQL CONNECT username IDENTIFIED BY password rule101 35 return sglerror printf error in rule execution of rule101 n EXEC SQL WHENEVER SQLERROR CONTINUE EXEC SQL ROLLBACK exit 1 rule101 EXEC SQL BEGIN DECLARE SECTION VARCHAR val_OD_STATUS 11 VARCHAR val_CUST_ORDER_ID 10 int val sum0 OUANTITY EXEC SOL END DECLARE SECTION EXEC SQL WHENEVER SQLERROR GOTO sqlerror EXEC SQL DECLARE factbase CURSOR FOR SELECT DISTINCT OD_STATUS CUST ORDER ID sum0 OUANTITY FROM rule101 factbase EXEC SOL OPEN factbase EXEC SOL WHENEVER NOT FOUND GOTO end of fetch for EXEC SQL FETCH factbase INTO val OD STATUS val CUST ORDER ID val sum0 QUANTITY val OD STATUS arr val OD STATUS len 0 val CUST ORDER ID arr val CUST ORDER ID len 80 if val sum0 QUANTITY gt 40 strepy val OD STATUS arr Delayed val OD STATUS len strlen Delayed notify operator a EXEC SOL UPDATE OPS ORDER SET OD STATUS val OD STATUS WHERE CUST ORDER ID val CUST ORDER ID end_of_fetch EXEC SQL CLOSE factbase 36 EXEC SOL COMMIT WORK RELEASE return sglerror EXEC SOL WHENEVER SOLERROR CONTINUE
43. ted in the Order Processing System Process Planning System Shop Floor Control System and Product Database System in the Computer Integrated Manufacturing environment at RPT s metadatabase research group Part 2 Technical Descriptions This section contains the detailed description of the local rule implementation and global rule decomposition 2 1 Local Rule Implementation The basic idea for local rule implementation is to automatically generate the detailed local DBMS system codes such as the code for creating the factbase and the code for fetching data from factbase evaluating the condition and executing the actions of the rule for the local rule execution Current implementation is targeted to Oracle DBMS version 6 and it can generate 1 Oracle SOL view for creating the factbase and 2 Oracle Pro C code for executing the rule The local rule syntax will be the same as the TSER rule grammar Babin 93 except that all the data items and routines are located in the same local application system It contains three major parts which are trigger condition and actions Based on the current existed system we can modeling the rule through the Information Base Modeling System IBMS and store the rule in the rulebase of the Metadatabase system We can easily retrieve a specific rule out from Metadatabase or directly from IBMS Then the local rule system will generate the necessary codes from the rule text according to the algorithm
44. ting global rule which is stored in the ruletext doc is as follows PREPARE NEW PLAN RI IF every time 1 1 1 1 0 AND A OL STATUS DESIGNED AND NOT exist A ORDER PROCESSING PART IDG ORDER ITEM B PARTID G PARTREV A ORDER LINE ID THEN B PARTREV G PARTREV 39 request design revision A ORDER PROCESSING PART IDG ORDER ITEM A OL STATUS IN ENG B ROUTING 0 B PLANSTATUS WORKING The output related to the global rule decomposition is listed as follows BEGIN SERIALIZE AND PARTITION THE ORIGINAL RULE ntype IRULEI valuetype IRULEI nvalue IPREPARE NEW PLAN RII nb children 71 ntype IIFI valuetype IIFI nvalue IF nb children l11 ntype IOPERATORI valuetype IANDI nvalue ANDI nb children 121 ntype IOPERATORI valuetype IEQI nvalue l nb children 121 ntype IITEMI valuetype IDENTI nvalue IOI STATUS alias Al oepr IORDER ITEMI ntype ICONSTANTI valuetype ISTRINGI nvalue IDESIGNEDI ntype IOPERATORI valuetype INOTI nvalue NOTI nb children 11 ntype IFN NAMEI valuetype IDENTI nvalue lexistl nb children 121 ntype IOPERATORI valuetype IEQI 40 nvalue nb children 121 ntype IITEMI valuetype IDENTI nvalue PART IDI alias IAI oepr IORDER ITEMI ntype IITEMI valuetype IDENTI nvalue IPARTIDI alias IBI oepr IPARTREVI ntype IITEMI valuetype IDENTI nv
Download Pdf Manuals
Related Search