This chapter describes a set of programmatic tools (PL/SQL procedures) that you can use primarily to maintain a deployed runtime Oracle Configurator.
This chapter covers the following topics:
This chapter describes a set of programmatic tools that you can use primarily to maintain a deployed runtime Oracle Configurator. This includes:
Reference for the CZ_modelOperations_pub Package
Important: For the latest reference information on these APIs, see the Oracle Integration Repository, which is installed with your patched instance of the Oracle E-Business Suite, as described in the Preface of this guide. In the Integration Repository, the package described in this chapter can be located by using the Search function on the Internal Name CZ_MODELOPERATIONS_PUB.
Important: This chapter includes references to DHTML user interfaces, but these are temporarily retained for historical informational purposes only. As of this release, DHTML UIs are no longer supported.
For information on tools for developing a configuration model or deploying a runtime Oracle Configurator, see Programmatic Tools for Development.
The programmatic tools that you use to maintain a deployed runtime Oracle Configurator are provided in the PL/SQL package CZ_modelOperations_pub.
The CZ_modelOperations_pub package contains a set of APIs that enable you to automate day-to-day maintenance activities, thus reducing the maintenance workload. The operations covered by this are:
Importing and refreshing configuration models with data from Oracle Applications BOMs
Migrating Models to another development instance
Generation and refreshing of logic and User Interfaces
Publication of generated logic and User Interfaces
Initial execution and refreshing of Item Master Populators
Force unlocking of Models in Oracle Configurator
Force unlocking of User Interface Content Templates in Oracle Configurator
The information provided for the package CZ_CF_API in Installation of the Packages also applies to the package CZ_modelOperations_pub.
For background information and details on basic aspects of working with the PL/SQL procedures and functions in this package, see References for Working with PL/SQL Procedures and Functions in References for Working with PL/SQL Procedures and Functions, which suggests relevant topics in the Oracle Documentation Library.
Use the table below to choose the appropriate procedure or function for the task you want to perform. These procedures and functions are described in detail in Procedures and Functions in the CZ_modelOperations_pub Package.
| Area | For This Purpose ... | Use This Procedure or Function ... |
|---|---|---|
| Repository | To create a folder in the Repository, or check whether a folder exists | CREATE_RP_FOLDER RP_FOLDER_EXISTS |
| Models | To import, refresh, or migrate Models | IMPORT_SINGLE_BILL IMPORT_GENERIC MIGRATE_MODELS REFRESH_SINGLE_MODEL |
| To make a deep copy of a specified Model | DEEP_MODEL_COPY | |
| To publish or republish Models | PUBLISH_MODEL REPUBLISH_MODEL |
|
| To run Populators | EXECUTE_POPULATOR REPOPULATE |
|
| To force unlock a Model | FORCE_UNLOCK_MODEL | |
| Rules | To generate logic | GENERATE_LOGIC |
| User Interfaces | To generate or refresh a user interface | CREATE_JRAD_UI REFRESH_JRAD_UI CREATE_UI (DHTML or Java Applet UI) REFRESH_UI (DHTML or Java Applet UI) |
| To force unlock a UI Content Template | FORCE_UNLOCK_TEMPLATE |
This section contains PL/SQL queries that indicate the values you need to provide as parameters to certain procedures in the CZ_modelOperations_pub package.
You can determine the IDs of Models and folders in the Repository of Oracle Configurator Developer by customizing a View so that it displays the column DatabaseId. See the Oracle Configurator Developer User’s Guide for details on customizing Views.
You can also use a database query to list these IDs. Query for Models and Folders provides a SQL query that lists the names and IDs of source (not published) Models, and the folders that contain them in the Repository of Oracle Configurator Developer.
The ID of a Model is stored as CZ_DEVL_PROJECTS.DEVL_PROJECT_ID. This query selects a value for DEVL_PROJECT_ID. This ID can then be used as a value for the parameter p_devl_project_id or p_model_id to the following procedures:
The ID of a folder that contains a specified Model is stored as CZ_RP_ENTRIES.ENCLOSING_FOLDER. This query selects a value for ENCLOSING_FOLDER. This ID can then be used as a value for the parameter p_encl_folder_id to the following procedures:
select P.devl_project_id, P.name, R.enclosing_folder, R2.name FOLDER from cz_devl_projects P, cz_rp_entries R, cz_rp_entries R2 where R.object_type = 'PRJ' and R.deleted_flag = '0' and P.deleted_flag = '0' and P.devl_project_id = R.object_id and R2.object_id = R.enclosing_folder and R2.object_type ='FLD';
You can add the following condition to the beginning of the WHERE clause of this query to specify the name of a particular Model as it appears in Oracle Configurator Developer.
P.name like '%your Model’s name%' and
You can add the following condition to the beginning of the WHERE clause of this query to specify the name of a particular folder as it appears in Oracle Configurator Developer.
R2.name like 'your folder’s name%' and
You can determine the IDs of User Interfaces by examining the UI ID column in the User Interfaces area of the Workbench of Oracle Configurator Developer. See the Oracle Configurator Developer User’s Guide for details on customizing Views.
You can also use a database query to list these IDs. Query for User Interface IDs provides a SQL query that lists the names and IDs of available user interfaces for a specified Model. To determine the devl_project_ID for the specified Model, use the query in Query for Models and Folders.
This query selects values for the column CZ_UI_DEFS.UI_DEF_ID. This UI_DEF_ID is returned by the procedures CREATE_UI and CREATE_JRAD_UI. You would use this ID as a value for the p_ui_def_id parameter for the procedures REFRESH_UI and REFRESH_JRAD_UI.
select ui_def_id, name from cz_ui_defs where devl_project_id = devl_project_ID and deleted_flag = '0';
Query for Referenced DHTML and Java Applet User Interface IDs provides a SQL query that lists the UIs for a given Model and all referenced Models of the given Model.
Query for Referenced DHTML and Java Applet User Interface IDs provides a SQL query that lists the IDs of available referenced (child)DHTML and Java Applet user interfaces for a specified parent_ui_def_ID. To determine the parent_ui_def_ID for a specified Model, use the query in Query for User Interface IDs.
This query selects a value for the column CZ_UI_NODES.UI_DEF_ID. Use this value as a parameter for the following procedures:
Query for Referenced DHTML and Java Applet User Interface IDs
select distinct ui_def_id from cz_ui_nodes where cz_ui_nodes.deleted_flag = '0' start with ui_def_id = parent_ui_def_ID connect by prior cz_ui_nodes.ui_def_ref_id = cz_ui_nodes.ui_def_id and prior deleted_flag = '0' order by cz_ui_nodes.ui_def_id;
Query for Populators provides a SQL query that lists the names and IDs of Populators for a given Model.
To determine the devl_project_ID_for_model for the specified Model, use the query in Query for Models and Folders.
This query selects a value for the column CZ_POPULATORS.POPULATOR_ID. Use this value as a parameter for the following procedures:
select populator_id, a.name POPULATOR_NAME, b.ps_node_id, b.name from cz_populators a, cz_ps_nodes b where a.owned_by_node_id = b.ps_node_id and b.devl_project_id = devl_project_ID_for_model and a.deleted_flag = '0' and b.deleted_flag = '0';
Query for Error and Warning Information provides a SQL query that retrieves the error and warning information that is recorded in the table CZ_DB_LOGS after you run one of the following procedures:
This query selects values for the columns URGENCY, STATUSCODE, and MESSAGE from the table CZ_DB_LOGS.
URGENCY and STATUSCODE only have significant values when populated by the GENERATE_LOGIC procedure. The URGENCY values used by are 0 for errors and 1 for warnings. STATUSCODE values are not meaningful to the user but are important to the Oracle Configurator engineering team for the debugging of logic generation code.
Query for Error and Warning Information
select urgency, statuscode, message from cz_db_logs where run_id = run_ID_returned_from_procedure;
This section provides descriptions of each of the procedures in the CZ_modelOperations_pub package. These procedures are listed alphabetically in Procedures and Functions in the Package CZ_modelOperations_pub.
Descriptions of the custom data types defined in the package are also provided, in Custom Data Types.
For a basic example of how to call one of the functions in the CZ_CF_API package, see Using the GENERATE_LOGIC Procedure.
There are no custom data types defined in the CZ_modelOperations_pub package.
Oracle APIs incorporate a mechanism called API version numbers. This mechanism:
Allows an API to differentiate between changes that require you to change your API calling code and those that don't.
Allows an API to detect incompatible calls.
Allows you to quickly determine if calling a new version of an API requires you to change any of your code.
Allows you to easily figure out which version of an API you need to call to take advantage of new features.
API version numbers consist of two segments separated by a decimal point. The first segment is the major version number; the second segment is the minor version number. The starting version number for an API is always 1.0.
The following table shows an example of an API Version number and the major and minor version derived from the API version.
| API Version Number | Major Version | Minor Version |
|---|---|---|
| 1.0 | 1 | 0 |
| 2.4 | 2 | 4 |
If the major version number has changed, then you probably need to modify your programs that call that API. Major version changes include changes to the list of required parameters or changing the value of an API OUT parameter.
If only the minor version number has changed, then you probably do not need to modify your programs.
The API version number for the APIs included in the current version of the CZ_modelOperations_pub package is:
1.0
The local constant that stores this version number is:
l_api_version CONSTANT NUMBER
To detect incompatible calls, programs calling an API must pass an API version number as one of the input parameters. The API can then compare the passed version number to its current version number, and detect any incompatible calls.
The Oracle standard parameter used by all procedures in this package to pass in the API version number is:
p_api_version IN NUMBER
This parameter is required, and has no initial values, thus forcing your program to pass this parameter when calling an API.
If your call to the API results in a version incompatibility, then an error message is inserted in the table CZ_DB_LOGS. You can examine the message using a query like the one shown in Query for Error and Warning Information.
This section provides descriptions of each of the procedures and functions in the CZ_modelOperations_pub package, arranged alphabetically. These procedures and functions are listed in Procedures and Functions in the Package CZ_modelOperations_pub.
The following table lists the API procedures and functions in the CZ_modelOperations_pub package.
| API Name | P/FP = procedure, F = function |
|---|---|
| CREATE_RP_FOLDER | P |
| CREATE_UI | P |
| CREATE_JRAD_UI | P |
| DEEP_MODEL_COPY | P |
| EXECUTE_POPULATOR | P |
| FORCE_UNLOCK_MODEL | P |
| FORCE_UNLOCK_TEMPLATE | P |
| GENERATE_LOGIC | P |
| IMPORT_SINGLE_BILL | P |
| IMPORT_GENERIC | P |
| MIGRATE_MODELS | P |
| PUBLISH_MODEL | P |
| REFRESH_SINGLE_MODEL | P |
| REFRESH_UI | P |
| REFRESH_JRAD_UI | P |
| REPOPULATE | P |
| REPUBLISH_MODEL | P |
| RP_FOLDER_EXISTS | F |
The CREATE_RP_FOLDER procedure creates a new folder in the specified enclosing (parent) folder of the Repository of Oracle Configurator Developer.
If a folder with the same name already exists in the enclosing folder, then that folder’s ID is returned in the x_new_folder_id parameter. You can use the function RP_FOLDER_EXISTS to determine beforehand whether a folder exists.
See also:
None
As an alternative to using this procedure, you can create a folder in Oracle Configurator Developer, by using the Create icon in the Repository. See the Oracle Configurator Developer User’s Guide for details.
The syntax for this procedure is:
PROCEDURE create_rp_folder(p_api_version IN NUMBER
,p_encl_folder_id IN CZ_RP_ENTRIES.OBJECT_ID%TYPE
,p_new_folder_name IN CZ_RP_ENTRIES.NAME%TYPE
,p_folder_desc IN
CZ_RP_ENTRIES.DESCRIPTION%TYPE
,p_folder_notes IN CZ_RP_ENTRIES.NOTES%TYPE
,x_new_folder_id OUT NOCOPY CZ_RP_ENTRIES.OBJECT_ID%TYPE
,x_return_status OUT NOCOPY VARCHAR2
,x_msg_count OUT NOCOPY NUMBER
, OUT NOCOPY VARCHAR2
);
The following table describes the parameters for the CREATE_RP_FOLDER procedure. This includes the mode (in or out), the data type, and a brief note about the parameter.
| Parameter | Mode | Data Type | Note |
|---|---|---|---|
| p_api_version | in | number | Required. See API Version Numbers. |
| p_encl_folder_id | in | number | Required. The ID of the enclosing (parent) folder in which you are creating the new folder. To determine the ID of a folder, see Querying for Model and Folder IDs. To specify the root folder of the Repository, use the constant RP_ROOT_FOLDER. |
| p_new_folder_name | in | varchar2 | Required. The name of the new folder that you are creating. |
| p_folder_desc | in | varchar2 | A description for the new folder that you are creating |
| p_folder_notes | in | varchar2 | Notes text for the new folder that you are creating |
| x_new_folder_id | out | number | The ID of the new folder created. If a folder with the same new name already exists in the enclosing folder, the ID of that existing folder. |
| x_return_status | out | varchar2 | Either FND_API.G_RET_STS_ERROR, FND_API.G_RET_STS_SUCCESS, FND_API.G_RET_STS_UNEXP_ERROR. |
| x_msg_count | out | number | The number of error messages returned in the x_msg_data parameter. |
| x_msg_data | out | varchar2 | A string that contains any error messages. |
The CREATE_UI procedure generates a new user interface for a model. This procedure generates only legacy Configurator User Interfaces (DHTML or Java applet) of the type generated with the limited edition of Oracle Configurator Developer.
If referenced models are present, then the behavior is the following:
If a referenced model has one or more user interfaces of the input UI style (DHTML or Applet), then the root UI will refer to the last UI created with this style.
If a referenced model has no user interface, the procedure will generate a new UI for that model.
See also:
None
As an alternative to using this procedure, you can create a UI in the limited edition of Oracle Configurator Developer. For more information see the Oracle Configurator Release Notes for this release.
The syntax for this procedure is:
PROCEDURE create_ui(p_api_version IN NUMBER,
p_devl_project_id IN NUMBER,
x_ui_def_id OUT NOCOPY NUMBER,
x_run_id OUT NOCOPY NUMBER,
x_status OUT NOCOPY NUMBER,
p_ui_style IN VARCHAR2 DEFAULT 'COMPONENTS',
p_frame_allocation IN NUMBER DEFAULT 30,
p_width IN NUMBER DEFAULT 640,
p_height IN NUMBER DEFAULT 480,
p_show_all_nodes IN VARCHAR2 DEFAULT '0',
p_look_and_feel IN VARCHAR2 DEFAULT 'BLAF',
p_wizard_style IN VARCHAR2 DEFAULT '0',
p_max_bom_per_page IN NUMBER DEFAULT 10,
p_use_labels IN VARCHAR2 DEFAULT '1');
The following table describes the parameters for the CREATE_UI procedure. This includes the mode (in or out), the data type, and a brief note about the parameter.
| Parameter | Mode | Data Type | Note |
|---|---|---|---|
| p_api_version | in | number | Required. See API Version Numbers. |
| p_devl_project_id | in | number | The ID of the Model for which to create a UI. See Query for Models and Folders for a query that provides this ID (DEVL_PROJECT_ID). |
| x_ui_def_id | out | number | The ID of the UI that is created. This is stored as CZ_UI_DEFS.UI_DEF_ID. |
| x_run_id | out | number | The ID of the running of this procedure. This value is stored in CZ_DB_LOGS.RUN_ID. If there are no warnings or errors, then 0 is stored. |
| x_status | out | number | Either G_STATUS_ERROR or G_STATUS_SUCCESS. |
| p_ui_style | in | varchar2 | The style of the UI. Values are: '0' or 'COMPONENTS' for a Component Tree (DHTML) style, '3' or 'APPLET' for an Applet UI style. The default is ‘COMPONENTS’. |
| p_frame_allocation | in | number | The left-hand frame allocation for the new UI, in %. The default is 30 (30% of the screen allocated to the left-hand frame). |
| p_width | in | number | The width of the screens in the new UI, in pixels. The default is 640. |
| p_height | in | number | The height of the screens in the new UI, in pixels. The default is 480. |
| p_show_all_nodes | in | varchar2 | Controls whether the "include in generated UI" flag on Model nodes is respected. If this parameter is '1', then the new UI will include all Model nodes including those marked as "do not include in generated UI". If this parameter is '0', then the new UI will respect the "include in generated UI" flag on Model nodes. The default is ‘0’. |
| p_look_and_feel | in | varchar2 | The look and feel for the new UI. Values are: 'BLAF', 'APPLET', or 'FORMS'. The default is 'BLAF'. ’FORMS’ can only be used if p_ui_style is ’COMPONENTS’. The default is 'BLAF'. |
| p_wizard_style | in | varchar2 | Whether to generate wizard style navigation. Values are: ’0’ for No, ’1’ for Yes. The default is ’0’ (No). |
| p_max_bom_per_page | in | number | The maximum number of BOM Option Class children per screen. The default is 10. |
| p_use_labels | in | varchar2 | Indicates how to generate captions: ’0’ for description only, ’1’ for name only, ’2’, for name and description. The default is ’1’. |
The CREATE_JRAD_UI procedure generates a new User Interface for a Model. This procedure generates only User Interfaces that are based on the OA Framework. For more information on the OA Framework, see the Oracle Application Framework Documentation Resources, Release 12, on MetaLink.
See also:
None
As an alternative to using this procedure, you can create a UI in Oracle Configurator Developer, in the UI area of the Workbench. See the Oracle Configurator Developer User’s Guide for details.
The syntax for this procedure is:
PROCEDURE create_jrad_ui(p_api_version IN NUMBER,
p_devl_project_id IN NUMBER,
p_show_all_nodes IN VARCHAR2,
p_master_template_id IN NUMBER,
p_create_empty_ui IN VARCHAR2,
x_ui_def_id OUT NOCOPY NUMBER,
x_return_status OUT NOCOPY VARCHAR2,
x_msg_count OUT NOCOPY NUMBER,
OUT NOCOPY VARCHAR2);
The following table describes the parameters for the CREATE_JRAD_UI procedure. This includes the mode (in or out), the data type, and a brief note about the parameter.
| Parameter | Mode | Data Type | Note |
|---|---|---|---|
| p_api_version | in | number | Required. See API Version Numbers. |
| p_devl_project_id | in | number | The ID of the Model for which to create a UI. See Query for Models and Folders for a query that provides this ID (DEVL_PROJECT_ID). |
| p_show_all_nodes | in | varchar2 | 'Controls whether the "include in generated UI" flag on Model nodes is respected. If this parameter is '1', then the new UI will include all Model nodes including those marked as "do not include in generated UI". If this parameter is '0', then the new UI will respect the "include in generated UI" flag on Model nodes.The default is ‘0’. |
| p_master_template_id | in | number | You can determine the IDs of UI master Templates in the Repository of Oracle Configurator Developer by customizing a View so that it displays the column DatabaseId. See the Oracle Configurator Developer User’s Guide for details on customizing Views. |
| p_create_empty_ui | in | varchar2 | If this parameter is '1', then the new UI will be an "empty" UI. See the Oracle Configurator Developer User’s Guide for details on empty UIs. |
| x_ui_def_id | out | number | The ID of the UI that is created. This is stored as CZ_UI_DEFS.UI_DEF_ID. |
| x_return_status | out | varchar2 | Either FND_API.G_RET_STS_ERROR, FND_API.G_RET_STS_SUCCESS, FND_API.G_RET_STS_UNEXP_ERROR |
| x_msg_count | out | number | The number of error messages returned in the x_msg_data parameter. |
| x_msg_data | out | varchar2 | A string that contains any error messages. |
The DEEP_MODEL_COPY procedure performs a deep copy of a specified Model.
Deep copying creates a new copy of the specified Model, along with new copies of any referenced Models. You can choose to copy the Model without its configuration rules, user interfaces, or referenced child Models.
None
As an alternative to using this procedure, you can perform a deep copy of a Model in Oracle Configurator Developer, by using the Copy command in the Repository. See the Oracle Configurator Developer User’s Guide for details.
The syntax for this procedure is:
PROCEDURE deep_model_copy(p_api_version IN NUMBER,
p_devl_project_id IN NUMBER,
p_folder IN NUMBER,
p_copy_rules IN NUMBER,
p_copy_uis IN NUMBER,
p_copy_root IN NUMBER,
x_devl_project_id OUT NOCOPY NUMBER,
x_run_id OUT NOCOPY NUMBER,
x_status OUT NOCOPY NUMBER);
The table Parameters for the DEEP_MODEL_COPY Procedure describes the parameters for the DEEP_MODEL_COPY procedure. This includes mode (in or out), the data type, and a brief note about the parameter.
| Parameter | Mode | Data Type | Note |
|---|---|---|---|
| p_api_version | in | number | Required. See API Version Numbers. |
| p_devl_project_id | in | number | The ID of the Model of which a copy is to be made. See Query for Models and Folders for a query that provides this ID (DEVL_PROJECT_ID). |
| p_folder | in | number | The folder to which the copy is made. See Query for Models and Folders for a query that provides this number (ENCLOSING_FOLDER). |
| p_copy_rules | in | number | Set to 1 to copy configuration rules with the model, 0 to omit the rules. |
| p_copy_uis | in | number | Set to 1 to copy user interfaces with the model, 0 to omit the user interfaces. |
| p_copy_root | in | number | Set to 1 to copy only the root model, 0 to copy all referenced models. |
| x_devl_project_id | out | number | The ID (DEVL_PROJECT_ID) of the Model created by the copying operation. |
| x_run_id | out | number | The ID of the running of this procedure. This value is stored in CZ_DB_LOGS.RUN_ID. |
| x_status | out | number | Either G_STATUS_ERROR or G_STATUS_SUCCESS. |
The EXECUTE_POPULATOR procedure can be used to refresh the CZ_PS_NODES table by implementing a Populator.
A Populator is a mechanism that automatically builds Model structure from data in the Item Master. See the Oracle Configurator Developer User’s Guide for more details on Populators.
The CZ_PS_NODES table in the CZ schema describes the structure of the generated logic.
See the description of REPOPULATE for information on the related procedure for repopulating Model structure.
Before running the EXECUTE_POPULATOR procedure, you must first run fnd_global.APPS_INITIALIZE procedure. This procedure sets up global variables and profile values in a database session. Call this procedure to initialize the global security context for a database session.
As an alternative to using this procedure, you can define and run a Populator using Oracle Configurator Developer. See the Oracle Configurator Developer User’s Guide for instructions on using Populators.
Another alternative to using this procedure is to run the Execute Populators in Model concurrent program. See Execute Populators in Model Concurrent Program for details on running this concurrent program.
The syntax for this procedure is:
PROCEDURE execute_populator(p_api_version IN NUMBER,
p_populator_id IN NUMBER,
p_imp_run_id IN OUT NOCOPY VARCHAR2,
x_run_id OUT NOCOPY NUMBER,
x_status OUT NOCOPY NUMBER);
The following table describes the parameters for the EXECUTE_POPULATOR procedure. This includes mode (in or out), the data type, and a brief note about the parameter.
| Parameter | Mode | Data Type | Note |
|---|---|---|---|
| p_api_version | in | number | Required. See API Version Numbers. |
| p_populator_id | in | number | The value of CZ_POPULATORS.POPULATOR_ID for the Populator to be used. |
| p_imp_run_id | in/out | varchar2 | Stored in CZ_IMP_PS_NODES.RUN_ID. |
| x_run_id | out | number | The ID of the running of this procedure. This value is stored in CZ_DB_LOGS.RUN_ID. If there are no warnings or errors, then 0 is stored. |
| x_status | out | number | Either G_STATUS_ERROR or G_STATUS_SUCCESS. |
The FORCE_UNLOCK_MODEL procedure unlocks one or more Models according to user-defined criteria.
Model locking provides a mechanism that protects multiple users from modifying the same Model at the same time. The FORCE_UNLOCK_MODEL procedure only works when it is run as the user who has access to the force unlock functionality. See the Oracle Configurator Developer User’s Guide for more information on Model locking.
Before running the FORCE_UNLOCK_MODEL procedure, you must first run fnd_global.APPS_INITIALIZE procedure. This procedure sets up global variables and profile values in a database session. Call this procedure to initialize the global security context for a database session.
As an alternative to using this procedure, the Oracle Configurator Administrator can unlock any object that is locked by another user. See the Oracle Configurator Developer User’s Guide for more information on force unlocking.
The syntax for this procedure is:
PROCEDURE force_unlock_model(p_api_version IN NUMBER,
p_model_id IN NUMBER,
p_unlock_references IN VARCHAR2,
p_init_msg_list IN VARCHAR2,
x_return_status OUT NOCOPY VARCHAR2,
x_msg_count OUT NOCOPY NUMBER,
x_msg_data OUT NOCOPY VARCHAR2);
The following table describes the parameters for the FORCE_UNLOCK_MODEL procedure. This includes mode (in or out), the data type, and a brief note about the parameter.
| Parameter | Mode | Data Type | Note |
|---|---|---|---|
| p_api_version | in | number | Required. See API Version Numbers. |
| p_model_id | in | number | Required. The value of CZ_DEVL_PROJECTS.MODEL_ID for the Model to be unlocked. |
| p_unlock_references | in | varchar2 | Controls whether to unlock just the Model or to unlock the Model and the entire tree of referenced Models. The values are FND_API.G_TRUE or FND_API.G_FALSE If this parameter is FND_API.G_FALSE, then the just the Model is unlocked. The default is FND_API.G_FALSE. |
| p_init_msg_list | in | varchar2 | Either FND_API.G_TRUE if the FND stack should be initialized, or FND_API.G_FALSE if the FND stack should not be initialized. |
| x_return_status | out | varchar2 | Either FND_API.G_RET_STS_ERROR, FND_API.G_RET_STS_SUCCESS, FND_API.G_RET_STS_UNEXP_ERROR. |
| x_msg_count | out | number | The number of error messages that are available on the FND error stack after the completion of the procedure. |
| x_msg_data | out | varchar2 | A string that contains any error messages. |
The FORCE_UNLOCK_TEMPLATE procedure unlocks a UI Content Template.
Locking UI Content Templates provides a mechanism that protects multiple users from modifying the same UI Content Template at the same time. The FORCE_UNLOCK_TEMPLATE API only works when it is run as the user who has access to the force unlock functionality. See the Oracle Configurator Developer User’s Guide for more information on UI Content Template locking.
Before running the FORCE_UNLOCK_TEMPLATE procedure, you must first run fnd_global.APPS_INITIALIZE procedure. This procedure sets up global variables and profile values in a database session. Call this procedure to initialize the global security context for a database session.
As an alternative to using this procedure, the Oracle Configurator Administrator can unlock any object that is locked by another user. See the Oracle Configurator Developer User’s Guide for more information on force unlocking.
The syntax for this procedure is:
PROCEDURE force_unlock_template(p_api_version IN NUMBER,
p_template_id IN NUMBER,
p_init_msg_list IN VARCHAR2,
x_return_status OUT NOCOPY VARCHAR2,
x_msg_count OUT NOCOPY NUMBER,
x_msg_data OUT NOCOPY VARCHAR2);
The following table describes the parameters for the FORCE_UNLOCK_TEMPLATE procedure. This includes mode (in or out), the data type, and a brief note about the parameter.
| Parameter | Mode | Data Type | Note |
|---|---|---|---|
| p_api_version | in | number | Required. See API Version Numbers. |
| p_template_id | in | number | Required. The value of CZ_UI_TEMPLATES.TEMPLATE_ID for the UI Content Template to be unlocked. |
| p_init_msg_list | in | varchar2 | Either FND_API.G_TRUE if the FND stack should be initialized, or FND_API.G_FALSE if the FND stack should not be initialized. |
| x_return_status | out | varchar2 | Either FND_API.G_RET_STS_ERROR, FND_API.G_RET_STS_SUCCESS, FND_API.G_RET_STS_UNEXP_ERROR. |
| x_msg_count | out | number | The number of error messages that are available on the FND error stack after the completion of the procedure. |
| x_msg_data | out | varchar2 | A string that contains any error messages. |
The GENERATE_LOGIC procedure generates the logic for a Model and all of its referenced Models if necessary.
Before running the GENERATE_LOGIC procedure, you must first run fnd_global.APPS_INITIALIZE procedure. This procedure sets up global variables and profile values in a database session. Call this procedure to initialize the global security context for a database session.
As an alternative to using this procedure, you can generate logic in Oracle Configurator Developer, in the General area of the Workbench. See the Oracle Configurator Developer User’s Guide for details.
The syntax for this procedure is:
PROCEDURE generate_logic(p_api_version IN NUMBER,
p_devl_project_id IN NUMBER,
x_run_id OUT NOCOPY NUMBER,
x_status OUT NOCOPY NUMBER);
The following table describes the parameters for the GENERATE_LOGIC procedure. This includes mode (in or out), the data type, and a brief note about the parameter.
| Parameter | Mode | Data Type | Note |
|---|---|---|---|
| p_api_version | in | number | Required. See API Version Numbers. |
| p_devl_project_id | in | number | The ID of the Model for which to generate logic. See Query for Models and Folders for a query that provides this ID (DEVL_PROJECT_ID). |
| x_run_id | out | number | The ID of the running of this procedure. This value is stored in CZ_DB_LOGS.RUN_ID. If there are no warnings or errors, then 0 is stored. |
| x_status | out | number | Either G_STATUS_ERROR, G_STATUS_WARNING, or G_STATUS_SUCCESS. |
When called in SQL*Plus, this example generates logic for a model with the ID (DEVL_PROJECT_ID) specified by the p_devl_project_id parameter. After the procedure runs, it prints the run ID and status.
Using the GENERATE_LOGIC Procedure
set serveroutput on
declare
x_run_id number;
x_status varchar2(100);
begin
CZ_modelOperations_pub.generate_logic(1.0,12345,x_run_id,x_status);
dbms_output.put_line('Run id: '||x_run_id);
dbms_output.put_line('x_status: '||x_status);
end;
The IMPORT_SINGLE_BILL procedure can be used to import a model from Oracle Bills of Materials (BOM).
See also:
Before running the IMPORT_SINGLE_BILL procedure, you must first run fnd_global.APPS_INITIALIZE procedure. This procedure sets up global variables and profile values in a database session. Call this procedure to initialize the global security context for a database session.
As an alternative to using this procedure, you can run the Populate Configuration Models concurrent program. See Populate and Refresh Configuration Models Concurrent Programs program for details.
The syntax for this procedure is:
PROCEDURE import_single_bill(p_api_version IN NUMBER,
p_org_id IN NUMBER,
p_top_inv_item_id IN NUMBER,
x_run_id OUT NOCOPY NUMBER,
x_status OUT NOCOPY NUMBER);
The following table describes the parameters for the IMPORT_SINGLE_BILL procedure. This includes mode (in or out), the data type, and a brief note about the parameter.
| Parameter | Mode | Data Type | Note |
|---|---|---|---|
| p_api_version | in | number | Required. See API Version Numbers. |
| p_org_id | in | number | Required. The organization ID of the bill to be imported. |
| p_top_inv_item_id | in | number | The Inventory Item ID of the top item to be imported (the BOM root). |
| x_run_id | out | number | The ID of the running of this procedure. This value is stored in CZ_DB_LOGS.RUN_ID. |
| x_status | out | number | Either G_STATUS_ERROR or G_STATUS_SUCCESS. |
The IMPORT_GENERIC procedure processes and imports data from the CZ interface tables as part of a custom import. See Custom Import for details about custom (generic) import.
See also:
Before running the IMPORT_GENERIC procedure, you must first run fnd_global.APPS_INITIALIZE procedure. This procedure sets up global variables and profile values in a database session. Call this procedure to initialize the global security context for a database session.
As an alternative to using this procedure, you can run the Populate Configuration Models concurrent program. See Populate and Refresh Configuration Models Concurrent Programs program for details.
The syntax for this procedure is:
PROCEDURE import_generic(p_api_version IN NUMBER
,p_run_id IN NUMBER
,p_rp_folder_id IN NUMBER
,x_run_id OUT NOCOPY NUMBER
,x_status OUT NOCOPY NUMBER);
The following table describes the parameters for the IMPORT_GENERIC procedure. This includes mode (in or out), the data type, and a brief note about the parameter.
| Parameter | Mode | Data Type | Note |
|---|---|---|---|
| p_api_version | in | number | Required. See API Version Numbers. |
| p_run_id | in | number | Required. The Run ID generated by previously populating the import (CZ_IMP_*) tables. Specify the ID of the records that you want to process during a particular generic import session. If this ID is NULL, then all the records in the import tables where run_id is NULL will be processed. You should obtain the Run ID from the sequence CZ_XFR_RUN_INFOS_S, to avoid possible conflicts with the IMPORT_SINGLE_BILL procedure. |
| p_rp_folder_id | in | number | Required. The ID of the folder in the Repository into which you want to import the Model. To determine the ID of a folder, see Querying for Model and Folder IDs. To specify the root folder of the Repository, use the constant RP_ROOT_FOLDER. |
| x_run_id | out | number | The ID of the running of this procedure. This value is stored in CZ_DB_LOGS.RUN_ID. If there are no warnings or errors, then 0 is stored. Used to get results from CZ_XFR_RUN_INFOS and CZ_XFR_RUN_RESULTS. |
| x_status | out | number | Either G_STATUS_ERROR, G_STATUS_SUCCESS, or G_STATUS_WARNING. |
After a publication record is created in Oracle Configurator Developer, the PUBLISH_MODEL procedure exports the publication to the target database (that is, Model and UI data).
Before running the PUBLISH_MODEL procedure, you must first run fnd_global.APPS_INITIALIZE procedure. This procedure sets up global variables and profile values in a database session. Call this procedure to initialize the global security context for a database session.
This procedure should only be run on publications with a status of Pending.
As an alternative to using this procedure, you can publish models in Oracle Configurator Developer in the Publications area of the Repository. See the Oracle Configurator Developer User’s Guide for details.
The syntax for this procedure is:
PROCEDURE publish_model(p_api_version IN NUMBER,
p_publication_id IN NUMBER,
x_run_id OUT NOCOPY NUMBER,
x_status OUT NOCOPY NUMBER);
The following table describes the parameters for the PUBLISH_MODEL procedure. This includes mode (in or out), the data type, and a brief note about the parameter.
| Parameter | Mode | Data Type | Note |
|---|---|---|---|
| p_api_version | in | number | Required. See API Version Numbers. |
| p_publication_id | in | number | The publication ID generated when you publish a model in Oracle Configurator Developer , stored as CZ_MODEL_PUBLICATIONS.PUBLICATION_ID. |
| x_run_id | out | number | The ID of the running of this procedure. This value is stored in CZ_DB_LOGS.RUN_ID. |
| x_status | out | number | Either G_STATUS_ERROR or G_STATUS_SUCCESS. |
The MIGRATE_MODELS procedure copies the model's structure, rules, UIs, UI Content Templates, UI Master Templates, Usages, Effectivity Sets, Configurator Extension Archives, Populators, corresponding Item Master, and Properties to another development instance.
None
None
As an alternative to using this procedure, you can migrate Models from Oracle Configurator Developer .. See the Oracle Configurator Developer User’s Guide for details.
The syntax for this procedure is:
PROCEDURE migrate_models(p_api_version IN NUMBER,
p_model_list_tab IN cz_pb_mgr.t_ref,
p_tgt_instance_id IN cz_servers.server_local_id%TYPE,
p_tgt_folder_id IN cz_rp_entries.object_id%TYPE,
p_enable_shallow IN VARCHAR2,
p_user_id IN NUMBER,
p_resp_id IN NUMBER,
p_appl_id IN NUMBER,
p_run_id IN NUMBER,
x_run_id OUT NOCOPY NUMBER,
x_return_status OUT NOCOPY VARCHAR2,
x_msg_count OUT NOCOPY NUMBER,
x_msg_data OUT NOCOPY VARCHAR2
)
;
The following table describes the parameters for the MIGRATE_MODELS procedure. This includes mode (in or out), the data type, and a brief note about the parameter.
| Parameter | Mode | Data Type | Note |
|---|---|---|---|
| p_model_list_tab | in | number | Table of numbers that contains a list of all Models selected for migration from the source instance.. |
| p_tgt_instance_id | in | number | Identifies the database instance where the Models will be migrated. |
| p_tgt_folder_id | in | number | Identifies the remote Repository folder where the Models are migrated. This is the object_id in the target's cz_rp_entries table. |
| p_userid p_respid p_applid |
in | number | Standard parameters required for locking. |
| p_run_id | in | number | Identifies the session. If this is Null, then the procedure generates a number and returns it in x_run_id. |
| x_run_id | out | number | The ID of the running of this procedure. This value is stored in CZ_DB_LOGS.RUN_ID. |
| x_status | out | number | Either G_STATUS_ERROR or G_STATUS_SUCCESS. |
The REFRESH_SINGLE_MODEL procedure can be used to refresh a model imported from Oracle Bills of Materials (BOM).
Before running the REFRESH_SINGLE_MODEL procedure, you must first run fnd_global.APPS_INITIALIZE procedure. This procedure sets up global variables and profile values in a database session. Call this procedure to initialize the global security context for a database session.
The syntax for this procedure is:
PROCEDURE refresh_single_model(p_api_version IN NUMBER,
p_devl_project_id IN VARCHAR2,
x_run_id OUT NOCOPY NUMBER,
x_status OUT NOCOPY NUMBER);
The following table describes the parameters for the REFRESH_SINGLE_MODEL procedure. This includes mode (in or out), the data type, and a brief note about the parameter.
| Parameter | Mode | Data Type | Note |
|---|---|---|---|
| p_api_version | in | number | Required. See API Version Numbers. |
| p_devl_project_id | in | varchar2 | Required. The ID of the Model for which to refresh imported data. See Query for Models and Folders for a query that provides this ID (DEVL_PROJECT_ID). |
| x_run_id | out | number | The ID of the running of this procedure. This value is stored in CZ_DB_LOGS.RUN_ID. |
| x_status | out | number | Either G_STATUS_ERROR or G_STATUS_SUCCESS. |
The REFRESH_UI procedure refreshes an existing user interface based on the current model data. This procedure operates only on legacy Configurator User Interfaces (DHTML or Java applet) of the type generated with the limited edition of Oracle Configurator Developer.
See also:
Before running the REFRESH_UI procedure, you must first run fnd_global.APPS_INITIALIZE procedure. This procedure sets up global variables and profile values in a database session. Call this procedure to initialize the global security context for a database session.
This procedure only refreshes the UI specified. Referenced user interfaces are not refreshed if the specified UI is DHTML. If the referenced UI is one that is based on the OA Framework, then referenced user interfaces are refreshed.
As an alternative to using this procedure, you can refresh a UI in the limited edition of Oracle Configurator Developer. For more information see the Oracle Configurator Release Notes for this release.
The syntax for this procedure is:
PROCEDURE (p_api_version IN NUMBER,
p_ui_def_id IN OUT NOCOPY NUMBER,
x_run_id OUT NOCOPY NUMBER,
x_status OUT NOCOPY NUMBER);
The following table describes the parameters for the REFRESH_UI procedure. This includes mode (in or out), the data type, and a brief note about the parameter.
| Parameter | Mode | Data Type | Note |
|---|---|---|---|
| p_api_version | in | number | Required. See API Version Numbers. |
| p_ui_def_id | in/out | number | UI definition ID of user interface to be refreshed. If user interface is Applet style, then a new ui_def_id is returned through this parameter. If the style is DHTML, then the same ui_def_id is returned. |
| x_run_id | out | number | The ID of the running of this procedure. This value is stored in CZ_DB_LOGS.RUN_ID. If there are no warnings or errors, then 0 is stored. |
| x_status | out | number | Either G_STATUS_ERROR, G_STATUS_WARNING or G_STATUS_SUCCESS. |
The REFRESH_JRAD_UI procedure refreshes an existing user interface based on the current Model data. This procedure generates only User Interfaces based on the OA Framework. For more information on the OA Framework, see the Oracle Application Framework Documentation Resources, Release 12, on MetaLink.
See also:
None
As an alternative to using this procedure, you can refresh a UI in Oracle Configurator Developer, in the User Interface area of the Workbench. See the Oracle Configurator Developer User’s Guide for details.
The syntax for this procedure is:
PROCEDURE refresh_jrad_ui(p_api_version IN NUMBER,
p_ui_def_id IN OUT NOCOPY NUMBER,
x_return_status OUT NOCOPY VARCHAR2,
x_msg_count OUT NOCOPY NUMBER,
OUT NOCOPY VARCHAR2);
The following table describes the parameters for the REFRESH_JRAD_UI procedure. This includes mode (in or out), the data type, and a brief note about the parameter.
| Parameter | Mode | Data Type | Note |
|---|---|---|---|
| p_api_version | in | number | Required. See API Version Numbers. |
| p_ui_def_id | in/out | number | Identifies the UI to refresh |
| x_return_status | out | varchar2 | Either G_STATUS_ERROR, G_STATUS_SUCCESS, or G_STATUS_WARNING. |
| x_msg_count | out | number | The number of error messages returned in the x_msg_data parameter. |
| x_msg_data | out | varchar2 | A string that contains any error messages. |
The REPOPULATE procedure iterates through all Populators associated with the input model and repopulates them.
Before running the REPOPULATE procedure, you must first run fnd_global.APPS_INITIALIZE procedure. This procedure sets up global variables and profile values in a database session. Call this procedure to initialize the global security context for a database session.
As an alternative to using this procedure, you can repopulate the Model with current data when data in the Item Master changes in Oracle Configurator Developer. See the Oracle Configurator Developer User's Guide for details.
The syntax for this procedure is:
PROCEDURE repopulate(p_api_version IN NUMBER,
p_devl_project_id IN NUMBER,
p_regenerate_all IN VARCHAR2 , -- DEFAULT '1',
p_handle_invalid IN VARCHAR2 , -- DEFAULT '1',
p_handle_broken IN VARCHAR2 , -- DEFAULT '1',
x_run_id OUT NOCOPY NUMBER,
x_status OUT NOCOPY NUMBER);
The following table describes the parameters for the REPOPULATE procedure. This includes mode (in or out), the data type, and a brief note about the parameter.
| Parameter | Mode | Data Type | Note |
|---|---|---|---|
| p_api_version | in | number | Required. See API Version Numbers. |
| p_devl_project_id | in | number | The ID of the Model to repopulate. See Query for Models and Folders for a query that provides this ID (DEVL_PROJECT_ID). |
| p_regenerate_all | in | varchar2 | Set to 0 if all Populators should be regenerated unconditionally before execution. Set to 1 to regenerate only modified Populators. The default is 1. |
| p_handle_invalid | in | varchar2 | Allows caller to specify how to handle invalid Populators. Pass 0 to skip invalid Populators, or pass 1 to regenerate them. The default is 1. |
| p_handle_broken | in | varchar2 | Allows caller to specify whether to continue (1) or not (0) when a Populator cannot be regenerated successfully. The default is 1. |
| x_run_id | out | number | The ID of the running of this procedure. This value is stored in CZ_DB_LOGS.RUN_ID. If there are no warnings or errors, then 0 is stored. |
| x_status | out | number | Either G_STATUS_ERROR or G_STATUS_SUCCESS. |
The REPUBLISH_MODEL procedure is the server side API to create a publication request and republish the model.
Only valid publications can be republished. A valid publication’s DELETED_FLAG=0, STATUS=OK, and SOURCE_TARGET_FLAG=S.
Possible reasons for the REPUBLISH_MODEL procedure to fail, are:
Input dates were not valid for the p_publication_id
There is an overlap with existing publications for the same Model
The Model was regenerated and the UI was refreshed
If the validation fails for any reason, the error messages are logged in CZ_DB_LOGS.
Before running the REPUBLISH_MODEL procedure, you must first run fnd_global.APPS_INITIALIZE procedure. This procedure sets up global variables and profile values in a database session. Call this procedure to initialize the global security context for a database session.
As an alternative to using this procedure, you can republish an existing model in Oracle Configurator Developer in the Publications area of the Repository. See the Oracle Configurator Developer User’s Guide for details.
The syntax for this procedure is:
PROCEDURE republish_model(p_api_version IN NUMBER,
p_publication_id IN NUMBER,
p_start_date IN DATE,
p_end_date IN DATE,
x_run_id OUT NOCOPY NUMBER,
x_status OUT NOCOPY NUMBER);
The following table describes the parameters for the REPUBLISH_MODEL procedure. This includes mode (in or out), the data type, and a brief note about the parameter.
| Parameter | Mode | Data Type | Note |
|---|---|---|---|
| p_api_version | in | number | Required. See API Version Numbers. |
| p_publication_id | in | number | Required. This is the ID of the publication that is being republished. |
| p_start_datel | in | date | This is the start date of the original publication. |
| p_end_date | in | date | This is the end date of the original publication. |
| x_run_id | out | number | The ID of the running of this procedure. This value is stored in CZ_DB_LOGS.RUN_ID. If there are no warnings or errors, then 0 is stored. |
| x_status | out | number | Either G_STATUS_ERROR, G_STATUS_SUCCESS, or G_STATUS_WARNING. |
The RP_FOLDER_EXISTS function checks whether a specified folder already exists in the Repository of Oracle Configurator Developer. You can use this function before you use CREATE_RP_FOLDER, to avoid trying to create a folder with a conflicting name.
This function returns the values listed in the tableValues Returned by RP_FOLDER_EXISTS, given the conditions shown.
| Enclosing folder (p_encl_folder_id) | Target folder (p_rp_folder) | Function Returns ... |
|---|---|---|
| Null | Exists anywhere in the Repository | TRUE |
| Not null and exists anywhere in the Repository | Exists inside enclosing folder. | TRUE |
| Null | Does not exist anywhere in the Repository | FALSE |
| Not null and does not exist anywhere in the Repository | N/A | FALSE |
| Not null | Does not exist inside enclosing folder. | FALSE |
See also:
None
As an alternative to using this procedure, you can search for the target folder in Oracle Configurator Developer, by expanding some or all folders in the Repository. See the Oracle Configurator Developer User’s Guide for details.
The syntax for this function is:
FUNCTION rp_folder_exists (p_api_version IN NUMBER
,p_encl_folder_id IN NUMBER
,p_rp_folder_id IN NUMBER) RETURN BOOLEAN;
The following table describes the parameters for the RP_FOLDER_EXISTS function. This includes mode (in or out), the data type, and a brief note about the parameter.
| Parameter | Mode | Data Type | Note |
|---|---|---|---|
| p_api_version | in | number | Required. See API Version Numbers. |
| p_encl_folder_id | in | number | Required. The ID of the enclosing (parent) folder containing the target folder name. To determine the ID of a folder, see Querying for Model and Folder IDs. To specify the root folder of the Repository, use the constant RP_ROOT_FOLDER. |
| p_rp_folder_id | in | number | Required. The ID of the folder that is the target of your search. To determine the ID of a folder, see Querying for Model and Folder IDs. |