|
| ICCS.MD.090 - Application Code |
| OMG = Oracle Method Guideline | ||
| OMS = Oracle Method Standard | ||
 |
| General |
| OMG-10042: | Document any unusual design decisions including the reasons in the Notes property of the respective object. |
| Rationale | This helps your team members understand the decisions that have been made. It is also valuable information for anyone performing QA on the project. | |
| OMS-61518: | When a secondary access element or secondary access controlled element (SAC) is deleted, this should be recorded in the notes of the primary access element or Primary access controlled (PAC) element. |
| Rationale | Analysts or developers might want to know what happened to the SAC. If this kind of information is not recorded, the person that can explain, might not be available on the project, if at all. |
| Example | The deletion of an attribute is recorded in the notes of the entity. | |
| OMS-61537: | Document any deviations of the CDM Standards in the respective Notes, including the OMS Standard code and the reason. |
| Rationale | Documenting these deviations helps your team members understand the decisions that have been made. This is also valuable information for anyone performing QA on the project. | |
 |
Note: If you deviate from any OMS standards on a project level, do not include the deviation for every object. If there is only one Application System involved, then document these deviations in the Description property of the Application System. When there are more Application Systems involved, then it is recommended to document the deviations in a separate document. |
|
| Server Model Generation |
| OMG-10077: | If you need code control sequences, use either a central code control table (CG_CODE_CONTROLS) for all your applications or a separate code control table for each relevant table ( [table name]_CC ). |
| Rationale | The alternative is a different table for each application system where the table name is [application system
name]_CODE_CONTROLS ). Sometimes the application system name is different from the application code (see also OMS-61605), but you would want the table name to start with the application code instead of the whole application system
name. When you do not make the table name application specific, you do not get any problems if you have multiple versions of the same logical application stored in differently named physical application systems in Designer. (In that case you would have to use a work around such as temporarily renaming the application system while generating modules and code control table.) This also applies when moving to Oracle Repository (Designer 6i): When you structure your project/system into multiple containers, the question that may arise is: how would you know which container to use to give the table its name. |
| Example | Suppose you have the following application systems, which all represent a version of the same logical application system: AID_DEV AID_PROD If you would use application specific names for the code control table, you would get the table names AID_DEV_CODE_CONTROLS AID_PROD_CODE_CONTROLS depending on which application system you generate from, while the result should have been the same for all these application systems. If you choose a central code control table, for each application system you would get the same: CG_CODE_CONTROLS Also if you choose a separate code control table per relevant table, for each application you would get the same, because each application system would contain the same table name AID_INVOICES: AID_INVOICES_CC |
|
 |
