2 Reference Information

This section contains the following topics:

• Section 2.1, "CDR Naming Version Object Type"

• Section 2.2, "CDR Base Object Type"

• Section 2.3, "CDR Object-Specific Database Object Types"

• Section 2.4, "Retrieving Reference Codelist Names and Values"

• Section 2.5, "Retrieving the Instance Domain ID"

• Section 2.6, "Standard Parameters"

2.1 CDR Naming Version Object Type

Object information is stored in two tables in the Oracle LSH database: cdr_namings, which contains one row for each defined Oracle LSH object, and cdr_naming_versions, which contains one row for each version of each defined Oracle LSH object. Information from these two tables is stored in two composite database object types: cdr_naming_version_obj_type and cdr_base_obj_type.

For both the composite object types, the attributes company_id, obj_id, obj_ver, namespace_obj_id, and namespace_obj_ver form a composite primary key. You can refer to any existing object using this primary key.

Parameters of type cdr_naming_version_obj_type are required in APIs for creating and modifying an object.

The attributes of cdr_naming_version_obj_type are:

• company_id. To get your company ID, use CDR_PUB_DEF_FACTORY_UTILS.GetCompanyId.

• obj_id is the unique ID of the object. Oracle LSH generates this ID when you create a new object.

• obj_ver is the object's version number.

  Note:

  The attributes company_id, obj_id, obj_ver, namespace_obj_id, and namespace_obj_ver together constitute an object's primary key.

• namespace_obj_id. The unique ID of the object's parent object; for example, a Table instance is always contained in a Work Area, so its namespace_obj_id is the object ID of its Work Area.

• namespace_obj_ver. The version number of the object's parent object.

  Note:

  You can create a child object only in the latest version of its parent object. If you pass a namespace version number that is not the latest when creating a child object, the system ignores the value you pass and creates the child in the latest version of the parent.

• namespace_start_obj_ver. This attribute contains the version number of the parent object at the time the version represented by obj_ver of the object represented by obj_id was created.

• namespace_end_obj_ver. This attribute contains the version number of the parent object at the time when the version represented by obj_ver of the object represented by obj_id was superseded by a higher version. If the object is still the most current version, then this attribute contains the value 999999.

• object_type_rc This attribute defines what type of object you are creating or modifying. This value is mandatory for creating objects, but not for modifying objects. See "Retrieving Reference Codelist Names and Values" for information on retrieving valid values.

• name. This is the name of the object.

• owning_location_rc. This attribute is entered in the system at LSH installation time and is stored as a profile in the system. The system automatically sets this value to the profile value for all objects.

• checked_out_flag_rc. This value indicates whether the object is currently checked out or not. The possible values are $YESNO$YES and $YESNO$NO.

• checked_out_id is the user ID of the person who checked out the object, if it is currently checked out.

• object_subtype_id. This attribute specifies the ID of the object's subtype. Use CDR_PUB_DF_NAMING_UTIL.GetObjectSubtypeID to retrieve an object's subtype ID.

• description. This is an optional attribute but it is highly recommended that you provide a description for future reference. You can modify the description using appropriate API for the object.

• ref_company_id. If the object is an instance object, this attribute contains the company ID of the source definition.

• ref_obj_id. If the object is an instance object, this attribute contains the object ID of the source definition.

• ref_obj_ver . If the object is an instance object, this attribute contains the object version number of the source definition.

• copied_from_company_id. If the object is a copy of another object, this attribute contains the company ID of the original object.

• copied_from_obj_id. If the object is a copy of another object, this attribute contains the object ID of the original object.

• copied_from_obj_ver. If the object is a copy of another object, this attribute contains the object version number of the original object.

• object_version_number. This attribute is for Oracle LSH internal use only. Never enter a value for this attribute.

• status_rc. This attribute contains the current status of the object. See "Retrieving Reference Codelist Names and Values" for information on retrieving valid values.

• validation_status_rc. This attribute contains the current validation status of the object. See "Retrieving Reference Codelist Names and Values" for information on retrieving valid values.

• version_label. This attribute stores the version label of the object, if any.

2.2 CDR Base Object Type

For some operations on objects, only the identification contained in a CDR base object type (cdr_base_obj_type) is required. Some APIs allow you to operate on multiple objects at the same time by using a parameter based on a collection of CDR base object types called cdr_base_obj_coll.

A CDR Base Object Type contains a subset of the information contained in a CDR naming Version Object Type (see "CDR Naming Version Object Type").

2.3 CDR Object-Specific Database Object Types

Each Oracle LSH object type has its own unique attributes beyond what is included in the CDR Naming Version Object Type and CDR Base Object Type. These unique attributes are included in a view for each object type. The view includes information on both definitions and instances of a particular object type. In the case of Tables, it includes Table Descriptors as well as Table definitions and instances.

