Programmatic Tools for Maintenance

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:

Overview

This chapter describes a set of programmatic tools that you can use primarily to maintain a deployed runtime Oracle Configurator. This includes:

For information on tools for developing a configuration model or deploying a runtime Oracle Configurator, see Programmatic Tools for Development.

Overview of the CZ_modelOperations_pub Package

The programmatic tools that you use to maintain a deployed runtime Oracle Configurator are provided in the PL/SQL package CZ_modelOperations_pub.

Purpose of the Package

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:

Installation of the Package

The information provided for the package CZ_CF_API in Installation of the Packages also applies to the package CZ_modelOperations_pub.

References for Working with PL/SQL Procedures and Functions

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.

Choosing the Right Tool for the Job

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.

Uses of 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

Queries to Support the CZ_modelOperations_pub Package

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.

Querying for Model and Folder IDs

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:

Query for Models and Folders

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

Querying for User Interface IDs

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.

Query for User Interface IDs

select 
  ui_def_id, 
  name 
from 
  cz_ui_defs 
where 
  devl_project_id = devl_project_ID 
and
  deleted_flag = '0';

Querying for Referenced User Interface IDs

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; 

Querying for Populators

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:

Query for Populators

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';

Querying for Error and Warning Information

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; 

Reference for the CZ_modelOperations_pub Package

Custom Data Types

There are no custom data types defined in the CZ_modelOperations_pub package.

API Version Numbers

Oracle APIs incorporate a mechanism called API version numbers. This mechanism:

Format of API Version Numbers

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.

Current API Version Number for This Package

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

Checking for Incompatible API Calls

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.

Procedures and Functions in the CZ_modelOperations_pub Package

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.

Procedures and Functions in the Package CZ_modelOperations_pub
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

CREATE_RP_FOLDER

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:

Considerations Before Running

None

Alternatives

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.

Syntax and Parameters

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.

Parameters for the CREATE_RP_FOLDER Procedure
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.

CREATE_UI

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:

  1. 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.

  2. If a referenced model has no user interface, the procedure will generate a new UI for that model.

See also:

Considerations Before Running

None

Alternatives

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.

Syntax and Parameters

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.

Parameters for the CREATE_UI Procedure
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’.

CREATE_JRAD_UI

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:

Considerations Before Running

None

Alternatives

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.

Syntax and Parameters

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.

Parameters for the CREATE_JRAD_UI Procedure
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.

DEEP_MODEL_COPY

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.

Considerations Before Running

None

Alternatives

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.

Syntax and Parameters

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.

Parameters for the DEEP_MODEL_COPY Procedure
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.

EXECUTE_POPULATOR

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.

Considerations Before Running

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.

Alternatives

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.

Syntax and Parameters

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.

Parameters for the EXECUTE_POPULATOR Procedure
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.

FORCE_UNLOCK_MODEL

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.

Considerations Before Running

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.

Alternatives

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.

Syntax and Parameters

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.

Parameters for the FORCE_UNLOCK_MODEL Procedure
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.

FORCE_UNLOCK_TEMPLATE

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.

Considerations Before Running

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.

Alternatives

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.

Syntax and Parameters

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.

Parameters for the FORCE_UNLOCK_TEMPLATE Procedure
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.

GENERATE_LOGIC

The GENERATE_LOGIC procedure generates the logic for a Model and all of its referenced Models if necessary.

Considerations Before Running

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.

Alternatives

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.

Syntax and Parameters

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.

Parameters for the GENERATE_LOGIC Procedure
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.

Example

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;

IMPORT_SINGLE_BILL

The IMPORT_SINGLE_BILL procedure can be used to import a model from Oracle Bills of Materials (BOM).

See also:

Considerations Before Running

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.

Alternatives

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.

Syntax and Parameters

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.

Parameters for the IMPORT_SINGLE_BILL Procedure
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.

IMPORT_GENERIC

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:

Considerations Before Running

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.

Alternatives

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.

Syntax and Parameters

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.

Parameters for the IMPORT_GENERIC Procedure
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.

PUBLISH_MODEL

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).

Considerations Before Running

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.

Restrictions and Limitations

This procedure should only be run on publications with a status of Pending.

Alternatives

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.

Syntax and Parameters

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.

Parameters for the PUBLISH_MODEL Procedure
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.

MIGRATE_MODELS

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.

Considerations Before Running

None

Restrictions and Limitations

None

Alternatives

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.

Syntax and Parameters

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.

Parameters for the MIGRATE_MODELS Procedure
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.

REFRESH_SINGLE_MODEL

The REFRESH_SINGLE_MODEL procedure can be used to refresh a model imported from Oracle Bills of Materials (BOM).

Considerations Before Running

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.

Syntax and Parameters

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.

Parameters for the REFRESH_SINGLE_MODEL Procedure
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.

REFRESH_UI

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:

Considerations Before Running

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.

Restrictions and Limitations

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.

Alternatives

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.

Syntax and Parameters

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.

Parameters for the REFRESH_UI Procedure
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.

REFRESH_JRAD_UI

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:

Considerations Before Running

None

Alternatives

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.

Syntax and Parameters

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.

Parameters for the REFRESH_JRAD_UI Procedure
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.

REPOPULATE

The REPOPULATE procedure iterates through all Populators associated with the input model and repopulates them.

Considerations Before Running

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.

Alternatives

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.

Syntax and Parameters

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.

Parameters for the REPOPULATE Procedure
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.

REPUBLISH_MODEL

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:

If the validation fails for any reason, the error messages are logged in CZ_DB_LOGS.

Considerations Before Running

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.

Alternatives

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.

Syntax and Parameters

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.

Parameters for the REPUBLISH_MODEL Procedure
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.

RP_FOLDER_EXISTS

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.

Values Returned by RP_FOLDER_EXISTS
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:

Considerations Before Running

None

Alternatives

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.

Syntax and Parameters

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.

Parameters for the RP_FOLDER_EXISTS Function
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.