Suggestion: If you decide to always use CG_CODE_CONTROLS, there are two arguments that plead for using the same table instance for all your
applications: * If you create a separate CG_CODE_CONTROLS table for each application, you might get conflicting synonym names if a user has access to multiple applications. (This can be solved through alter session set current_schema, but that makes things more complex.) * Suppose you have a database setup with a separate owner for each application and one 'super' user who has access to all applications (each application owner grants access to the 'super' user and the 'super' user has synonyms t o the application owner's objects), where users log in with either a username that is not a database user or a username which has no privileges. Once successful login is confirmed, the security system logs in with the 'super' user. In that case, on the database you must have either different names, or a single CG_CODE_CONTROLS table. You cannot have one CG_REF_CODES per application. So if the end users only have access to one application system, create CG_CODE_CONTROLS in the application owner schema and reverse engineer the table into the Designer application system. And if the end users might need access to more than one application system, create CG_CODE_CONTROLS in a central schema and let each application owner have a grant/synonym for it; reverse engineer the table to an application system for common objects and share it to the other application systems. |
 |
Generation: By default, a single table CG_CODE_CONTROLS is generated to provide unique identifiers for all modules in the application system. Alternatively, within the General Generator Options dialog box you can set the Scope Of Code Control Table Option to generate a table for a specific application system, or for a specific table. |
| OMG-10078: | If in your forms you want to display online help information in a special help form, use a central online help table (CG_FORM_HELP) for all your applications. |
| Rationale | The alternative is a different table for each application system where the table name is [application system
name]_FORM_HELP . Sometimes the application system name is different from the application code (see also OMS-61605), but you would want the table name to start with the application code instead of the whole application system name. When you do not make the table name application specific, you do not get any problems if you have multiple versions of the same logical application stored in differently named physical application systems in Designer (in that case you would have to use a work around like temporarily renaming the application system while generating modules and online help table). This also applies when moving to Oracle Repository (Designer 6i): when you structure your project/system into multiple containers, the question that may arise is: how would you know which container to use to give the table its name. Also, the standard help form (ofghlpf) attempts to locate help text in CG_FORM_HELP. If you choose the application specific table name and you intend to use ofghlpf to display help text, you must change any references to CG_FORM_HELP in ofghlpf to refer instead to the name of the table created for the application system. |
| Example | Suppose you have the following application systems, which all represent a version of the same logical application system: AID_DEV AID_PROD If you would use application specific names for the online help table, you would get the table names AID_DEV_FORM_HELP AID_PROD_FORM_HELP depending on which application system you generate from, while the result should have been the same for all these application systems. If you choose a central online help table, for each application system you would get the same: CG_FORM_HELP |
|
|
Generation: In the DBA section of the Form Generator Preferences, the preference HPTABL determines the Scope of the online help table. The options are: GENERIC (default) System wide. A single table called CG_FORM_HELP is created to hold online help text for forms generated from all the Repository application systems. APPSYS Application system wide. A table is created for each Repository application system, named [application system name]_FORM_HELP. |
|
Suggestion: If you decide to always use CG_FORM_HELP, there are two arguments that plead for using the same table instance for all your
applications: * If you create a separate CG_FORM_HELP table for each application, you might get conflicting synonym names if a user has access to multiple applications. (This can be solved through alter session set current_schema, but that makes things more complex.) * Suppose you have a database setup with a separate owner for each application and one 'super' user who has access to all applications (each application owner grants access to the 'super' user and the 'super' user has synonyms to the application owner's objects), where users log in with either a username that is not a database user or a username which has no privileges. Once successful login is confirmed, the security system logs in with the 'super' user. In that case, on the database you must have either different names, or a single CG_FORM_HELP table. You cannot have one CG_FORM_HELP per application. So if the end users only have access to one application system, create CG_FORM_HELP in the application owner schema and reverse engineer the table into the Designer application system. And if the end users might need access to more than one application system, create CG_FORM_HELP in a central schema and let each application owner have a grant/synonym for it; reverse engineer the table to an application system for common objects and share it to the other application systems. |
|
| Application Systems |
| Notes | |
 |
| OMS-61517: | Record the deletion of primary objects such as entities, modules, etc. as revision history in the Notes of the Application System. Add new entries on top. |
| Rationale | Analysts or developers might want to know what happened to the object. If this kind of information is not recorded, the person that can explain, might
not be available on the project, if at all. Putting new entries on top gives quick insight into the latest change. |
| Example | REVISION HISTORY Label Date Name Description 1.1 12-11-1999 S. Muller Removed function 31 and module ASP0050F 1.0 06-07-1998 L. Jellema Removed entity STATUS 1.1 ---- Removed function 31 and module ASP0050F because their functionality was dropped as result of tighter planning. 1.0 ---- Removed Entity STATUS, functionality now in domain STATUS |
|
|
| Business Functions |
| OMS-61637: | If a business rule function is triggered by events in more than one entity, it must be decomposed. The decomposed business rule functions must each have triggering events in only one entity. |
| Rationale | A business rule design definition can only be triggered by one table, and the Business Rule Transformer (a Headstart Utility) needs to have one business
rule function for each business rule design definition. Also, it is a good opportunity to think about way the parent rule has to be implemented, because an inter-entity rule might decompose into a change event rule, a delete rule and an inter-entity rule on one entity. |
| Example |
| Label | Short Definition | |
| Parent | BR_ORD001_IER | An order must have at least one order line |
| Child 1 | BR_ORD001A_IER | An order must have at least one order line |
| Child 2 | BR_ORD001B_DEL | Do not delete the last order line of an order, unless you also delete the order itself |
| Parent | BR_PAS002_IER | The project assignment start date must be greater than or equal to the project's start date |
| Child 1 | BR_PAS002A_IER | The project assignment start date must be greater than or equal to the project's start date |
| Child 2 | BR_PAS002B_IER | The project's start date must be less than or equal to all of its project assignment start dates |
|
Note: If one of the decomposed functions is triggered by another than the 'main' entity, it should be made into a common function. See OMS-61636. |
| Label | |
|
| OMS-61638: | Decomposed business rule functions must have a label with the same entity short name and number as their parent function. They also must include a decomposition id. |
| Rationale | This way it is obvious that they are decomposed, to which parent they belong, and of which rule type they are. |
| Example |
| Label | Short Definition | |
| Parent | BR_ORD001_IER | An order must have at least one order line |
| Child 1 | BR_ORD001A_IER | An order must have at least one order line |
| Child 2 | BR_ORD001B_DEL | Do not delete the last order line of an order, unless you also delete the order itself |
| Parent | BR_PAS002_IER | The project assignment start date must be greater than or equal to the project's start date |
| Child 1 | BR_PAS002A_IER | The project assignment start date must be greater than or equal to the project's start date |
| Child 2 | BR_PAS002B_IER | The project's start date must be less than or equal to all of its project assignment start dates |
|
Note: The decomposed business functions can have (and often do have) a different rule type and a different description. Also, if one of the decomposed functions is triggered by another than the 'main' entity, it should be made into a common function. See OMS-61636. |
| Master Function | |
|
| OMS-61636: | If you organize your business rule hierarchy by entity, and you have a decomposed business rule function that is triggered by a different entity than its parent, you have to do the following. Create another business rule function under the triggering entity branch, with the same description and with the short name of the triggering entity in its label. Make the decomposed business rule function a 'common' function of this new business rule function. Both these rules must have the same rule type in the label. |
| Rationale | If you organize your business rule hierarchy by entity, you must record all business rules related to an entity under that entity branch. It allows you
to clearly document the work associated with each entity, easily do completeness checks and communicate to the end user all rules they can run into in relation to a certain entity. The decomposed function is linked to the new rule function as a 'common' function to document that these two rules are really the same rule. The Business Rule Transformer (a Headstart Utility) ignores common functions so only the master function will get transformed into a business rule design definition. Following this standard enables the Business Rule Transformer to correctly name the rule when it creates the Design Definition. In other words, the business rule design definition will be named after the table in whose CAPI it will be implemented. |
| Example |
| Label | Short Definition | |
| Parent | BR_ORD001_IER | An order must have at least one order line |
| Child 1 | BR_ORD001A_IER | An order must have at least one order line |
| Child 2, common to BR_ORL002_DEL | BR_ORD001B_DEL | Do not delete the last order line of an order, unless you also delete the order itself |
| Master of BR_ORD001B_DEL | BR_ORL002_DEL | Do not delete the last order line of an order, unless you also delete the order itself |
| Parent | BR_PAS002_IER | The project assignment start date must be greater than or equal to the project's start date |
| Child 1 | BR_PAS002A_IER | The project assignment start date must be greater than or equal to the project's start date |
| Child 2, common to BR_PRJ003_IER | BR_PAS002B_IER | The project's start date must be less than or equal to all of its project assignment start dates |
| Master of BR_PAS002B_IER | BR_PRJ003_IER | The project's start date must be less than or equal to all of its project assignment start dates |