APIs that are used to create or modify Oracle LSH defined objects contain parameters based on these supplementary database object types. You can set values for the object-specific attributes using these parameters.

For example, the supplementary database object type for Oracle LSH Programs is called cdr_program_obj_type. In the Create Program API, the parameter pi_cdrprgobjtype is of this type. Its attributes are:

• company_id. To get your company ID, use CDR_PUB_DEF_FACTORY_UTILS.GetCompanyId.

• obj_id. The unique ID of the Program.

• obj_ver. The Program's version number.

• tech_type_id. Different executable object types have different technology types, which can be queried using the view cdr_tech_types_v. Use the column program_type_rc to see which tech type is valid for a particular object type. In the case of Programs, only the tech types whose value in the program_type_rc column is $PROGRAMTYPES$PROGRAM and which are present in the lookup type cdr_tech_types are allowed. They are: $TECHTYPES$SAS, $TECHTYPES$SASCATALOGS, $TECHTYPES$SASFORMATS, $TECHTYPES$PLSQL, $TECHTYPES$REPORTS.

  Note:

  Tech types that are not included in the lookup type cdr_tech_types are used internally only and should not be used with public APIs.

• manual_validation_flag_rc. This flag determines whether a Program's outputs receive their validation status from their Execution Setup or must be validated manually. The valid values are: $YESNO$YES and $YESNO$NO.

See the chapter on "Defining Programs" in the Oracle Life Sciences Data Hub Application Developer's Guide for information about these attributes. Each object type has its own chapter in this manual where its attributes are described.

2.4 Retrieving Reference Codelist Names and Values

Some database object type attributes (those ending in the string _rc) have a fixed set of allowed values stored in a lookup (reference codelist). These attributes correspond to fields in the user interface with a drop-down or pop-up list of values. To supply or change one of these values you must enter the exact string stored in the reference codelist, with the codelist name surrounded by dollar signs and followed by a codelist value.

For example, the API to create any object includes a parameter of type cdr_naming_version_obj_type, one of whose attributes is object_type_rc. You must enter the correct string for the type of object you want to create.

Reference codelists are stored in a table you access through the view cdr_lookups. The following columns contain the following information:

• lookup_type: reference codelist names

• lookup_code: reference codelist values

• meaning: the text that is displayed in the user interface

• description: additional information (sometimes)

If you have LSH Setup Admin privileges you can look up reference codelists in the Applications user interface; see "Querying and Viewing Lookups" in the Oracle Life Sciences Data Hub System Administrator's Guide.

You can browse the view in a tool like SQL Developer to find these values. However, it is not always easy to guess the name of the reference codelist. In that case, you can go into the Oracle LSH user interface to where they are displayed and note one of the allowed values, then query.

For example, object types are displayed in the Add drop-down list in the Work Area Properties screen. You can see that one object type is Business Area, so you can use the following query:

select lookup_type, lookup_code, meaning from cdr_lookups where meaning like '%Business Area%';

Now you know that the lookup_type for object types is CDR_OBJECT_TYPES and you can use the following query to get all the other values:

select distinct lookup_code, meaning from cdr_lookups where lookup_type = 'CDR_OBJECT_TYPES';

2.5 Retrieving the Instance Domain ID

While working with classification-related APIs, you may need the domain ID for the Oracle LSH environment you are working in. This is the ID for your Oracle LSH instance, which is created during installation. It has nothing to do with user-defined Domains that contain Application Areas.

Use the following query to find the domain ID of your Oracle LSH environment:

SELECT def_domain_id FROM tms.tms_def_domains WHERE name = 'cdr_user_hier';

2.6 Standard Parameters

Some or all of the following standard Oracle Applications parameters are included in each function and procedure:

P_API_VERSION (Mandatory) Enter the current version of the API you are calling. <Add: "The version number is displayed at the top of this page." or whatever is true for where the user can see the version number.> The API compares the version numbers of incoming calls to its current version number and returns an error if they are incompatible.

P_INIT_MSG_LIST (Optional) Accept the default value (FND_API.G_FALSE) to ensure that this individual API does not initialize the message list upon completion. Pass FND_API.G_TRUE to override the default behavior.

P_COMMIT LIST (Optional) Accept the default value (FND_API.G_FALSE) to ensure that this individual API does not commit upon completion. Pass FND_API.G_TRUE to override the default behavior.

P_VALIDATION_LEVEL (Optional) Accept the default value to perform full validation. No other values are currently supported.

X_RETURN_STATUS This output parameter returns the end status of the API: (S) Success, (E) Error or (U) Unexpected Error.

X_MSG_COUNT This output parameter returns the count of error messages if the return status is other than Success.

X_MSG_DATA This output parameter returns the text of the error message, if the message count is 1. If there are more than one messages, use cdr_pub_msg_pub.get to retrieve the messages.