Configuration Tools
This section describes tools to facilitate detailed business configuration. The configuration tools allow you to extend both the front-end user interface as well as create and define specialized back-end services. Note that the tools described here are controlled completely by meta-data – no programming required!
This section provides an overview of business objects and describes how to maintain them.
Contents
The Big Picture of Business Objects
The Big Picture of Business Objects
The topics in this section describe background topics relevant to business objects.
Contents
A Business Object Has Properties
A Business Object May Define Business Rules
Each Business Object Can Have A Different Lifecycle
Audit Changes To A Business Object
Granting Access To Business Objects
What Is A Business Object?
The fundamental idea behind a business object is that it should closely match the end user's conception of an object (e.g.; the specific information used to define a customer). This is in marked contrast to an application developer's notion of an object (e.g.; the normalized database tables used to capture generic person information). The business object configuration tool described here is a bridge between the two notions; a business object maps the end user's concept of an object to the physical database structures, and services, used to maintain the information. In other words, a business object is typically a simplification of the maintenance object.
Customer – as a Business Object
Customer – as Defined in the Database
Another definition of a business object is a structure that allows an implementation to define a simpler view of a maintenance object. For example, a tax management COTS team can set up business objects for individual taxpayer, corporation, and partnership all as simpler views of the Person maintenance object. Yet another use of business objects is for managing market messages: separate business objects can be defined for a multitude of market messages, all of which belong to a single market message MO.
A Business Object Has Properties
A business object has properties (AKA, elements). Properties such as “Social Security Number” and “Home Phone” are applicable to an individual taxpayer, whereas “Corporate Name” is applicable to a corporation. The structure of a business object is defined using an XML schema. The purpose of the schema is to describe the business object's properties and map them to the corresponding maintenance object fields.
Customer - Business Object Schema (partial)
Keep in mind that many maintenance objects have child table collections (e.g., a collection of phone numbers, or a collection of characteristics on an account) and therefore the definition of where a property resides can be sophisticated. For example, defining a business object property like "Name" requires the implementer to define:
· The child table on the maintenance object that holds names (e.g., CI_PER_NAME)
· The unique identifier of the instance of the collection in which the value resides (e.g., where Name Type Flag = PRIM(ary))
· The name of the field in which the property resides (e.g., ENTITY_NAME)
Flatten. We use the terms "flattening" and "flatten out" to describe a business object property that resides in a collection but is defined as a singular element.
Some maintenance objects allow data to be stored as an XML structure field (CLOB) with the entity. Business object properties may reside in the MO's XML extension. You will typically map business object properties to an MO XML extension when the property does not have to be exposed for SQL indexing or joining (e.g., most fields on a tax form or the elements in a market message).
CLOB is only for non-indexed / joined fields! We'd like to stress that putting properties in an XML document (CLOB) field should only be done for properties that will never be indexed or joined in an SQL statement. If you need to "join" to a property you must map it to an indexed field, like a characteristic, rather than to the CLOB. This is because databases do not commonly support indexes for elements in a CLOB field (at least not today).
Schema Definition Tips. A context sensitive "Schema Tips" zone appears when you open the Business Object page to assist you with the schema definition syntax. The zone provides a complete list of the XML nodes and attributes available to you when you construct a schema.
XAI incoming messages and scripts support interaction with business objects. It is also possible to interact with business objects directly from a Java class.
A Business Object May Define Business Rules
A business object may define business rules that govern the behavior of entities of this type. Simple element-level validation is supported by schema attributes. For more sophisticated rules you create algorithms and associate them with your business object.
There are several different types of algorithms that can be set up and you can have more than one of each type. For example, you may create a Post-Processing algorithm if you need to perform additional steps such as creating a To Do Entry or add a log record as part of the business object logical transaction. Refer to Business Object - Algorithms for more information on the various types of algorithms you can define.
The system applies business object rules (schema based and algorithms) whenever a business object instance is added, changed or deleted. This is only possible when the call is made via the maintenance object service. For example, when made via business object interaction, XAI services, the MO’s maintenance page, etc. In addition the system must be able to determine the business object associated with the actual object being processed. To do that the Maintenance Object itself has to have a Determine BO algorithm plugged in. If the business object cannot be determined for a maintenance object instance business object rules are not applied.
Direct entity updates bypass business rules! As mentioned above, it is the maintenance object service layer that applies business object rules. Processes that directly update entities not via the maintenance object service bypass any business object rules you may have configured.
Business Object Inheritance
A business object may inherit business rules from another business object by referencing the latter as its parent. A child business object can also have children, and so on. A parent’s rules automatically apply to all of its children (no compilation – it's immediate). A child business object can always introduce rules of its own but never remove or bypass an inherited rule.
The following is an illustration of multiple levels of business object inheritance.
Notice how the “Business Customer” business object extends its parent rules to also enforce a credit history check on all types of customers associated with its child business objects.
Most types of business object system events allows for multiple algorithms to be executed. For example, you can have multiple Validation algorithms defined for a business object. For these, the system executes all algorithms at all levels in the inheritance chain starting from the highest-level parent business object moving on to lower levels.
Other types of system events allows for a single algorithm to be executed. For example, you can only have one Information algorithm to format the standard description of a business object instance. For these, the system executes the one at the level nearest to the business object currently being processed.
Note. The parent and its children must reference the same maintenance object.
Data structures are not inherited. While you can declare schemas on parent business objects, their children will not inherit them. A good practice is to design child business object schemas to include their parent business object's schema.
Use Inheritance Wisely. While it is intellectually attractive to abstract behavior into parent BOs to avoid redundant logic and simplify maintenance, before doing this weigh the reuse benefits against the cost in transparency, as it is not easy to maintain a complex hierarchy of business objects.
Each Business Object Can Have A Different Lifecycle
Many maintenance objects have a status column that holds the business entity’s current state within its lifecycle. Rules that govern lifecycle state transition (e.g., what is its initial state, when can it transition to another state, etc.) and the behavior associated with each state are referred to as lifecycle rules. Older Maintenance Objects, such as To Do Entry, have predefined lifecycles whose rules are governed by the base-package and cannot be changed. The lifecycle of newer Maintenance Objects exists in business object meta-data and as such considered softly defined. This allows you to have completely different lifecycle rules for business objects belonging to the same maintenance object.
Here are examples of two business objects with different lifecycles that belong to the same maintenance object.
Note. A Maintenance Object supports soft lifecycle rules if it is defined with a Status Field Maintenance Object option.
The topics that follow describe important lifecycle oriented concepts.
Contents
Valid States versus State Transition Rules
One Initial State and Multiple Final States
Keeping An Entity In Its Last Successful State
Required Elements Before Entering A State
Valid States versus State Transition Rules
The boxes in the above diagram show the potential valid states a business entity of the above business object can be in. The lines between the boxes indicate the state transition rules. These rules govern the states it can move to while in a given state. For example, the above diagram indicates a high bill complaint that's in the Lodged state can be either Canceled or moved into the Preliminary Investigation state.
When you set up a business object, you define both its valid states and the state transition rules.
One Initial State and Multiple Final States
When you set up lifecycle states, you must pick one as the initial state. The initial state is the state assigned to new entities associated with the business object. For example, the above high-bill complaint business object defines an initial state of Lodged, whereas the literature request one defines an initial state of Literature Sent.
You must also define which statuses are considered to be "final". Typically when an entity reaches a "final" state, its lifecycle is considered complete and no further processing is necessary.
Allowing An Entity To Be “Reopened”. You can set up your state transition rules to allow a business entity to be “reopened” (i.e., to be moved from a final state to a non-final state). Neither of the above examples allows this, but it is possible if you configure your business object accordingly.
State-Specific Business Rules
For each state in a business object's lifecycle, you can define the following types of business rules.
Contents
Logic To Take Place When Entering A State
Logic To Take Place When Exiting A State
Logic To Take Place When Entering A State
You can define algorithms that execute before a business entity enters a given state. For example, you could develop an algorithm that requires a cancellation reason before an entity is allowed to enter the Canceled state.
You can also incorporate state auto-transitioning logic within this type of algorithms. Refer to auto-transition for more information.
Logic To Take Place When Exiting A State
You can define algorithms that execute when a business entity exists a given state. For example, you could develop an algorithm that clears out error messages when a given entity exits the Error state.
You can define algorithms to monitor a business entity while it is in a given state. This type of logic is typically used to check if the conditions necessary to transition the entity to another state exist (and, if so, transition it). For example, transition an entity to the Canceled state if it's been in the Error state too long. Another common use is to perform ancillary work while an entity is in a given state. For example, update statistics held on the object while it's in the Active state.
Monitor algorithms are invoked when a business entity first enters a state and periodically after that in batch. You have the option to defer the monitoring of a specific state until a specific monitoring batch job runs. You do so by associating the state with a specific monitoring process. In this case the system will only execute the monitoring rules of this state when that specific batch process runs. This may be useful for example in a market-messaging world where you do not want an inbound message processed when it is received; rather, you want to wait until a later point in time (maybe at the end of the day).
A monitor algorithm can carry out any business logic. In addition it can optionally tell the system to do either of the following:
· Stop monitoring and transition to another state. The system will not call any further monitoring algorithm plugged in on the state and attempt to transition the entity to the requested new state.
· Stop monitoring. Same as above except that no transition takes place. You may want to use this option to prevent transitions while some condition is true.
If none of the above is requested the system keeps executing subsequent monitoring algorithms.
Refer to Business Object - Lifecycle for more information on how to set up state-specific algorithms.
Inheriting Lifecycle
If a business object references a parent business object, it always inherits its lifecycle from the highest-level business object in the hierarchy. In other words, only the highest-level parent business object can define the lifecycle and the valid state transitions for each state. Child business objects, in all levels, may still extend the business rules for a given state by introducing their own state-specific algorithms.
The system executes all state-specific algorithms at all levels in the inheritance chain starting from the highest-level parent business object moving on to lower levels.
Auto-Transition
In a single transition from one state to another, the system first executes the Exit algorithms of the current state, transitions the entity to the new state, executes the Enter algorithms of the new state followed by its Monitor algorithms. At this point if a Monitor algorithm determines that the entity should be further automatically transitioned to another state the remaining monitoring algorithm defined for the current state are NOT executed and the system initiates yet another transition cycle.
Notice that an Enter algorithm can also tell the system to automatically transition the entity to another state. In this case the remaining Enter algorithm as well as all Monitor algorithms defined for the current state are NOT executed.
The following illustration provides an example of an auto-transition chain of events.
In this example a business entity is in a Pending state. While in that state a Monitor algorithm determines to auto-transition it to the Denied state. At this point the following takes place:
· No further Monitor algorithms of the Pending state are executed
· Pending state Exit algorithms are executed
· The system transitions the entity to the Denied state
· Denied state Enter algorithms are executed. No further auto-transition is requested.
· Denied state Monitor algorithms are executed. No further auto-transition is requested.
Keeping An Entity In Its Last Successful State
By default, any error encountered while transitioning a business entity from one state to another rolls back ALL changes leaving the entity in its original state.
When applicable, the Maintenance Object can be configured to always keep an entity in its last successful state rather than rolling all the way back to the original state. This practice is often referred to as “taking save-points”. In case of an error, the entity is rolled back to the last successfully entered state and the error is logged on the maintenance object’s log. Notice that with this approach no error is returned to the calling process, the error is just logged!
The logic to properly log the error is in a Transition Error Maintenance Object plug-in. The system considers a maintenance object to practice “save-points” when such an algorithm is plugged into it.
Even if the maintenance object practices “save-points”, in case of an error the system will not keep an entity in the last successfully entered state if that state is either marked as transitory or one of its Enter algorithms has determined that the entity should proceed to a next state. The system will roll back to the first previous state that does not match these conditions.
Monitoring Batch Processes
The base package provides a periodic monitoring batch process for each maintenance object that supports soft state transition. The process periodically executes the monitoring algorithms associated with the current state of an entity, excluding states explicitly referencing a deferred monitoring batch process.
A deferred monitoring process works in the same way but only considers entities whose current state references this particular batch control as their monitor process. Deferred monitoring is only needed for certain states based on business requirements.
Your business rules will dictate the execution frequency of each monitoring process and the order in which they should be scheduled.
MO Option. The maintenance object options identify the periodic monitor process or deferred monitor process supplied in the base product for an MO, if applicable.
Transitory States
You can define a state as Transitory if you do not wish the business entity to ever exist in that particular state.
The following illustrates a lifecycle with a transitory Validate state.
In this example, the business entity is saved still not validated in the Pending state. At some point, the user is ready to submit the entity for validation and transitions it into a transitory state Validate whose Enter rules contain the validation logic. The responsibility of the transitory state's Enter algorithms is to decide if the entity is valid or in error and then transitions it into the appropriate final state. In this scenario, you may not ever want the business entity to exist in the Validate state.
Let’s also assume that the maintenance object in this example is practicing “save-points” and requires the entity to be kept in its last successful state. If an error were to occur during the transition from Validate to the next state, the system would roll back the entity back to Pending, and not Validate even though the entity has successfully entered the Validate state. Refer to the Auto Transition section for more information.
State Transitions Are Audited
Most Maintenance Objects that support soft lifecycle definition also have a log to hold significant events throughout a business entity’s lifecycle. For example, log entries are created to record:
· When the business entity is created (and who created it)
· When its status changes (and who changed it)
· If a transition error occurred (and the error message)
· References to other objects created throughout the entity’s lifecycle. For example, if a To Do entry is created as part of processing the entity, the To Do Entry is referenced in the log.
· Manual entries added by a user (think of these as "diary" entries)
When a business entity is first created and when it transitions into a new state the system calls Transition algorithm(s) plugged in on the Maintenance Object to record these events. If the maintenance object supports a log these events can be captures as log entries.
Note. Most base package maintenance objects supporting a log may already provide state transition logging as part of their core logic. In this case you only need to provide a Transition plug-in if you wish to override base logging logic with your own.
Required Elements Before Entering A State
You can define additional elements that are required before a business entity can enter a given state. For example, let's assume that a Cancel Reason must be defined before an object can enter the Canceled state. You do this by indicating that element as a Required Element state-specific option on the appropriate state on the business object.
Audit Changes To A Business Object
You can configure a business object to audit any change made to entities of this type. Any time a business entity is added, changed or deleted the system detects and summarizes the list of changes that took place in that transaction and hands it over to Audit plug-ins associated with the business object. It is the responsibility of such algorithms to log the changes if and where appropriate. Refer to BO algorithms for more information on this type of algorithm.
By default all elements of the business object are subject to auditing. You can however mark certain elements to be excluded from the auditing process using the noAudit schema attribute. Marking an element as not auditable will prevent it from ever appearing as a changed element in the business object's audit plug-in spot. Refer to the “Schema Tips” context sensitive zone associated with the Business Object maintenance page for more information on this attribute.
Granting Access To Business Objects
Every business object must reference an application service. When you link a business object to an application service, you are granting all users in the group access to its instances. You can prevent users from transitioning a business object into specific states by correlating each business object status with each application service action (and then don't give the user group rights to the related action).
Refer to The Big Picture Of Application Security for information about granting users access rights to an application service.
The system checks if a user has access rights each time the application is invoked to add, change, delete, read, or transition a business object. However, if a business object invokes another business object, we assume that access was controlled by the initial business object invocation and we do not check access for other business objects that it invokes. In other words, access rights are only checked for the initial business object invoked in a service call.
In order to apply business object security the system must be able to determine the business object associated with the actual object being processed. To do that the Maintenance Object itself has to have a Determine BO algorithm plugged in. If this algorithm is not plugged in or it can not determine the BO on the MO, the system will NOT invoke any BO rules If the business object can not be determined for a maintenance object instance business object security is not checked. In this case the system checkd the user’s access rights using standard maintenance object security.
Parent business objects are ignored. If a child business object exists, a user need only have access to the child business object's application service (not to every application service in the business object hierarchy).
Defining Business Objects
The topics in this section describe how to maintain business objects.
Business Object - Main
Use this page to define basic information about a business object. Open this page using Admin Menu, Business Object.
Description of Page
Enter a unique Business Object name and Description. Use the Detailed Description to describe the purpose of this business object in detail. Ownerindicates if this business object is owned by the base package or by your implementation (Customer Modification).
Important! If you introduce a new business object, carefully consider its naming convention. Refer to System Data Naming Convention for more information.
Enter the Maintenance Object that is used to maintain objects of this type.
Enter a Parent Business Object from which to inherit business rules.
Lifecycle Business Object is only displayed for child business objects, i.e. those that reference a parent business object. It displays the highest-level business object in the inheritance hierarchy. Refer to Inheriting Lifecycle for more information.
Application Service is the application service that is used to provide security for the business object. Refer to Granting Access To Business Objects for more information. The application service on the child business object must have the same valid actions as the application service on the parent business object.
Use Instance Control to allow or prevent new entities from referencing the business object.
The optionsgrid allows you to configure the business object to support extensible options. Select the Option Type drop-down to define its Value. Detailed Description may display additional information on the option type. Set the Sequence to 1 unless the option can have more than one value. Ownerindicates if this option is owned by the base package or by your implementation (Customer Modification).
You can add new options types. Your implementation may want to add additional option types. For example, your implementation may have plug-in driven logic that would benefit from a new option. To do that, add your new values to the customizable lookup field BUS_OBJ_OPT_FLG. If you add a new option type for a business option, you must update its maintenance object to declare this new option type. Otherwise, it won't appear on the option type dropdown. You do that by referencing the new option type as a Valid BO Option Type maintenance object option.
Click the View MO hyperlink to view the maintenance object in the Maintenance Object Viewer. You may find it useful to leave the application viewer window open while defining your business object schema.
Click on the View Schema hyperlink to view the business object's expanded schema definition. Doing this opens the schema viewer window.
Where Used
Follow this link to open the data dictionary to view the tables that reference F1_BUS_OBJ.
Business Object - Schema
Use this page to maintain a business object's schema. Open this page using Admin Menu, Business Object and then navigate to the Schema tab.
Description of Page
The contents of this section describe the zones that are available on this portal page.
The General Information zone displays main attributes of the business object.
The Schema Editor zone allows you to edit the business object's schema. The purpose of the schema is to describe the business object's properties and map them to corresponding maintenance object fields.
Schema Definition Tips. A context sensitive "Schema Tips" zone is associated with this page. The zone provides a complete list of the XML nodes and attributes available to you when you construct a schema.
Business Object - Algorithms
Use this page to maintain a business object's algorithms. Open this page using Admin Menu, Business Object and then navigate to the Algorithms tab.
Description of Page
The Algorithms grid contains algorithms that control important functions for entities defined by this business object. You must define the following for each algorithm:
· Specify the System Event with which the algorithm is associated (see the table that follows for a description of all possible events).
· Specify the Sequence Number and Algorithm for each system event. You can set the Sequence Number to 10 unless you have a System Event that has multiple Algorithms. In this case, you need to tell the system the Sequence in which they should execute.
· If the algorithm is implemented as a script, a link to the Script is provided. Refer to Plug-In Scripts for more information.
· Ownerindicates if this is owned by the base package or by your implementation (Customer Modification).
The following table describes each System Event.
|
System Event |
Optional / Required |
Description |
|
Audit |
Optional |
Algorithms of this type may be used to audit certain changes made to business object instances. The system hands over to the algorithms a summary of all the elements that were changed throughout a specific call to update an object. Excludes from this processing are elements explicitly marked on the schema as requiring no audit. For each element its original value before the change as well as its new value are provided. It is the responsibility of the algorithms to record corresponding audit information, typically on the business event log. The system invokes all algorithms of this type defined on the business object’s inheritance hierarchy. Refer to Business Object inheritance for more information. Click here to see the algorithm types available for this system event. |
|
Information |
Optional |
We use the term “Business Object Information” to describe the basic information that appears throughout the system to describe an entity defined by the business object. The data that appears in this information description is constructed using this algorithm. The system invokes a single algorithm of this type. If more than one algorithm is plugged-in the system invokes the one with the greatest sequence number found on the business object closest to the current business object in the inheritance hierarchy. Refer to Business Object inheritance for more information. Click here to see the algorithm types available for this system event. |
|
Post-Processing |
Optional |
Algorithms of this type may be used to perform additional business logic after a business object instance has been processed. The system invokes all algorithms of this type defined on the business object’s inheritance hierarchy. Refer to Business Object inheritance for more information. Click here to see the algorithm types available for this system event. |
|
Pre-Processing |
Optional |
Algorithms of this type further populates a request to maintain a business object instance right before it is processed. The system invokes all algorithms of this type defined on the business object’s inheritance hierarchy. Refer to Business Object inheritance for more information. Click here to see the algorithm types available for this system event. |
|
Validation |
Optional |
Algorithms of this type may be used to validate a business object instance when added, updated or deleted. The system invokes all algorithms of this type defined on the business object’s inheritance hierarchy. Refer to Business Object inheritance for more information. Click here to see the algorithm types available for this system event. |
You can add new system events. Your implementation may want to add additional business object oriented system events. For example, your implementation may have plug-in driven logic that would benefit from a new system event. To do that, add your new values to the customizable lookup field BO_SEVT_FLG. If you add a new business object system event, you must update the maintenance object to declare this new system event. Otherwise, it won't appear on the system event dropdown. You do that by referencing the new system event as a Valid BO System Event maintenance object option.
Business Object - Lifecycle
Use this page to maintain a business object's lifecycle oriented business rules and options. Open this page using Admin Menu, Business Object and then navigate to the Lifecycle tab.
Description of Page
The Status accordion contains an entry for every status in the object's lifecycle. The entry appears differently for a child business object as it can only extend its inherited lifecycle by introducing algorithms and options of its own.
Use Status to define the unique identifier of the status. This is NOT the status's description, it is simply the unique identifier used by the system. Only the highest-level business object can define lifecycle statuses. For a child business object the inherited status description is displayed allowing navigation to the corresponding entry on the business object defining the lifecycle.
Use Description to define the label of the status. This field is hidden for a child business object.
Use Access Mode to define the action associated with this status. Refer to Access Rights for the details of how to use this field to restrict which users can transition a business entity into this state. This field is hidden for a child business object.
Enter a Monitor Process to defer the monitoring of entities in this state until the specific batch process runs. Refer to Monitor Rules for more information. This field is hidden for a child business object.
Use Status Condition to define if this status is an Initial, Interim or Final state. Refer to One Initial State and Multiple Final States for more information about how this field is used. This field is hidden for a child business object.
Use Transitory State to indicate whether a business entity should ever exist in this state. Only Initial or Interim states can have a transitory state value of No. Refer to transitory states for more information. This field is hidden for a child business object.
Use Alert Flag to indicate that being in this state warrants an application alert. This may be used by custom logic to provide an alert to a user that entities exist in this state. This field is hidden for a child business object.
Use Display Sequence to define the relative order of this status for display purposes. For example when displayed on the status accordion and on the summary tab page. This field is hidden for a child business object.
Algorithms
The Algorithms grid contains algorithms that control important functions for a given status. You must define the following for each algorithm:
· Specify the System Event with which the algorithm is associated (see the table that follows for a description of all possible events).
· Specify the Sequence Number and Algorithm for each system event. You can set the Sequence Number to 10 unless you have a System Event that has multiple Algorithms. In this case, you need to tell the system the Sequence in which they should execute.
· If the algorithm is implemented as a script, a link to the Script is provided. Refer to Plug-In Scripts for more information.
· Ownerindicates if this is owned by the base package or by your implementation (Customer Modification).
The following table describes each System Event.
|
System Event |
Optional / Required |
Description |
|
Enter |
Optional |
Algorithms of this type apply business rules when a business object instance enters a given state. The system invokes all algorithms of this type defined on the business object’s inheritance hierarchy. Refer to Business Object Inheritance for more information. Click here to see the algorithm types available for this system event. |
|
Exit |
Optional |
Algorithms of this type apply business rules when a business object instance exits a given state. The system invokes all algorithms of this type defined on the business object’s inheritance hierarchy. Refer to Business Object Inheritance for more information. Click here to see the algorithm types available for this system event. |
|
Monitor |
Optional |
Algorithms of this type monitor a business object instance while in a given state. Typically these are used to auto-transition it to another state. The system invokes all algorithms of this type defined on the business object’s inheritance hierarchy. Refer to Business Object Inheritance for more information. Click here to see the algorithm types available for this system event. |
Next Statuses
Use the Next Statuses grid to define the valid statuses a business entity can transition into while it's in this state. This section is hidden for a child business object. Refer to Valid States versus State Transition Rules for more information. Please note the following about this grid:
· Status shows the statuses for the top-level business object, the Status Code, the Lifecycle BO description, and the Status description for each status.
· Use Action Label to indicate the verbiage to display on the action button used to transition to this status.
· Sequence controls the relative order of one status compared to others for display purposes. This information may be used to control the order in which action buttons are presented on a user interface.
· Default controls which next state (if any) is the default one. This information may be used by an Enter or Monitor algorithm to determine an auto-transition to the default state. It may also be used to also mark the associated button as the default one on a user interface.
· Transition Condition may be configured to identify a common transition path from the current state. By associating a given “next status” with a transition condition value, you can design your auto-transition rules to utilize those flag values without specifying a status particular to a given business object. Thus, similar logic may be used across a range of business objects to transition a business entity into, for example, the next Ok state for its current state. You’ll need to add your values to the customizable lookup field BO_TR_COND_FLG.
· Transition Role controls whether only the System or both System and User have the ability to transition a business entity into a given “next status”.
· When you initially set up a business object lifecycle, none of the statuses will reside on the database and therefore you can't use the search to define a "next status". We recommend working as follows to facilitate the definition of this information:
· Leave the Next Statuses grid blank when you initially define a business object's statuses
· After all statuses have been saved on the database, update each status to define its Next Statuses (this way, you can use the search to select the status).
Options
The optionsgrid allows you to configure the business object status to support extensible options. Select the Option Type drop-down to define its Value. Detailed Description may display additional information on the option type. Set the Sequence to 1 unless the option can have more than one value. Ownerindicates if this option is owned by the base package or by your implementation (Customer Modification).
You can add new options types. Your implementation may want to add additional option types. For example, your implementation may have plug-in driven logic that would benefit from a new option. To do that, add your new values to the customizable lookup field BO_OPT_FLG. If you add a new option type for a status, you must update the business object’s maintenance object to declare this new option type. Otherwise, it won't appear on the option type dropdown. You do that by referencing the new option type as a Valid BO Status Option Type maintenance object option.
Business Object - Summary
This page summarizes business object information in a high level. Open this page using Admin Menu, Business Object and then navigate to the Summary tab.
Description of Page
The contents of this section describe the zones that are available on this portal page.
The General Information zone displays main attributes of the business object.
The Options zone summarizes business object and state specific options throughout the inheritance chain.
The Rules zone summarizes business object and state specific rules throughout the inheritance chain.
The Schema Usage Tree zone summarizes all cross-references to this schema. These may be other schemas, scripts, and XAI Inbound Services. For each type of referencing entity, the tree displays a summary node showing a total count of referencing items. The summary node appears if at least one referencing item exists. Expand the node to list the referencing items and use their description to navigate to their corresponding pages.
The Business Object Hierarchy zone displays in a tree view format the hierarchy of child business object associated with the current business object. It also shows the current business object’s immediate parent business object.
In the same way that a business object is used to simplify a maintenance object, a business service can be used simplify a back-end service. The rating engine is a good example of a complex back-end service because it must satisfy a vast array of differing requirements. However, it is also true that the actual data required for a specific rating task can be quite simple. For example, if your script must calculate a simple cost per ton: you can pass the rating engine just a single service quantity and receive a calculated amount back.
Business services define alternative services to our internal services that are easier to work with. A Business Service provides a “simpler” data interface thus making interaction with the actual service easier. For example, it may flatten out complex collections and set up default values for other pieces of information (like a rate schedule).
Weight Calculation Business Service
Rate Application Service (about 30% of actual service)
As with the business object, the business service's interface to the internal service is defined using its schema. The schema maps the business service's elements to the corresponding elements in the internal service program's XML document. Keep in mind that many back-end services have child table collections (e.g., a collection of input service quantities, or a collection of output bill lines) and therefore the definition of where a business service property resides can be sophisticated. For example, defining a business service property like "Weight" requires the implementer to define:
· The collection on the business service that holds service quantities (e.g., SQ)
· The unique identifier of the instance of the collection in which the value resides (e.g., where SQI Code = TONS)
· The name of the field in which the property resides (e.g., SQI_CD)
Weight Charge Schema
Flatten. We use the terms "flattening" and "flatten out" to describe a business service property that resides in a collection but is defined as a singular element.
Schema Definition Tips. A context sensitive "Schema Tips" zone appears when you open the Business Service page to assist you with the schema definition syntax. The zone provides a complete list of the XML nodes and attributes available to you when you construct a schema.
XAI incoming messages and scripts support interaction with business services. You can also invoke a business service from a Java class.
Defining Business Services
The topics in this section describe how to maintain business services.
Contents
Business Service - Main
Use this page to define basic information about a Business Service. Open this page using Admin Menu, Business Service.
Description of Page
Enter a unique Business Service name and Description. Use the Detailed Description to describe the purpose of this business service in detail. Ownerindicates if the business service is owned by the base package or by your implementation (Customer Modification).
Important! If you introduce a new business service, carefully consider its naming convention. Refer to System Data Naming Convention for more information.
Enter the internal Service Name being called when this business service is invoked.
Click the View XML hyperlink to view the XML document used to pass data to and from the service in the Service XML Viewer. You may find it useful to leave the application viewer window open while defining your business service schema.
XML document may not be viewable. If you create a new page service and do not regenerate the application viewer, you will not be able to view its XML document.
Click on the View Schema to view the business service's expanded schema definition. Doing this opens the schema viewer window.
Where Used
Follow this link to open the data dictionary to view the tables that reference F1_BUS_SVC.
Business Service - Schema
Use this page to maintain a Business Service's schema and to see where the Business Service is used in the system. Open this page using Admin Menu, Business Service and then navigate to the Schema tab.
Description of Page
The contents of this section describe the zones that are available on this portal page.
The General Information zone displays main attributes of the business service.
The Schema Editor zone allows you to edit the business service's schema. The purpose of the schema is to map the business service's elements to the corresponding fields of the backend service program it rides on.
Schema Definition Tips. A context sensitive "Schema Tips" zone is associated with this page. The zone provides a complete list of the XML nodes and attributes available to you when you construct a schema.
The Schema Usage Tree zone summarizes all cross-references to this schema. These may be other schemas, scripts, and XAI Inbound Services. For each type of referencing entity, the tree displays a summary node showing a total count of referencing items. The summary node appears if at least one referencing item exists. Expand the node to list the referencing items and use their description to navigate to their corresponding pages.
The User Interface (UI) map holds HTML to be rendered within portal zones and Business Process Assistant (BPA) scripts. UI maps allow your implementation to create input forms and output maps that closely match your customer’s business practices. In other words, the UI Map is designed to facilitate the capture and display of your business objects and business services.
The UI map is a repository for a single HTML document paired with an XML schema where the schema defines the data that the HTML document displays and/or modifies. The UI Map HTML gives you the ability to craft the display by any method that an html document can support, including JavaScript and full CSS functionality.
Configuration tool support for UI Maps hinges around the ability to inject and extract an XML document from the HTML. For more information on the specialized support for HTML and JavaScript functionality – please refer to the HTML tips document (more on this below).
HTML to Display Customer Business Object
Customer HTML Rendered (Output Data for Zone)
UI maps are typically crafted as output tables when used in conjunction with portal zones – please refer to Map Zones for more information. When referenced within BPA scripts, UI maps are typically crafted as forms for the capture and update of data.
HTML Input Form Rendered (for BPA Script)
Portal zones can reference a UI map for the zone header. They may also utilize a UI map to define their filter area. This type of UI map is not a complete HTML document, but is instead configured as a UI Map "fragment".
UI Map Tips. A context sensitive "UI Map Tips" zone appears when you open the UI Map page to assist you with the HTML document and schema definition syntax. The "tips" describe methods to take advantage of the configuration tools, however, they are not an HTML reference.
Editing HTML. You can use a variety of HTML editors to compose your HTML, which you can then cut, and paste into your UI map. In addition, the zone provides a complete list of the XML schema nodes and attributes available to you when you construct the map's data schema.
Defining UI Maps
The topics in this section describe how to maintain UI Maps.
Contents
UI Map - Main
Use this page to define basic information about a user interface (UI) Map. Open this page using Admin Menu, UI Map.
Description of Page
Enter a unique Map name. Ownerindicates if the UI map is owned by the base package or by your implementation (Customer Modification).
Important! If you introduce a new UI map, carefully consider its naming convention. Refer to System Data Naming Convention for more information.
Use UI Map Type to indicate whether the map is a Complete HTML Document or an HTML Fragment. Portal zones can reference a UI map to describe a fragment of their HTML, for example the zone header or filter area. In this case the UI map is not a complete HTML document, but is instead configured as a UI Map "fragment".
How used. A context sensitive "UI Map Tips" zone is associated with this page to assist you with the HTML document definition syntax. Refer to the tips zone for more information on how to use fragment UI maps to construct portal zone HTML components.
Enter a Description. Use the Detailed Description to describe how this map is used in detail.
Click on the View Schema to view the UI map's expanded schema definition. Doing this opens the schema viewer window.
Use the Test UI Map hyperlink to render your html in a test window.
Testing your map. You can use the Test UI Map hyperlink to render your map's html. Importantly, the hyperlink also exercises the proprietary functionality that binds an xml element with an html element so you can get immediate feedback on your html syntax.
Where Used
Follow this link to open the data dictionary to view the tables that reference F1_MAP.
UI Map - Schema
Use this page to maintain a UI Map's HTML and schema and to see where the UI Map is used in the system. Open this page using Admin Menu, UI Map and then navigate to the Schema tab.
Description of Page
The contents of this section describe the zones that are available on this portal page.
The General Information zone displays main attributes of the UI Map.
The HTML Editor zone allows you to edit the HTML document of the map.
HTML Definition Tips. A context sensitive "UI Map Tips" zone is associated with this page to assist you with the HTML document definition syntax. The "tips" describe good ways to produce simple HTML, however, they are not an HTML reference. Note that you can use a variety of HTML editors to compose your HTML, which you can then cut and paste into your UI map.
Providing Help. A tool tip can be used to display additional help information to the user. This applies to section elements as well as individual elements on a map. Refer to the tips context sensitive zone for more information on how to enable and provide UI map help.
The Schema Editor zone allows you to edit the data schema part of the map. The purpose of the schema is to describe the data elements being displayed by the map.
Schema Definition Tips. The same "UI Map Tips" zone above also provides a complete list of the XML nodes and attributes available to you when you construct the map's data schema.
The Schema Usage Tree zone summarizes all cross-references to this schema. These may be other schemas, scripts, and XAI Inbound Services. For each type of referencing entity, the tree displays a summary node showing a total count of referencing items. The summary node appears if at least one referencing item exists. Expand the node to list the referencing items and use their description to navigate to their corresponding pages.
The data area has no business purpose other than to provide a common schema location for re-used schema structures. It exists solely to help eliminate redundant element declaration. For example, if you have multiple schemas that share a common structure, you can set up a stand-alone data area schema for the common elements and then include it in each of the other schemas.
Be aware that a stand-alone data area can hold elements that are mapped to true fields. For example, you might have 50 different types of field activities and all might share a common set of elements to identify where and when the activity should take place. It would be wise to declare the elements that are common for all in a stand-alone data area and then include it in the 50 field activity business objects.
It's strongly recommended that you take advantage of stand-alone data areas to avoid redundant data definition!
Dynamic inclusion! When the system renders a schema, all schemas included within it are expanded real-time. This means that any change you make to a data area will take affect immediately within all schemas it is referenced within.
Schema Definition Tips. A context sensitive "Schema Tips" zone appears when you open the Data Area page to assist you with the schema definition syntax. The zone provides a complete list of the XML nodes and attributes available to you when you construct a schema.
Defining Data Areas
The topics in this section describe how to maintain Data Areas.
Contents
Data Area - Main
Use this page to define basic information about a data area. Open this page using Admin Menu, Data Area.
Description of Page
Enter a unique Data Area name and Description. Use the Detailed Description to describe what this data area defines in detail. Ownerindicates if the data area is owned by the base package or by your implementation (Customer Modification).
Important! If you introduce a new data area, carefully consider its naming convention. Refer to System Data Naming Convention for more information.
Click on the View Schema to view the data area's expanded schema definition. Doing this opens the schema viewer window.
Where Used
Follow this link to open the data dictionary to view the tables that reference F1_DATA_AREA.
Data Area - Schema
Use this page to maintain a Data Area's schema and to see where the data area is used in the system. Open this page using Admin Menu, Data Area and then navigate to the Schema tab.
Description of Page
The contents of this section describe the zones that are available on this portal page.
The General Information zone displays the main attributes of the data area.
The Schema Editor zone allows you to edit the data area's schema. The purpose of the schema is to describe the structure and elements of the data area.
Schema Definition Tips. A context sensitive "Schema Tips" zone is associated with this page. The zone provides a complete list of the XML nodes and attributes available to you when you construct a schema.
The Schema Usage Tree zone summarizes all cross-references to this schema. These may be other schemas, scripts, and XAI Inbound Services. For each type of referencing entity, the tree displays a summary node showing a total count of referencing items. The summary node appears if at least one referencing item exists. Expand the node to list the referencing items and use their description to navigate to their corresponding pages.
The schema viewer shows a tree-view presentation of a schema in its expanded form.
The schema illustrates the structure to be used when communicating with the schema's associated object. The following takes place when a schema is expanded:
· If the schema definition includes references to other schemas, these references are replaced with the corresponding schema definitions.
· Also, if the schema definition contains private elements, they are omitted from this view.
Clicking on any node on the tree populates the text box on the top with the node's absolute XPath expression. You will find this feature very useful when writing scripts interacting with schema-based objects. Scripting often involves referencing elements in a schema-based XML document using their absolute XPath expression. You can use this feature on the schema viewer to obtain the XPath expression for an element and copy it over to your script.
Business Event Log may be viewed as a tool designed to capture any type of business event worth noting. You configure business objects to represent the various types of events your application calls for. The following type of details may be captured for each event:
· The business object representing the type of event.
· The date and time the event took place and who initiated it.
· The business entity for which this event is logged.
· Standard application message to describe the event.
· Additional context information that is available at the time of the event and varies for each type of event. The Business Event Log maintenance object supports a standard characteristics collection as well as an XML storage (CLOB) field. The event’s business object determines where each piece of information resides. Refer to Business Objects for more information.
One common type of event may be the audit of changes made to sensitive data, for example, tracking an address change. Whenever an entity associated with a business object is added, changed, or deleted the system summarizes the list of changes that took place in that transaction and hands them over to Audit business object algorithms to process. You may design such an algorithm to audit the changes as business event logs. Refer to business event auditing for more information.
Another type of event may be to track all inquiry activities against sensitive data. An inquiry activity may be viewed as the event in which a user has been presented with information on a certain zone or portal. In this case, you can configure the service script associated with retrieving the data to be displayed on a particular zone to also create an inquiry business event log capturing the zone, the requesting user, and key information about the data displayed.
You can also allow users to initiate business event logs to capture important notes about a business entity by exposing a BPA Script to invoke the event’s corresponding business object.
Bottom line is that any process can create a business event log by invoking the business object representing the appropriate type of event.
Where Used
Follow this link to open the data dictionary where you can view the tables that reference F1_BUS_EVT_LOG.