Oracle Configurator CIO and dependent jar files

Here are the some of the jar files required to build Configurator CX extensions and few other test cases around that.

It contains old com.sun.java.util.collections jar along with JDBC, FND, OC4J and other related jars. Its link to dropbox. These jars are from Oracle applications 12.1.x version.

Although these files are here for reference purpose, its always good to get them from your instance where you are going to deploy your changes. You can get all of the following classes from $JAVA_TOP directory on instance middle-tier.

UPDATE: Link to jar file is removed now. Jar file can be created with following commands from middletier unix box.

bash>cd $JAVA_TOP
bash>jar cvf oracle.apps.cz.jar oracle/apps/cz
bash>jar cvf oracle.apps.fnd.jar oracle/apps/fnd

Update Java Extension ClassName for Configurator CX rules using query

Following query will update the java classname (from xxcz.cx.MyOldClass to xxcz.cx.MyNewClass ) for all the models which are under repository folder name 'Models - In Process'

UPDATE cz_rules ru
SET ru.class_name        = 'xxcz.cx.MyNewClass'
WHERE exists(SELECT
  rpf.name folder_name,
  p.name model_name,
  p.devl_project_id,
  r.name rule_name,
  r.rule_id,
  r.class_name
FROM cz_rules r,
  cz_devl_projects p,
  cz_rp_entries rpp,
  cz_rp_entries rpf
WHERE r.devl_project_id=p.devl_project_id
AND r.rule_type = 300 -- CX rules
AND rpp.object_id       =p.devl_project_id
and rpp.enclosing_folder = rpf.object_id
AND rpp.object_type     ='PRJ'
AND R.DISABLED_FLAG=0  --update only enabled rules
AND rpf.object_type = 'FLD'
--AND P.DEVL_PROJECT_ID=1037298 --add this if you want to update specific model only
AND class_name LIKE 'xxcz.cx.MyOldClass'
AND RPF.NAME LIKE 'Models – In Process'
AND r.rule_id=ru.rule_id
);

Configurator: Deploying CX class in archive vs file system

CZ Extension java classes uploaded directly on middletier / unix box:

1. Java extension classes are placed in middle-tier/unix file system
2. jserv.properties (11.5.10) or oc4j.properties (R12) file should be updated to add extension classes in classpath.
3. All published Configurator models will use same extension classes
4. Any new change in code will require a Jserv/OC4J bounce to take effect, no model republish required
5. Any code change will affect all published models using extension classes
6. Any application in the EBIZ running on Jserv/OC4J will have access to all CZ Extension classes through java classpath

CZ Extension java classes uploaded through archive

1. No changes required on middletier/unix box
2. Classes are stored in binary format in database table
3. Any change in CX requires archive upload on Configurator Model Development instance and ALL MODELS referring the archive needs to be published again,  no server bounce required
4. Code change will be effective on model basis - whichever model is published will have new code.
5. Only CZ models which are using the archive will have access to java classes, no other application of EBIZ will have access to these extension classes.
6. These classes are loaded dynamically by Runtime Configurator 

Configurator: Check for Model Logic Status using Plsql API

Sometimes its useful to find how many model's logic is not upto date using plsql API. One simple example would be for during republish of the model - if model logic is not upto date at the time of publication processing, publication program will fail and model will not be published. Following block can be handy before running any publication or locally creating configuration for the model using CIO API.

DECLARE

  p_model_id      NUMBER := 1774920;

  x_return_status VARCHAR2(10);

  x_msg_data      VARCHAR2(256);

BEGIN

  CZ_PB_MGR.IS_MODEL_UPTO_DATE( P_MODEL_ID =>p_model_id, X_RETURN_STATUS =>x_return_status, X_MSG_DATA =>x_msg_data);

  dbms_output.put_line('X_RETURN_STATUS = ' || X_RETURN_STATUS);

  dbms_output.put_line('X_MSG_DATA = ' || X_MSG_DATA);

END;

If x_return_status=1 then logic is not upto date, 0 value means logic is upto date.