This chapter covers the following topics:
This chapter describes setup tasks that you must perform to Oracle Configurator that are specific to the Oracle Telecommunications Service Ordering (TSO) solution.
This chapter explains:
The role of Configurator Extensions in a TSO solution and how to modify these Configurator Extensions where necessary for your requirements. Without modification, these Configurator Extensions can provide a certain amount of TSO functionality. Other optional functionality requires you to modify the Configurator Extensions.
How to use certain features of the Oracle Configuration Interface Object (CIO) that are specifically designed to support a TSO solution.
Before you can set up Oracle Configurator Extensions for use with the Oracle TSO solution, you must set up Oracle Bills of Material, Oracle Installed Base, and Oracle Order Management. For more information, see the following chapters:
Set Up Bills of Material
Set Up Installed Base
Set Up Order Management
In addition to this chapter, there is another chapter on setting up Oracle Configurator for use with the TSO solution, Set Up Oracle Configurator and Customize the Solution.
Following is the setup checklist for implementing TSO-specific functionality for Oracle Configurator Extensions:
| Setup Step | Required/Optional | Comment |
|---|---|---|
| Implement Oracle Configurator | Required | You must install Oracle Configurator before implementing Configurator Extensions |
| Perform General Setup for Configurator Extensions | Required | You must perform certain tasks when setting up any of the Configurator Extensions. |
| Set Up Interactive Location Search Configurator Extension (sets the Location of configured Components) | Optional (see Comment) | An item instance must have a location assigned before it can be ordered. The provided Extension is an optional design for fulfilling that general requirement. |
| Set Up Line Type Configurator Extension (sets the Line Type of a configured Component) | Required | The provided Extension should satisfy the needs of all users, but you may replace it with one of your own design. |
| Set Up IBAttribute Configurator Extension (collects configuration attributes of a configured Component) | Optional (see Comment) | This Extension is not required if no attributes are being collected from your configured item instance, but this is not a likely implementation. |
Reconfiguring installed configurations of container Models relies on the use of one or more Configurator Extensions, depending on how much you want to customize the TSO solution, if at all.
The available solutions are:
Default solutions, which require modest implementation work on your part
Customized solutions, which require additional design and custom implementation to achieve your desired results. The provided solutions are sufficient for demonstrations using the Oracle Vision instance. If the business logic and behavior of the default solution does not meet your business needs, you should consider modifying or replacing the extension with your own customized version.
For more information about reconfiguring installed configurations of Container Models, see the chapter Oracle TSO Business Processes.
Some setup considerations that affect all the TSO Configurator Extensions are described in this section.
If you do not need to customize a given Configurator Extension, then you can use the Java class for that extension that is already installed with Oracle Configurator. See Installed Classes for TSO Configurator Extensions.
If you do need to modify the default behavior of any of these Configurator Extensions, then see Using Customizable Source Code for TSO Configurator Extensions.
For each Configurator Extension, whether or not you customize its behavior, you must perform the associated setup procedures specific to that extension, as described in the other sections of this chapter:
You will need to know how to incorporate Configurator Extensions into your configuration Model and make them available to the runtime Oracle Configurator. For this information, see the Oracle Configurator Developer User's Guide.
Compiled class files for the default versions of the TSO Configurator Extensions are available directly in the class path used by the runtime Oracle Configurator. The names of the installed Java classes for the TSO Configurator Extensions are listed in the following table, along with the name of the Java package that contains them.
| Configurator Extension | Installed Java Package/Class |
|---|---|
| package for all | oracle.apps.cz.cx.tso |
| Interactive Location Search | MaintainLocationCX |
| Line Type | AssignItemLineTypeCX |
| IBAttribute | CZIBAttributeCX |
If you do not need to modify the default behavior of an extension, then, when you are defining its associated Configurator Extension Rules, you do not have to compile the Java source code and place it in a Configurator Extension Archive. Instead, when you are defining a Configurator Extension Rule in Oracle Configurator Developer, simply enter the fully qualified Java class name, as text, in the field labelled Java Class. For example, to use the Interactive Location Search Configurator Extension in a rule, you would enter the following in the Java Class field:
oracle.apps.cz.cx.tso.MaintainLocationCX
If you enter a class name for the Configurator Extension Rule directly, as described here, do not use the Choose Class button to select a class.
If you need to modify the default behavior of any of the TSO Configurator Extensions, then you must modify and recompile its customizable Java source code. Begin by consulting the Note on MetaLink, Oracle's technical support Web site, that has the Subject indicated in the table Customizable Source Code for TSO Configurator Extensions for "all" TSO Configurator Extensions. That Note is the starting point for obtaining the source code, and references all of the other individual MetaLink Notes that contain the source code and certain detailed setup information for the TSO Configurator Extensions. The table here lists the full MetaLink Note Subject for each Extension. You can locate each Note by searching MetaLink for this Subject string.
| Configurator Extension | MetaLink Note Subject |
|---|---|
| all | R12 Source Code for Oracle Telecommunications Service Ordering (TSO) Configurator Extensions |
| Interactive Location Search | R12 TSO Configurator Extension MaintainLocationCX.java (and its References) |
| Line Type | R12 TSO Configurator Extension AssignItemLineTypeCX.java (and its References) |
| IBAttribute | R12 TSO Configurator Extension CZIBAttributesCX.java |
Procedure
Consult the MetaLink note for the appropriate extension, as listed in the table Customizable Source Code for TSO Configurator Extensions. Copy the text from the Sample Code field into a text file with the appropriate name.
Edit the Java source file for the Configurator Extension, to modify the behavior of the Java class that implements the extension.
The modifications that you might be likely to make to each extension are suggested elsewhere in this chapter. For instance, see Modifying the IBAttribute Configurator Extension.
For information on how to write and compile Configurator Extensions, see the Oracle Configurator Extensions and Interface Object Developer's Guide.
See Using the Oracle Configuration Interface Object (CIO) for information on using the API for programmatic access to the runtime Oracle Configurator.
The Javadoc-format comments in the source code provide details on how to bind the methods of the Java classes when defining Configurator Extension Rules.
Any modifications to the source should be made in a package or class different from that of the installed classes. Do not place the modified versions in a package named oracle.apps.cz.cx.tso, or they will be superseded at runtime by the installed versions described in Installed Classes for TSO Configurator Extensions, because the Configurator Extension Archives in which you place customized classes are appended to the runtime class path. As a convenience, each source code sample has already been put in a different package (oracle.apps.cz.cx.sample.tso), to avoid conflicts with the installed class definitions.
Compile the Java class. See the Oracle Configurator Extensions and Interface Object Developer's Guide for information about compiling Configurator Extensions.
Place the compiled Java class in a Java class archive file (using a valid zip or JAR format) with a name of your choice.
In Oracle Configurator Developer, create a Configurator Extension Archive for the class. Add the Configurator Extension archive you created to the archive path for your Model. This provides your Model with access to the Java class in the archive. For details on how to do this, see the Oracle Configurator Developer User's Guide.
The Interactive Location Search Configurator Extension demonstrates how to interact with an Oracle Applications Framework page to display locations from an Oracle Trading Community Architecture (TCA) account, and to use the location selected by the end user to set the required Location ID and Location Type Code on a trackable Component instance. To understand the need for the Location ID and Location Type Code, see Locations.
This extension, or some alternative that provides location information, is required for implementing the reconfiguring of installed configurations of container Models.
Note: Implementing this extension assumes that you are using a user interface generated with the HTML-based version of Oracle Configurator Developer. If you want to use a DHTML user interface, you must implement a Functional Companion, as described in a previous release of this document. Functional Companions do not have all the functionality of Configurator Extensions.
Oracle Sales lets you create multiple addresses for customers. Each address is identified by a Location ID, which is not displayed to the Oracle Sales end user. At the other end of the quote-to-installation flow, Oracle Installed Base requires that every installed Component instance have a Location ID, to identify the location at which an item has been installed. Along the course of this flow, the Location Type Code points to the database table containing the detailed information for the address that the Location ID identifies.
An Oracle Configurator configuration Model normally represents only the configurable aspects of a Component, and thus does not have any innate means of expressing the location of a configured Component. Consequently, there is no built-in equivalent to the Location ID. For a trackable Component to be configured and later accepted by Oracle Installed Base, a Location ID must be assigned to every configured Component.
Oracle Configurator forces trackable item instances to be incomplete until the location is set, via the CIO. This incompleteness enforces the need for the location field in Oracle Installed Base. When an end user adds an instance of a trackable item, a location validation failure occurs, informing the user that the component lacks the location information required for ordering. This requirement for a location does not apply to items that are network Links. See Network Link Items for details.
You must implement a Configurator Extension to assign a location to an instance, but you do not necessarily require the Interactive Location Search Configurator Extension described here. If the quote or order contains the location information, then you can use a simpler Configurator Extension to query the quote or order for the needed location data, and assign it programmatically. Oracle does not currently supply a Configurator Extension to perform these tasks.
For the full source code of the Interactive Location Search Configurator Extension, consult MetaLink, Oracle's technical support Web site.
The following sections describe what you must do before using the Interactive Location Search Configurator Extension.
Note: Since this extension is constructed with Oracle Applications Framework, you must use the business logic written into the Java source for the controller object to modify its behavior. This requires expertise in programming for the Oracle Applications Framework.
Perform the following general setups.
In Oracle Trading Community Architecture (TCA), perform the required tasks for setting up Locations and Location IDs.
In Oracle Sales, define your customers.
If you are customizing the Configurator Extension, then you may also need to deploy customized versions of the Oracle Applications Framework files for the Configurator Extension. If you are using the installed classes for the Configurator Extension, then skip this section.
Obtain the Oracle Applications Framework files for Interactive Location Search from MetaLink, Oracle's technical support Web site.
Customize the files as desired, using Oracle JDeveloper. See the section Modify the Interactive Location Search Configurator Extension, for more information.
Warning: To preserve your customizations, give the files your own variations on their packages or names. Otherwise they will be overwritten when you install patches for Oracle Configurator.
Important: Be sure to check the MetaLink Note for this Configurator Extension, as listed in Customizable Source Code for TSO Configurator Extensions, to see whether there have been updates to the source code or rule binding instructions.
You need to define Configurator Extension Rules in Oracle Configurator Developer for use with the Interactive Location Search Configurator Extension. For details about Configurator Extension archives and defining Configurator Extension Rules, see the Oracle Configurator Developer User's Guide.
If you are customizing the Configurator Extension, perform the steps under Using Customizable Source Code for TSO Configurator Extensions.
For each trackable root Model in your container Model that requires a location, define one Configurator Extension Rule having three bindings, as described in the following steps:
Define a Configurator Extension Rule with the options listed below.
Name: Enter Select Location. (This is a suggested convention. You may choose any name.)
Model Node: Choose the trackable root node of your Model whose instances need their Location set.
Java Class: Specify oracle.apps.cz.cx.tso.MaintainLocationCX.
Java Class Instantiation: Choose With Model Node Instance.
For the Configurator Extension Rule described above, create an event binding, using the options listed below:
Event: Choose onCommand.
Command Name: Enter a string that you want to use as a command. For example: Pick Locations. Do not enclose the string in quotation marks. The string can contain spaces The string becomes the default title for the generated UI button that runs the Configurator Extension.
Event Scope: Choose Base Node.
Method: Choose redirectLocationSearch(HttpServletResponse Arg1, oracle.apps.cz.cio.BomModel Arg2).
For the event binding shown above, create argument bindings, using the options listed below:
Argument Binding 1
Argument Name: Accept response or Arg1.
Argument Type: Accept javax.servlet.http.HttpServletResponse.
Argument Specification: Choose Event Parameter.
Binding: Choose HttpServletResponse.
Argument Binding 2
Argument Name: Accept trackableRoot or Arg2.
Argument Type: Accept oracle.apps.cz.cio.BomModel.
Argument Specification: Choose Model Node or Property.
Binding: Choose the trackable root BomModel.
For the Configurator Extension Rule described above, create another event binding, using the following options:
Event: Choose onCommand.
Command Name: Enter the exact string updateLocationData as the command. This name is mandatory for this binding to function correctly.
Event Scope: Choose Base Node.
Method: Choose updateLocationData(oracle.apps.cz.cio.BomModel Arg1, oracle.apps.cz.cio.CXEvent Arg2) or updateLocationData(oracle.apps.cz.cio.BomModel Arg1, oracle.apps.cz.cio.TextFeature Arg2, oracle.apps.cz.cio.CXEvent Arg3).
Note: If you wish to implement the alternate version of the updateLocationData() method, which updates a TextFeature with the current TCA address, then you would choose the signature of updateLocationData() that includes a TextFeature parameter, and then define an argument binding for that parameter, as shown below under "(Optional) Argument Binding 2".
For the above event binding, create argument bindings, using the options listed below:
Argument Binding 1
Argument Name: Accept trackableRoot or Arg1.
Argument Type: Accept oracle.apps.cz.cio.BomModel.
Argument Specification: Choose Model Node or Property.
Binding: Choose the trackable root BomModel.
(Optional) Argument Binding 2
Argument Name: Accept addressFeature or Arg2.
Argument Type: Accept oracle.apps.cz.cio.TextFeature.
Argument Specification: Choose Model Node or Property.
Binding: Choose the Text Feature used to show the selected address to end users.
Argument Binding 2 (or 3)
Argument Name: Accept commandEvent or Arg2 (or Arg3).
Argument Type: Accept oracle.apps.cz.cio.CXEvent.
Argument Specification: Choose System Parameter.
Binding: CXEvent.
If it is a practice of your organization to allow changes to the TCA address data for a location between reconfigurations, then you can optionally synchronize the Text Feature with TCA, using the updateCurrentAddress() method. Otherwise, skip this binding.
Given the preceding information, then for the Configurator Extension Rule described above, optionally create an event binding, using the following options:
Event: Choose postInstanceLoad.
Event Scope: Choose Base Node.
Method: Choose updateCurrentAddress(oracle.apps.cz.cio.BomModel Arg1, oracle.apps.cz.cio.TextFeature Arg2).
For the above event binding, create argument bindings, using the options listed below:
Argument Binding 1
Argument Name: Accept trackableRoot or Arg1.
Argument Type: Accept oracle.apps.cz.cio.BomModel.
Argument Specification: Choose Model Node or Property.
Binding: Choose the trackable root BomModel.
Argument Binding 2
Argument Name: Accept currentAddress or Arg2.
Argument Type: Accept oracle.apps.cz.cio.TextFeature.
Argument Specification: Choose Model Node or Property.
Binding: Choose the Text feature that displays the current address obtained from TCA.
This is the same Text Feature that you previously used in the binding for updateLocationData(). The updateLocationData() method sets the Text Feature after the Oracle Applications Framework search. The updateCurrentAddress() method corrects the value if the TCA data has changed, since the Text Feature would have an incorrect text value for the old data
After you have defined the event and argument bindings for the items requiring locations, generate logic for your Model in order to reflect the addition of the Configurator Extension Rules.
Create or refresh a user interface for your Model. This creates two buttons in the user interface that by default are captioned with the Command Names that you specified in the binding for the onCommand events. The buttons appear on the page for the Model node that you associated with the Configurator Extension. To avoid confusion for end users, delete the button generated for the updateLocationData command; that command is issued programmatically by the Configurator Extension at run time, and clicking the button would produce an error.
In order to test the Interactive Location Search Configurator Extension from Configurator Developer, you must provide a custom initialization parameter named calling_application_id, with a value that specifies your desired calling application. You must also provide another custom initialization parameter that depends on the calling application. For Oracle Quoting and Oracle Order Management, the custom initialization parameter is client_header which the Extension uses to identify the customer by querying either the Order Management or Order Capture schema for the order/quote specified by the client header. See the Oracle Configurator Implementation Guide for details about initialization parameters.
Test the Configurator Extension from Configurator Developer by choosing the Test Model button, then choosing the Model Debugger, or the user interface that you generated.
When you test the Model and click the button you created for each top-level node requiring a location, the Interactive Location Search Configurator Extension replaces the current Oracle Configurator window and points to an OA (Oracle Applications) page. The OA page determines the host application that called it, and determines the Customer ID. Then the OA page queries the TCA for all locations for that customer, and presents them so that end users can select one. When the user selects a location, the Location ID (typically a PARTY_SITE_ID) is stored as the Location ID for the runtime Component bound to the Configurator Extension.
Since this Configurator Extension redirects to another Oracle Applications Framework page and later returns to its original page, it is necessary to get a message authentication code (MAC) for the URL of the original and apply it to the URL before returning. For details, see the section on redirecting to a Framework page in the Oracle Configurator Extensions and Interface Object Developer's Guide.
See the section, "Location Synchronization", for important information about the synchronization of location data with Oracle Installed Base when Oracle Configurator reconfigures an instance.
If you need details on the operation of this Configurator Extension, consult the comments in its source code on MetaLink.
Since the Interactive Location Search solution is constructed with Oracle Applications Framework in addition to Configurator Extensions, you must use the business logic written into the Java source for the controller object to modify its behavior. This requires expertise in programming for the Oracle Applications Framework.
The Line Type Configurator Extension is required for reconfiguring installed configurations of container Models.
If you do not install this extension, the Line Types for your fulfilled items will be defaulted in Oracle Order Management. The Line Type is a mandatory field on an order line. OM defaults the Line Type from the default Line Type that is set up for the order type. Line Types are also known as Actions.
If you install this extension and complete the setup steps described in this chapter, then your fulfilled orders will have Line Types in Oracle Service Fulfillment Manager. The Line Types will be those defined in this extension and the associated setup.
Note: Implementing this extension assumes that you are using a user interface generated with the HTML-based version of Oracle Configurator Developer. If you want to use a DHTML user interface, you must implement a Functional Companion, as described in a previous release of this document. Functional Companions do not have all the functionality of Configurator Extensions.
The Line Type Configurator Extension determines and sets the Line Type value for the associated node and its descendants by either:
Detecting the type of change that was made to the node being configured or reconfigured, relative to the latest valid baseline recorded in Oracle Installed Base
Detecting a change in the state of specified Features in the Model
The Line Type is a reference to a Transaction Type in Oracle Order Management that indicates the fulfillment actions to be applied to the configured Component instances. The Configurator Extension assigns the Line Type during a configuration session when the configuration is saved or when the Summary window appears.
The following sections describe what you must do before using the Line Type Configurator Extension.
Set up Oracle Order Management for use with this extension. For background and details, see the Oracle Configurator Implementation Guide.
In Oracle Order Management, define the desired Line Types, by defining Transaction Types that have a Transaction Type Code of Line.
Transaction Types are stored in the Order Management table, ONT.OE_TRANSACTION_TYPES_TL. The name you enter in the Transaction Types window is stored as NAME. Oracle Applications stores a numeric code for the type, TRANSACTION_TYPE_ID. The NAME value is used to display the Line Type values on the Summary window of the runtime Oracle Configurator.
The following table shows a set of Line Types that you might define. The IDs shown are example values; the actual values of the IDs depend on the data in the particular database instance in which you define the Line Types.
| TRANSACTION_TYPE_ID | NAME |
|---|---|
| 2516 | MOVE |
| 2476 | ADD |
| 2477 | CHANGE |
| 2556 | DISCONTINUED |
| 2560 | SUSPEND |
| 2570 | RESUME |
| 2600 | NO CHANGE |
These types are passed downstream to Oracle Service Fulfillment Manager to indicate the type of fulfillment action to perform.
Use the following query to see the other Transaction Types currently defined:
SELECT transaction_type_id, name, description FROM ont.oe_transaction_types_tl;
Record the TRANSACTION_TYPE_ID and NAME values for your Line Types. You will use them in the task below, Setup in Oracle Configurator Developer Using User Properties.
Perform the setup below in the Oracle Configurator (CZ) schema of the Oracle Applications database when you use this Extension. For background and details, see the Oracle Configurator Implementation Guide.
Confirm that DISPLAY_SUMMARY_FULFILLMENT_ACTION is set correctly in the CZ_DB_SETTINGS table. See the chapter, Set Up Configurator and Customize the Solution, for details. The default setting should be correct.
After you set DISPLAY_SUMMARY_FULFILLMENT_ACTION correctly, the Summary window of the runtime Oracle Configurator displays the Line Types assigned to nodes of a BOM Model.
Define elements of a Model in Oracle Configurator Developer for use with this extension. For details about defining Model elements, see the Oracle Configurator Developer User's Guide.
For the Line Types that you have defined in Oracle Order Management (as shown in the example in the table Example Line Types Defined in OE_TRANSACTION_TYPES_TL), define sets of Properties in the Main area of the Repository. Each Line Type will require at least one set of properties, and may require more, depending on how many ways you plan to test for the Line Type. For example, a Line Type of CHANGE may need multiple tests (for attribute changes, name changes, and so on), and each test will require a set of properties. Use the settings shown in the table below. In each set of Property names, replace n with an integer, incrementing n by 1 for each set. There is no limit on the number of sets you can specify.
The result should be multiple sets of Properties named in the following pattern:
LINETYPE_1_NAME, LINETYPE_1_ID, LINETYPE_1_TEST, LINETYPE_2_NAME, LINETYPE_2_ID, LINETYPE_2_TEST, LINETYPE_3_NAME, LINETYPE_3_ID, LINETYPE_3_TEST, and so on
Note that you may not want to enter a default value for these Properties. If your implementation has a standard set of tests that do not vary much when applied to specific nodes, then it might be more convenient to set them as default values. But if multiple products have different Line Types and different ways of testing for them, then you should not set default values. You will be entering node-specific properties in a subsequent step.
The form of these Property names is mandatory, unless you modify the source code for this extension to search for different strings. Oracle recommends that you not make such a change.
Important: In cases where the remote server for publication has TRANSACTION_TYPE_ID values that differ from those in the Configurator instance being used for development testing or staging, the published model will have incorrect Property values. For this reason Oracle recommends that you use only LINETYPE_n_NAME to set up the Line Type Configurator Extension. The previously documented use of LINETYPE_n_ID is still supported, but is deprecated. If you use both NAME and ID, their values may not match. This Extension does not check this situation, but uses the last Property that it examines.
For each root node in your container Model that requires Line Types, add a set of these LINETYPE_n Properties on that node for each applicable Line Type, with node-specific values, as described in the following steps.
The Properties can be defined on a BOM Model, BOM Option Class, or BOM Standard Item.
Set the priority of the Line Type relative to the other Line Types, by selecting the set of Properties that correspond to this priority, using the integer part of the Property name to indicate the priority. The priority determines the order, at runtime, in which this extension applies tests to the associated node. The first test that passes (that is, returns a True value) causes the assignment of the corresponding Line Type to the node.
For example:
LINETYPE_1_TEST is applied first.
If LINETYPE_1_TEST fails, then LINETYPE_2_TEST is applied.
If LINETYPE_2_TEST passes, then the value of LINETYPE_2_NAME is assigned to the node as its Line Type.
If LINETYPE_2_TEST fails, then LINETYPE_3_TEST is applied, and so on.
For the LINETYPE_n_NAME (or LINETYPE_n_ID) member of the Property set, enter the instance-independent NAME (or instance-specific TRANSACTION_TYPE_ID) for the Line Type, as shown in the table, Example Line Types Defined in OE_TRANSACTION_TYPES_TL.
For example, for the Line Type called ADD, enter ADD as the value of the Property LINETYPE_1_NAME (or enter 2476 as the value of the Property LINETYPE_1_ID).
The value you enter for LINETYPE_n_NAME is of type Translatable Text. You must ensure that this name is unique for the translated language in which you enter it, and that it corresponds exactly to the translated value of the NAME defined in Order Management table ONT.OE_TRANSACTION_TYPES_TL.
For the LINETYPE_n_TEST member of the Property set, enter a token string which indicates the CIO test that determines whether the specified type of change occurred that corresponds to the Line Type. The token string is composed of the string &BaseNode. combined with one of the predefined CIO test methods listed in the table, Methods for Identifying Changes Against the Baseline, later in this chapter. (If you wish to use the method isIBNodeOrDescendantChanged(), you must customize the code of this extension.)
For example, for the Line Type called ADD, you would probably enter the following token string:
&BaseNode.isAddChanged()
If you use the method isTargetChanged(), then you must use the token string syntax &BaseNode.Connectorn.isTargetChanged(), for each Connector, since the target change is on the Connector, not on the Base Node.
You must determine which test corresponds to your own definition of the meaning of a particular Line Type. If the CIO tests listed in the table, Methods for Identifying Changes Against the Baseline, do not capture some of your Line Types, then see the section, Setup in Oracle Configurator Developer Using Features.
When you have finished defining your Property sets, the results should resemble the contents of the table Line Type Definitions Compared to User Properties for Line Types, which combines the Line Types shown in the table Example Line Types Defined in OE_TRANSACTION_TYPES_TL with the Property definition sets that correspond to each of them. The Line Type priorities shown for LINETYPE_n are for demonstration only. You must assign your own priorities.
| TRANSACTION_TYPE_ID | NAME | n | LINETYPE_n_NAME | LINETYPE_n_ID | LINETYPE_n_TEST |
|---|---|---|---|---|---|
| 2476 | ADD | 1 | ADD | 2476 | &BaseNode.isAddChanged() |
| 2556 | DISCONTINUED | 2 | DISCONTINUED | 2556 | &BaseNode.isDeleteChanged() |
| 2477 | CHANGE | 3 | CHANGE | 2477 | &BaseNode.isAttributeChanged() |
| 2516 | MOVE | 4 | MOVE | 2516 | &BaseNode.isLocationChanged() |
Missing nodes correspond to situations where Oracle Installed Base contains a configuration having elements that are no longer present in the published model currently being used for orders.
Example: a model contains a Value Added Service named "Free Internet". This service was removed from the configuration model's definition, but there are item instances in Installed Base where it may be selected. When such an instance is reconfigured, the service cannot be fully restored, because this service is no longer a node in the configuration model definition. If a Line Type is to be applied to the service, it has to be done without applying any tests on the node, because the node does not exist in the current reconfiguration session.
During reconfiguration, the Line Type Configurator Extension can identify the BOM nodes that are no longer present in the item instance that is being reconfigured. This section describes how to assign a Line Type to those nodes.
See Setup in Oracle Configurator Developer Using User Properties for important background to this setup.
Define a set of Properties in the Main area of the Repository according to the following table.
| Name | Data Type | Default Value |
|---|---|---|
| LINETYPE_MISSING_NAME | Translatable Text | (Definition is optional.) |
| LINETYPE_MISSING | Integer | (Do not define one.) |
For each trackable root BOM Model that requires Line Types, add either of these LINETYPE_MISSING Properties to that node. Add the Property only once per each trackable root, which must be a BOM Model (not a BOM Option Class or BOM Standard Item).
Assign a value to the Property to indicate the appropriate Line Type, as described below.
In the Property LINETYPE_MISSING_NAME (or LINETYPE_MISSING ID), enter the instance-independent NAME (or instance-specific TRANSACTION_TYPE_ID) for the "missing" Line Type as defined in Order Management. The value indicates the Line Type that you want to assign if the node is found to be missing during reconfiguration, relative to the instance restored from Installed Base.
Example values are shown in the table Example Line Types Defined in OE_TRANSACTION_TYPES_TL. For example, if the defined Line Type is called DISCONTINUED, enter DISCONTINUED as the value of the Property LINETYPE_MISSING_NAME. If you are using Property IDs instead of names, enter the instance-specific TRANSACTION_TYPE_ID (such as 2556) as the value of the Property LINETYPE_MISSING). While it is possible to enter different Property values for different trackable root nodes, this is probably not useful and is not recommended.
The value you enter for LINETYPE_MISSING_NAME is of type Translatable Text. You must ensure that this name is unique for the translated language in which you enter it, and that it corresponds exactly to the translated value of the NAME defined in Order Management table ONT.OE_TRANSACTION_TYPES_TL.
During reconfiguration, the Line Type Configurator Extension can identify BOM nodes that have no actual changes made to them, and so are not considered "changed" when the item instance is being reconfigured. This section describes how to assign a Line Type to those nodes.
Although some implementers want these lines to appear in the quote or order resulting from a reconfiguration, Oracle recommends against this practice, for performance reasons.
See Setup in Oracle Configurator Developer Using User Properties for important background to this setup.
Define a set of Properties in the Main area of the Repository according to the following table.
| Name | Data Type | Default Value |
|---|---|---|
| LINETYPE_UNCHANGED_NAME | Translatable Text | (Definition is optional.) |
| LINETYPE_UNCHANGED | Integer | (Do not define one.) |
For each trackable root BOM Model that requires Line Types, add either of these LINETYPE_UNCHANGED Properties to that node. Add the Property only once per each trackable root, which must be a BOM Model (not a BOM Option Class or BOM Standard Item).
Assign a value to the Property to indicate the appropriate Line Type, as described below.
In the Property LINETYPE_UNCHANGED_NAME (or LINETYPE_UNCHANGED ID), enter the instance-independent NAME (or instance-specific TRANSACTION_TYPE_ID) for the "unchanged" Line Type as defined in Order Management. The value indicates the Line Type that you want to assign if the node is found to be unchanged during reconfiguration.
This value is used to ensure that merely assigning a Line Type does not trigger a "change" Line Type on parent items. (By default, Line Type assignment to any child implies a change to that child, resulting in parent items returning true for the isChildChanged() method.)
Example values are shown in the table Example Line Types Defined in OE_TRANSACTION_TYPES_TL. For example, if the defined Line Type is called NO CHANGE, enter NO CHANGE as the value of the Property LINETYPE_UNCHANGED_NAME. If you are using Property IDs instead of names, enter the instance-specific TRANSACTION_TYPE_ID (such as 2600) as the value of the Property LINETYPE_UNCHANGED). While it is possible to enter different Property values for different trackable root nodes, this is probably not useful and is not recommended.
The value you enter for LINETYPE_UNCHANGED_NAME is of type Translatable Text. You must ensure that this name is unique for the translated language in which you enter it, and that it corresponds exactly to the translated value of the NAME defined in Order Management table ONT.OE_TRANSACTION_TYPES_TL.
If the CIO tests listed in the table Methods for Identifying Changes Against the Baseline, later in this chapter, do not capture the meaning of some of your Line Types, then you can Model those Line Types as nodes whose state can be tested as being True or False. You can Model a Line Type test as either the True state of a Boolean Feature or as the selected Option of an Option Feature.
Determine which of your Line Types (such as those listed in Example Line Types Defined in OE_TRANSACTION_TYPES_TL) are not captured by the CIO tests listed in the table Methods for Identifying Changes Against the Baseline.
Define a Feature whose state, when it is evaluated as True, corresponds to that Line Type. You might choose to use either an Option Feature or a Boolean Feature.
Define an Option Feature whose options correspond to the names of those Line Types.
For example:
Define an Option Feature named Use Cases
For the Line Type called SUSPEND, define an option of Use Cases named Suspend
For the Line Type called RESUME, define an option of Use Cases named Resume
Define Boolean Features whose True states correspond to the names of those Line Types.
For example:
For the Line Type called SUSPEND, define a Boolean Feature named Suspended?
For the Line Type called RESUME, define a Boolean Feature named Resumed?
Follow steps 1 through 4 under the section Setup in Oracle Configurator Developer Using Properties.
For the LINETYPE_n_TEST member of the Property set, enter the relative node path from the nearest parent BOM Model to the Option or Boolean Feature that corresponds to the Line Type.
For example, for the Line Type called SUSPEND, you would enter the following path: Use Cases.Suspend
When you have finished defining your Property sets, using both the Property-based and Feature-based methods, the results might resemble the contents of the table More Line Type Definitions Compared to User Properties for Line Types, which combines the Line Types shown earlier with the Property definition sets that correspond to each of them. The table below is similar to the earlier table Line Type Definitions Compared to User Properties for Line Types, with the addition of rows showing Feature-based definitions for the Line Types SUSPEND and RESUME. For the sake of demonstration, the table shows both an Option Feature-based value and a Boolean Feature-based value for LINETYPE_n_TEST. This is not necessarily a recommended practice.
The Line Type priorities shown for LINETYPE_n are for demonstration only. You must assign your own priorities.
| TRANSACTION_TYPE_ID | NAME | n | LINETYPE_n_NAME | LINETYPE_n_ID | LINETYPE_n_TEST |
|---|---|---|---|---|---|
| 2476 | ADD | 1 | ADD | 2476 | &BaseNode.isAddChanged() |
| 2556 | DISCONTINUED | 2 | DISCONTINUED | 2556 | &BaseNode.isDeleteChanged() |
| 2477 | CHANGE | 3 | CHANGE | 2477 | &BaseNode.isValueChanged() |
| 2516 | MOVE | 4 | MOVE | 2516 | &BaseNode.isLocationChanged() |
| 2560 | SUSPEND | 5 | SUSPEND | 2560 | Use Cases.Suspend |
| 2570 | RESUME | 6 | RESUME | 2570 | Resumed? |
The setup described elsewhere in this section assumes that some of the items in a trackable Component instance share the same data that this Configurator Extension uses to assign the Line Type (that is, the Line Type's ID, test, and priority).
It is very possible that your own configuration Model requires different IDs, tests, or priorities for different trackable items. The different items might be other trackable root Components or trackable descendants of the Component you have already defined Line Types for. You could accomplish this distinction by defining User Properties on all the affected items, but this course might require many Property definitions.
To remedy this situation, this extension allows you to define Line Type data for a node by specifying only the path to a node that already has the required Property definitions. This method is called indirection, since the Property definitions for a node are obtained indirectly from another node.
In the Main area of the Repository, define a single Text Property, named LINETYPE_CHECKLIST, with no default value.
Determine which of your trackable nodes require Property definitions for Line Types that differ from the set that you have defined on the originally selected node.
In one of those differing nodes, define the Property sets for Line Types, as described in the section Setup in Oracle Configurator Developer Using Properties.
If the differing node is a trackable descendant of the originally selected node, then at runtime it reuses the Line Type-related User Properties of that ancestor node. Consequently, you do not have to define a full set of Property sets on the differing child node; you only have to define the Property sets with values that differ from the original node's. Any Property definitions that are defined locally on a node override the reused definitions.
In one of the other differing nodes, add the User Property LINETYPE_CHECKLIST that you defined.
For the value of the Property LINETYPE_CHECKLIST, enter the relative node path from the nearest parent BOM Model to the differing node that carries the Properties that you defined in step 3.
Expanding on the explanation under step 3, the Properties of the node specified by LINETYPE_CHECKLIST are reused. If you need to further redefine the Properties for one of the differing nodes, you only have to define the Property sets with values that differ from the checklist node. These local values override the inherited ones.
Repeat steps 4 through 6 for all of the other differing nodes in your Model.
Important: Be sure to check the MetaLink Note for this Configurator Extension, as listed in Customizable Source Code for TSO Configurator Extensions, to see whether there have been updates to the source code or rule binding instructions.
You need to define a Configurator Extension Rule in Oracle Configurator Developer for use with this extension. For details about defining Configurator Extension Rules, see the Oracle Configurator Developer User's Guide.
If you are customizing the behavior of this Configurator Extension, then see Using Customizable Source Code for TSO Configurator Extensions. If you are using the installed classes and not customizing, see Using Installed Classes for TSO Configurator Extensions.
Define a Configurator Extension Rule with the options listed below:
Model Node: Choose the node of your Model whose instances need their Line Types updated. The update applies to all descendants of the Component.
Java Class: Specify oracle.apps.cz.cx.tso.AssignItemLineTypeCX.
Java Class Instantiation: Choose With Model Node Instance.
Create an event binding for the above Configurator Extension Rule, with the options listed below:
Event: Choose postInstanceLoad.
Event Scope: Choose Base Node Subtree.
Method: Choose initializeItemLineTypeMapping(oracle.apps.cz.cio.IRuntimeNode Arg1).
Create an argument binding for the above event binding, with the options listed below:
Argument Name: Accept node or Arg1.
Argument Type: Accept oracle.apps.cz.cio.IRuntimeNode.
Argument Specification: Choose Event Parameter.
Binding: Choose newNode.
Create a second event binding for the Configurator Extension Rule, with the options listed below:
Event: Choose onConfigLineType.
Event Scope: Choose Global.
Method: Choose assignItemLineType(oracle.apps.cz.cio.IRuntimeNode Arg1).
Create an argument binding for the above event binding, with the options listed below:
Argument Name: Accept trackableRoot or Arg1.
Argument Type: Accept oracle.apps.cz.cio.IRuntimeNode.
Argument Specification: Choose System Parameter.
Binding: Choose Base Node of Rule.
Generate logic for your Model, in order to reflect the addition of the Configurator Extension Rule.
Create or refresh a user interface for your Model.
Test the Configurator Extension from Configurator Developer by choosing the Test Model button, then choosing the Model Debugger, or the user interface that you generated.
The method initializeItemLineTypeMapping() is bound to the event postInstanceLoad so it is triggered immediately after a Component instance or other associated node is created, or brought into the configuration. This method validates that all the Line Type-related Property data is correct, and then initializes the mapping structures that will cache this data for use by the assignItemLineType() method.
The method assignItemLineType() is bound to the event onConfigLineType, which is triggered whenever the Summary window appears and displays the Line Type values. Choosing , at runtime, to display only the changes relative to Installed Base also triggers this event. The onConfigLineType event is also triggered when the current configuration is saved, such as when the user ends a configuration session. This method proceeds recursively through each BOM entity in the configuration, assigning the Line Types, based on the Property data cached by the method, initializeItemLineTypeMapping(). Line Types can be assigned to both trackable and non-trackable BOM nodes.
Because of the interdependency of the two methods, it is essential to perform the event binding for both of them.
If you need details on the operation of this Configurator Extension, consult the comments in its source code on MetaLink.
If you modify your Model in accordance with the steps in this section, then you should not need to modify the Line Type Configurator Extension.
The IBAttribute Configurator Extension allows end users to collect attributes of configured Components. This extension is recommended, but not required for implementing the reconfiguring of installed configurations of container Models.
Note: Implementing this extension assumes that you are using a user interface generated with the HTML-based version of Oracle Configurator Developer. If you want to use a DHTML user interface, you must implement a Functional Companion, as described in a previous release of this document. Functional Companions do not have all the functionality of Configurator Extensions.
This extension enables an end user of the runtime Oracle Configurator to collect the values of attribute Features that have been set on the trackable children of a runtime Component instance. When the configuration is saved, the configuration attribute values are automatically written to the pending transactions for Oracle Installed Base.
The following sections describe what you must do before using the IBAttribute Configurator Extension.
Set up elements of the Oracle Applications database for use with this extension. For background and details, see the Oracle Configurator Implementation Guide. For trackable items, map extended attributes in Oracle Installed Base to configuration attribute Features and Properties in Configurator Developer.
For more information, see the chapter, Set Up Configurator and Customize the Solution.
Important: Be sure to check the MetaLink Note for this Configurator Extension, as listed in Customizable Source Code for TSO Configurator Extensions, to see whether there have been updates to the source code or rule binding instructions.
You need to define a Configurator Extension Rule in Oracle Configurator Developer for use with this extension. For details about defining Configurator Extension Rules, see the Oracle Configurator Developer User's Guide.
If you are customizing the behavior of this Configurator Extension, then see Using Customizable Source Code for TSO Configurator Extensions. If you are using the installed classes and not customizing, see Using Installed Classes for TSO Configurator Extensions.
Define a Configurator Extension Rule with the options listed below:
Model Node: Choose the node of your Model whose instances need their attributes collected. The Configurator Extension searches all descendants of the Component for attributes.
Java Class: Specify oracle.apps.cz.cx.tso.CZIBAttributeCX.
Java Class Instantiation: Choose With Model Node Instance.
Create an event binding for the above Configurator Extension Rule, with the options listed below:
Event: Choose onInstanceLoad.
Event Scope: Choose Base Node Subtree.
Method: Choose onLoad(oracle.apps.cz.cio.IRuntimeNode Arg1).
Create an argument binding for the above event binding, with the options listed below:
Argument Name: Accept node or Arg1.
Argument Type: Accept oracle.apps.cz.cio.IRuntimeNode.
Argument Specification: Choose Event Parameter.
Binding: Choose newNode.
Generate logic for your Model, in order to reflect the addition of the Configurator Extension Rule.
Create or refresh a user interface for your Model.
Test the Configurator Extension from Configurator Developer by choosing the Test Model button, then choosing the Model Debugger, or the user interface that you generated.
The IBAttribute Configurator Extension runs whenever a trackable instance is loaded. For each trackable BOM child of the instance, the Configurator Extension:
Collects configuration attribute information from the Properties.
Finds the attribute Feature.
Associates the attribute with the RuntimeNode.
Propagates the attribute to the node's children (including instantiable Components) based on the propagation mode. The IBAttribute Configurator Extension associates attributes with a RuntimeNode by using the public class Attribute, which is part of the CIO.
Finally, the attribute values are saved to the CZ_CONFIG_EXT_ATTRIBUTES table when the configuration is saved. The CZ_CONFIG_EXT_ATTRIBUTES table is a temporary holder for the attribute values while the attribute details are pending for acceptance in Installed Base. At this point, the attributes become part of the transaction details in the transaction that is pending for acceptance into Oracle Installed Base. When the transaction is accepted (by installation through Service Fulfillment Manager), the configuration attribute values become part of the installed instance.
See the section Attribute Synchronization, for important information about the synchronization of attribute data with Oracle Installed Base when Oracle Configurator reconfigures an instance.
If you need details on the operation of this Configurator Extension, consult the comments in its source code on MetaLink.
For information on using the classes and methods of the Configuration Interface Object (CIO), see the Oracle Configurator Extensions and Interface Object Developer's Guide.
If you modify your Model in accordance with the steps in the section Setting Up IBAttribute Configurator Extension, then you do not need to modify the IBAttribute Configurator Extension.
When modifying your Model, you must follow the conventions for naming Properties described in the Oracle Configurator Methodologies chapter on configuration attributes. Otherwise, the IBAttribute Configurator Extension will not be able to collect values for the attribute Features. To use different Property names, you must modify the character strings used to match Property names, so that they match your own Property names. The following example shows typical matching strings.
Example: Strings for Property Names in the Configurator Extension
...
private void getAttributes(RuntimeNode node) {
...
if (prop.getName().startsWith("ATTR_")) {
...
int beginningIndex = new String("ATTR_"). length();
StringTokenizer tokens = new StringTokenizer(name.substring(beginningIndex), "_", false);
...
if (name.endsWith("PATH")) {
...
} else if (name.endsWith("MODE")) {
...
} else if (name.endsWith("NAME")) {
...
} else if (name.endsWith("GROUP")) {
...
if (prop.getName().startsWith("ATTR_NAME")) {
...
This section contains information about using the Oracle Configuration Interface Object (CIO). For additional information about using this API, see the Oracle Configurator Extensions and Interface Object Developer's Guide.
In addition to single-instance configurations, Oracle Configurator can create and maintain configurations that consist of multiple instances of trackable configurable Components. That is, the instances can be joined into a network by creating connections. For more information about instance configurations, see the Oracle Configurator Extensions and Interface Object Developer's Guide.
Each Component instance has a unique Instance Header identifier, stored as CZ_CONFIG_ITEMS.INSTANCE_HDR_ID. You can save, restore, revise, and save again a Component instance. Each saved instance revision has a non-unique Instance Revision Number identifier, stored as CZ_CONFIG_ITEMS.INSTANCE_REV_NBR. The unique combination of Header ID and Revision Number identifies an instance record. For more information on identifying configurations, see the Oracle Configurator Implementation Guide.
Configurations can include multiple Component instances, and you can configure the same Component instance in multiple configuration sessions.
In Oracle Installed Base, you can track the baseline and revised Component instances in a configuration. For information about how to determine differences between the baseline for a Component in Oracle Installed Base and the revised instance of that Component, see the section, "Identify Changes to a Configuration", below.
For information on creating configuration Models that support reconfiguration, see the chapter, Set Up Configurator and Customize the Solution.
You can use the set of methods appearing in the table, Methods for Identifying Changes Against the Baseline, below, to identify the types of changes that occur during a configuration session between the baseline revision of the trackable Component instance (as installed in Oracle Installed Base when the configuration session began) and the current Component instance (which is being reconfigured). The methods appearing in the table are all members of the IRuntimeNode interface.
Following is a fragmentary example of how to use one of these methods.
...
public boolean wasAdded(RuntimeNode node) {
boolean added = node.isAddChanged();
return added;
}
...
For additional explanation, see the section, "Specify the Line Type", earlier in this chapter.
You can reconfigure installed instances directly through the CIO. To ensure that you select all the trackable instances that you want to reconfigure, you need to identify the set of instances and add them to a ConfigParameters object before calling CIO.startConfiguration().
Following are suggestions for determining the set of instances that you want to reconfigure.
If you know the order number for the fulfilled instances, then you can query for the order number as the value of CSI_ITEM_INSTANCES.LAST_OE_ORDER_LINE_ID. The instances in Installed Base for that order are identified by CSI_ITEM_INSTANCES.CONFIG_INST_HDR_ID.
If you know the Session Header ID (CZ_CONFIG_DETAILS_V.CONFIG_HDR_ID) and Session Revision Number (CZ_CONFIG_DETAILS_V.CONFIG_REV_NBR) of the order that was fulfilled, then you can use the following query to find the instances in that order.
Query for Instances
SELECT config_inst_hdr_id, config_inst_rev_num FROM apps.csi_item_instances ib, apps.cz_config_details_v cz WHERE ib.config_inst_hdr_id = cz.instance_hdr_id AND cz.component_instance_type = 'I' AND cz.config_hdr_id = session_header_id AND cz.config_rev_nbr = session_revision_number AND cz.config_item_id = ib.config_inst_item_id AND ib.active_end_date IS NULL;
Once you have identified the desired instances, use ConfigParameters.addInstalledInstance() to add them to the ConfigParameters object used to start the reconfiguration, then call CIO.startConfiguration() to create a configuration containing the instances.
The following example, Reconfiguring Installed Instances, demonstrates this technique. The code assumes that you have created a CIO object and a database context, and have identified the desired model. To identify the model, a hard-coded hypothetical model ID is shown. You might also define the custom method shown, getPublication(itemId, orgId). You pass the Collection of desired instances to the custom method startReconfigFlow().
Reconfiguring Installed Instances
import com.sun.java.util.collections.Collection;
import com.sun.java.util.collections.Iterator;
import oracle.apps.cz.cio.BomExplosionException;
import oracle.apps.cz.cio.CIO;
import oracle.apps.cz.cio.ConfigParameters;
import oracle.apps.cz.cio.Configuration;
import oracle.apps.cz.cio.LogicalException;
import oracle.apps.cz.cio.ModelLookupException;
import oracle.apps.cz.dio.ui.NoSuchUiDefException;
import oracle.apps.cz.utilities.EffectivityUsageException;
import oracle.apps.fnd.common.Context;
public class Reconfiguration {
public void startReconfigFlow(CIO cio, Context ctx, int itemId, int orgId, Collection instances)
throws LogicalException, ModelLookupException, EffectivityUsageException, BomExplosionException, NoSuchUiDefException {
ConfigParameters params = null;
int modelId = 1000; // or define custom method: getPublication(itemId, orgId);
params = new ConfigParameters( modelId );
params.setValidationContext("INSTALLED");
if(instances != null) {
for(Iterator itr = instances.iterator(); itr.hasNext(); ) {
Long insHdr = (Long) itr.next();
params.addInstalledInstance( insHdr );
}
}
Configuration config = cio.startConfiguration(params, ctx);
// perform reconfiguration of instances here
config.completeBeforeSave();
config.saveNew();
}
}
An item node is considered discontinued if it was previously installed and, during a configuration session, it is either:
deselected: the end user deselects the node, thus setting its state to unknown or false
deleted: the end user removes the node (for example, by clicking the Delete button on an instance containing the node)
Be aware that for downstream applications there is no effective difference between these states.
Note: Oracle recommends not deleting or deselecting instances at runtime, if possible. Instead, we suggest using a Boolean Feature that indicates the Line Type. This approach allows the end user to access the instance and supply additional attribute data, such as the reason for the discontinuation. The Line Type may be used in SFM to expire the instance so that it is no longer accessible for reconfiguration. Using this approach makes it much less likely that you need to worry about the concerns in the section Access Discontinued Items.
To access both current and discontinued items in a TSO solution, you must use the following alternate signatures for these methods:
RuntimeNode.getChildByName(String name, int type)
RuntimeNode.getChildByID(int ID, int type)
RuntimeNode.getChildByPersistentID(int ID, int type)
Each signature includes a second argument, type. The possible values for type are:
RuntimeNode.CURRENT_OR_DISCONTINUED_CHILD
RuntimeNode.CURRENT_CHILD
RuntimeNode.DISCONTINUED_CHILD
The default type is CURRENT_CHILD.
If a configured instance of your Model might contain discontinued nodes, then you should also call IRuntimeNode.isDiscontinued() as a condition of working with a node, such as by calling getState(), getCount(), or isSelected(). If a node has been discontinued by deselection, but not by deletion, then calling a method on it does not raise a NodeDeletedException.
You should also be familiar with the list of problems that can occur when evaluating runtime conditions provided in the Oracle Configurator Developer User's Guide, since some of those problems may resemble issues with accessing discontinued nodes.
To access trackable Component instances in a TSO solution, use one of the following methods:
Use Component.getInstanceNumberLong() to get the Instance Header ID of a trackable Component instance. If the Component instance is not trackable, this method returns the Instance Number. If the Component is a mandatory Component (Minimum Instances and Maximum Instances are both 1), this method returns 1.
Use ComponentSet.getChildByInstanceNumber(int instNum) to get a trackable Component instance by passing an Instance Header ID.
If you have set the name for a Component instance--by using Component.setInstanceName(String newName)--then you can get that instance by the name you set, by using ComponentSet.getChildByName(String userSetName) on the ComponentSet that includes the instance.
In order to access both current and discontinued Component instances, use the following alternate signature: ComponentSet.getChildByInstanceNumber(int instNum, int type). For type, specify one of the values listed above (such as CURRENT_CHILD).
If the link flag on a node is set by Oracle Configurator, then this marks it as a link. Links are trackable, but do not have a location. See the chapter, Set Up Configurator and Customize the Solution, for database details.
The CIO reports as unsatisfied any Model instance that is:
A trackable root
Does not have a location assigned
The following methods report whether a node is a link:
BomInstance.isIBLinkItem()
ITrackableInstance.isIBLinkItem()
The use of events to trigger Configurator Extensions is a notable feature of Oracle Configurator. The TSO solution does not introduce any new events or restrict the use of existing events. However, there are some events with particular significance for TSO. The following table lists these events. For details on Configurator Extension events, see the Oracle Configurator Developer User's Guide.
During the fulfillment phase of the TSO flow, end users can change the attributes of instances of trackable items. These changes are saved in Oracle Installed Base, but are not kept as data in the saved configuration results. When Oracle Configurator reconfigures an instance, it synchronizes the attribute data for the item's saved configuration with the latest attribute data from Oracle Installed Base. This synchronization occurs in the following order relative to events listed in the above table.
The onInstanceLoad event is dispatched.
Configurator synchronizes the attribute data in the saved configuration of an instance with the latest attribute data from Oracle Installed Base (except for transient attributes).
The postInstanceLoad event is dispatched.
Note: If you create a Configurator Extension that depends on attribute data, ensure that you bind it to the proper event. If you are creating attribute data before fulfillment, choose onInstanceLoad. If you are restoring attribute data after fulfillment, choose postInstanceLoad.
See the section, "Use Configuration Attributes with Installed Base (IB)" earlier in this chapter, for background on how attribute values are assigned.
Transient attribute values are not restored during attribute synchronization. See the section Transient Attributes for background.
The CIO allows you to directly set the value of an extended attribute. To do so, use RuntimeNode.setAttributeValue(String name, String group, String value), specifying the name and group of the attribute, and the value to set for it. The group argument can be null.
During reconfiguration, Oracle Configurator synchronizes the instance name for the item's configuration with the latest instance name from Oracle Installed Base. If you have changed the instance name during fulfillment, the name is restored when you reconfigure the instance in the runtime Configurator. The synchronization of instance names has the same relation to Configurator Extension events as the synchronization of attribute data described in the section, "Attribute Synchronization", above.
During reconfiguration, Oracle Configurator synchronizes the location for the item's configuration with the latest location from Oracle Installed Base. If you have changed the location during fulfillment, the location is restored when you reconfigure the instance in the runtime Configurator. The synchronization of location has the same relation to Configurator Extension events as the synchronization of attribute data described in the section, "Attribute Synchronization", above.
A BOM node is tangible if it is a shippable, inventory transactable, serializable, non-ATO standard item, in a Network Configuration.
BomNode.isTangible() returns True if this BOM node is tangible.
BomNode.isReturned() returns True if this tangible node was returned in Installed Base.
For details on tangible items, see Tangible Items.
You can make input for a Text Feature required by calling TextFeature.setRequired(), as described in the Oracle Configurator Extensions and Interface Object Developer's Guide. However, when using this technique in the TSO flow, do not call TextFeature.setRequired() on passive item instances. Doing so will produce a runtime error when the current transaction is committed or rolled back. From the standpoint of the CIO, a passive item instance is one that returns False when tested with RuntimeNode.isEditable(). For background on passive item instances, see Partial Network Reconfiguration and Validation. You should only call TextFeature.setRequired() in a Configurator Extension that is bound to the event postInstanceEditable.