Designing Client Extensions
Designing your client extension is the most significant part of implementing client extensions. If you create careful, thorough design and specifications in this stage, you can expect more ease in writing the PL/SQL procedure and a more successful client extension implementation. This design cycle involves the following aspects:
Step 1. Understand the appropriate client extension, including its intended purpose, its processing flow, the predefined place that it is called, and its input values.
Each essay in this chapter describes the processing flow for a client extension. Since each client extension may be processed differently by Oracle Projects, you should carefully review the flow and additional design information we provide for each extension.
Step 2. Define and document the requirements and logic of your business rules under all possible conditions. This logic includes the required inputs, the calculations performed, and the corresponding outputs.
Step 3. Determine the data elements required to drive your rules and how you will select or derive each of the required elements. Define additional implementation data and document additional business procedures of using the system based on the requirements of your business rules.
Step 4. Step through various business scenarios to ensure that your logic handles each condition as you expect. You can use these scenarios as test cases when you test your actual client extension definition and procedure.
Step 5. Hand off detailed specification of logic to the technical resource who will write the PL/SQL procedure.
Determining Data Elements
Predefined Parameters
Oracle Projects provides predefined parameters for your use in client extensions. The program which calls and executes the client extension passes in values for the predefined parameters, which define the context of what transaction is being processed.
Derived Parameters
You can derive additional parameters from the predefined parameters. For example, a client extension may have a predefined parameter of PROJECT_ID, which is the identifier of the project. Your business rule needs project type, so you derive the project type from the PROJECT_ID.
You can also use descriptive flexfield segments to hold additional data as inputs into your rules. When you write the PL/SQL procedure, you select from the descriptive flexfield segment column which holds the appropriate input value.
You can derive data for any Oracle table as input into your rules, as long as you can derive the appropriate values based on the predefined input values passed into the PL/SQL procedure.
Example of Designing Client Extension
Let's use our earlier transaction control extension example to illustrate these design steps.
Step 1. After studying transaction control extensions, you have decided to use transaction control extensions to implement the following policy:
You can only charge supplies to overhead projects
Step 2. You define the logic for the transaction control extension as:
IF charging supplies
THEN IF charging to overhead projects
THEN OK
ELSE error message
You can only charge supplies to overhead projects
ELSE OK
Step 3. You now determine the required data elements to identify what transactions are supplies and what projects are overhead projects.
You decide that the expenditure type of Supplies specifies the type of charge, and that the project type of Overhead specifies the type of project.
The transaction control extension predefined parameters include expenditure type and project ID. You can derive the project type of the project using the project ID.
You have already defined these values as implementation data.
Project Type: Overhead
Expenditure Type: Supplies
When using these data elements, the logic for the transaction control extension is as follows:
IF Expenditure Type = Supplies
THEN IF Project Type = Overhead
THEN OK
ELSE error message
You can only charge supplies to overhead projects
ELSE OK
Step 4. You step through several scenarios of different types of charges to different types of projects. Your logic handles all of the scenarios.
Step 5. You are ready to hand off this specification to your technical resource.
