This chapter describes requests, which are programmatic attempts to modify a configuration.
This chapter covers the following topics:
A request is an attempt to modify a configuration by setting the logical state or numeric value of a node in the configuration Model (such as an Option or BOM Item). The table Methods Typically Used to Make Requests lists some methods of this type:
| Method | Described In ... |
|---|---|
| IState.setState() | Getting and Setting Logic States |
| ICount.setCount() | Getting and Setting Numeric Values |
| IOPtion.select() | Access to Options |
Requests that set a state or value, such as those listed in Methods Typically Used to Make Requests, are called user requests. See User Requests.
You can code a set of user requests that are applied to a configuration at any time. These are called nonoverridable requests. These requests can be applied only programmatically, and have a higher priority than user requests. See Nonoverridable Requests.
When user requests fail, due to an override of a contradiction, the CIO generates a list of these failed requests. See Failed Requests.
You can get information about a request by interrogating an instance of the Request object. See Getting Information about Requests.
The class oracle.apps.cz.cio.Request exposes logic requests. A Request object can be used to represent several kinds of requests.
The Request object provides a set of methods for determining the value of the request, and the runtime node on which the request has been made:
getNumericValue()
getValue()
getRuntimeNode()
The Request object also provides a set of methods for determining the type of the request. These methods are listed in the table Type Methods of the Class Request. (In the value column, the test for the value of the request is case-sensitive.)
| This returns TRUE if ... | ... the request made was for ... | The value of the request is ... |
|---|---|---|
| isNumericRequest() | changing the numeric value of a runtime node | a Number |
| isStateRequest() | changing the state of a runtime node | True, False, Toggle, Tnknown |
| isTrueStateRequest() | changing the state of a runtime node to True | True |
| isFalseStateRequest() | changing the state of a runtime node to False | False |
| isToggleStateRequest() | toggling the state of a runtime node | Toggle |
| isUnknownStateRequest() | unsetting the state of a runtime node | Unknown |
You can obtain a list of the Request objects that represent all current user requests in the system, by using the method Configuration.getUserRequests() in your Configurator Extension.
...
IRuntimeNode node = getRuntimeNode();
Configuration config = node.getConfiguration();
List requests = config.getUserRequests();
Iterator it = requests.iterator();
while (it.hasNext()) {
Request req = (Request)it.next();
IRuntimeNode node = req.getRuntimeNode();
String value = req.getValue();
}
...
You can specify a set of logic requests to be applied to a configuration at any time that have a higher priority than user requests. Such requests are called nonoverridable requests.
You apply nonoverridable requests automatically on the creation of a configuration, following the practice illustrated in Using Nonoverridable Requests and in the following steps:
Begin a configuration transaction, using Configuration.beginConfigTransaction().
ConfigTransaction tr = config.beginConfigTransaction();
See Using Logic Transactions for details about transactions.
Specify that the transaction contains nonoverridable requests, using ConfigTransaction.useNonOverridableRequests().
tr.useNonOverridableRequests();
Specify the desired user requests using the appropriate methods.
BooleanFeature feat = (BooleanFeature)node.getChildByName("Feature_1234");
feat.setState(IState.TRUE);
See User Requests for details about setting logic requests.
When you have set all the desired nonoverridable requests, commit the logic transaction.
config.commitConfigTransaction(tr);
These steps are combined in Using Nonoverridable Requests. For a fuller example of using nonoverridable requests, see Setting Nonoverridable Requests.
...
ConfigTransaction tr = config.beginConfigTransaction();
tr.useNonOverridableRequests();
BooleanFeature feat = (BooleanFeature)node.getChildByName("Feature_1234");
feat.setState(IState.TRUE);
config.commitConfigTransaction(tr);
...
You can think of a transaction that includes ConfigTransaction.useNonOverridableRequests() (as illustrated in Step 2) as putting the CIO in "nonoverridable request mode". You can nest any number of subtransactions within this transaction; the requests in these subtransactions all inherit this mode of being nonoverridable requests. You can perform overrides and rollbacks as you would with ordinary user requests. You must commit or roll back the nonoverridable-request transaction, as in Step 4, to indicate the conclusion of the nonoverridable requests. You can then specify other user requests in your Configurator Extension.
When you save a configuration that includes nonoverridable requests, the nonoverridable requests are saved as part of the configuration. When you restore such a configuration, with CIO.restoreConfiguration(), the nonoverridable requests are reapplied to the configuration.
You can get a list of the list of nonoverridable requests present in a configuration by using Configuration.getNonOverridableRequests().
In a nonoverridable transaction, you can retract a nonoverridable request by calling unset() on the appropriate runtime node.
After you apply nonoverridable requests to a configuration, you cannot override any of the nonoverridable requests with user requests. But you can override nonoverridable requests with other nonoverridable requests. An attempt to override a nonoverridable request with a user request throws a NonOverridableRequestException, which cannot be overridden.
You cannot use nonoverridable requests to add or delete components, or create a connection.
When you use LogicalOverridableException.override() to override a logical contradiction (see Overriding Contradictions), the override() method returns a List of Request objects. These Request objects represent all the previously asserted user requests that failed due to the override that you are performing.
See Getting a List of Failed Requests for an example.