We have talked about defining a business object. This section describes how business objects are used throughout the system to view, add and update records.
Various parameters for zones that are used to display data in the system include support for retrieving data by referencing a business object. The zone code will “invoke” the BO, meaning that the record will be retrieved using the referenced BO.
The system’s scripting language includes a step type to “invoke BO”. This allows for BPA scripts, service scripts and plug-in scripts to retrieve information and add or update records using BO interaction.
Inbound web services may reference a business object in its operations collection. This allows external systems to add or update records in our product via web service interaction.
Often when configuring a zone or writing a script, the BO to use in the “invoke BO” statement should be the identifying BO of the record. As such, often the script will include steps prior to the “invoke BO” step to “determine the identifying BO of the record” and once the identifying BO is found, the script step will invoke that BO. Note that zones and inbound web services reference a BO directly. In each case, if the BO to use should be dynamic, then the zone / inbound web service should reference a service script that can perform the steps to identify the BO and then invoke that BO.
It should be noted however that the BO used in an “invoke BO” statement (or referenced in an inbound web service) does not have to match the identifying BO for the record. Here are some examples of where this may be true:
A script may only require a subset of elements for a record and not the entire record. In this case, it is better for performance purposes to define a special BO (sometimes called a “lite” BO or a “mini” BO) that only defines the needed elements. When the system retrieves the data, it will only access the tables that are included in the BO’s schema definition. In addition, if there are no elements that map to an XML structure field, the system will skip any parsing of that column. Similarly, if a script is updating a subset of elements on a record, it may be beneficial to use a “mini” BO to do the updates.
The maintenance object to be added or updated in a script may not support business objects as “identifying BOs”. For example, Batch Control maintenance object does not have an identifying BO. However, scripts may still wish to retrieve data (or make updates) to these types of records. An easy way to achieve that goal is to define a business object and use “invoke BO” to access the data.
Some functionality may be trying to add or update records for a maintenance object in a ‘physical’ manner and do not want or need to use the object’s identifying BO. Or the MO may not have an identifying BO. For example, revision control takes a snapshot of a record for audit purpose and to be able to restore a previous version. In this case, the system wants to capture a full “physical” view of the record. To do this, a special “physical” BO may be created that includes all (or most of) the columns and the child tables.
Copyright © 2007, 2016, Oracle and/or its affiliates. All rights reserved. Documentation build: 2.5.2016 10:21:45 [T1_1454696505000]