| Oracle® Real-Time Decisions Base Application Decision Management Installation and Configuration Guide Release 3.1.1 Part Number E28941-01 |
|
|
PDF · Mobi · ePub |
| Oracle® Real-Time Decisions Base Application Decision Management Installation and Configuration Guide Release 3.1.1 Part Number E28941-01 |
|
|
PDF · Mobi · ePub |
Terminology:
The term "reference implementation" is used in this chapter to refer to the specific Oracle RTD Decision Management application RTD for Marketing Optimization, released with Oracle RTD Base Application.
This chapter contains the following topics:
The following diagram shows the communications at runtime between the various components of Oracle RTD Decision Management after installation:
The Oracle RTD Decision Management application is an ADF based web application, which also leverages the Oracle RTD reports as JSP pages embedded in an IFrame. If Decision Center reports are enabled and single sign-on configured, the Decision Manager browser displays JSP pages from both the Oracle RTD Decision Management and the Oracle RTD applications.
Additionally, Oracle RTD makes web service (SOAP) calls from the Oracle RTD Decision Management application to the Oracle RTD workbench server to retrieve type restrictions and display the rule editor. These requests use the username and password that you configured in Section 1.4.3.5, "Storing Credentials to Enable Web Service Calls" for WebLogic or Section 1.5.2.5, "Storing Credentials to Enable Web Service Calls" for WebSphere.
The Oracle RTD Decision Management application accesses the Decision Management database using the credentials defined in the CLMDS JNDI datasource.
The Oracle RTD Decision Management Inline Service loaded in the Oracle RTD application accesses the Decision Management database to retrieve dynamic choices.
The Oracle RTD application accesses the Oracle RTD (SDDS) database using the credentials defined in the SDDS JNDI datasource.
This section contains the following topics:
Oracle RTD Decision Management applications are built and deployed using Decision Designer.
Decision Designer is the combination of design tools that include JDeveloper, ant, and the metadata files that you set up and used to create the Oracle RTD Decision Management application, as described in Chapter 1, "Installing Oracle RTD Decision Management."
You can use Decision Designer to make changes to the reference implementation, or to build your own application from scratch.
You can also use Decision Designer to further customize the behavior of Oracle RTD Decision Management applications by adding your own logic. You can do so in the model layer and the view controller layer. The two ways to achieve customization are through extensibility of the ADF Framework and through the Decision Manager templates. As an example, the rule to validate that a start date is less than an end date has been implemented through templates in the released application RTD for Marketing Optimization
The following diagram shows the components that are generated by Decision Designer.
The following diagram shows the main Decision Management metadata and database setup files, as released with Oracle RTD Base Application.
The folder clm\Build\metadata, also referred to generically as <metadata_modules_home>, contains metadata modules for different applications.
The folder clm\Build\metadata\ref contains the metadata for the reference implementation.
Within a metadata module, two files, config.xml and perspectives.xml, must be in the config subdirectory. And you can add as many files as you want in the main directory to configure choice groups, relationship types, and security.
The folder clm\Build\metadata\core contains the metadata module for the core application. Use the core application when you want to create your own application from scratch, it contains the strict minimum for an empty application and Inline Service.
Note:
In all the XML files, the characters "<" and ">" are effectively control characters, and must not be used to specify any metadata element values. For operators, for example, they must be replaced by "<"(instead of "<") and ">"(instead of ">").
This section contains the following topics:
config.xml contains general configuration settings:
Under a <config> node, the following settings are available:
<workbenchService> specifies the url of the Oracle RTD server running in the same host WebLogic server as Oracle RTD Decision Management. The url must contain the protocol (http or https), the host, and the port.
The host is therefore always localhost, but the port can change based on your configuration. If you followed the instructions in Chapter 1, "Installing Oracle RTD Decision Management," the default port is 7001 in a development WebLogic environment, 7003 in a production WebLogic environment, and 9080 in a WebSphere environment.
<inlineService> specifies the name of the Inline Service used to get type restrictions and Decision Center reports.
The deployment state must be the exact deployment state that you want to access, 5 by default.
<decisionCenter> specifies the base URL to access embedded Decision Center reports. Remove the <decisionCenter> node to hide the Decision Center reports in the user interface.
<ownership-mode> specifies the ownership mode for when a choice is edited in a project. The value can be:
off (the default)
The user does not become the owner of the choice when the user edits a choice, and the choice owner is not shown in the Decision Manager user interface.
on
The user becomes the owner of the choice when the user edits a choice, and the choice owner is shown in the Decision Manager user interface. Users can also see the owner in the Audit Trail without adding the Owner attribute on the page.
<display-name> specifies the name of the application as it appears on the login page and at the top of the main page.
<database-encoding>
The value of <database-encoding> depends on the database character set. Oracle RTD Decision Management uses database encoding to properly enforce byte length throughout the application.
You must specify the java character set, as defined in java.nio.charset.Charset. For example, for an Oracle database with charset AL32UTF8, the value of <database-encoding> must be UTF-8. UTF-8 is the default value, used when <database-encoding> is not specified in config.xml.
<enterpriseAppName> specifies the application name used when multiple applications are deployed into the same domain. The default value is clm.
<datasourceJNDIName> specifies the data source name used when multiple applications are deployed into the same domain. The default value is CLMDS.
<webAppContextRoot> specifies the context root used when multiple applications are deployed into the same domain. This element must start with "/", for example "/dm2". The default value is /dm.
Perspectives allow business users to view a subset of the choice group graph in the folder tree in the Decision Manager user interface.
For instance, the reference implementation contains the choice groups shown in the following choice group graph:
Four "general" - that is, unqualified - perspectives are defined on top of this graph:
Perspectives are defined in the file clm\Build\metadata\ref\config\perspectives.xml (you can modify this if you use a metatada.module different from ref).
perspectives.xml is made of a <perspectives> root node which contains multiple perspectives.
Note:
In this section, property entries shown in bold are required entries.
Properties of perspective:
name: the name of the perspective
description
If present in perspectives.xml, the description appears as the heading for the perspective in the left-hand Perspective panel of the Decision Manager user interface. It also provides the tool tip help information for Decision Manager users as they mouse hover over the perspective name either in the Perspective panel or the dropdown list of perspectives that is displayed by clicking the Perspectives list icon at the top of the Perspectives panel.
one root node
multiple level nodes (ordered)
A single root node can have multiple level nodes in sequence - which enables multiple folders to be visible in sequence under the root choice group in the Decision Manager user interface. Alternatively, to enable a hierarchical folder structure in the Decision Manager user interface, the level nodes under a root node can be nested.
For example, the associations Slot Type -> Creative, Slot-Type -> Slot can be represented through the following schematic:
<root ... "Slot Type"... > <level ... "Creative" ... /> <level ... "Slot" ... /> </root>
In the Decision Manager user interface, this provides a perspective panel display similar to the following (with showFolder=true):
On the other hand, a hierarchical association Channel -> Placement -> Slot can be defined with nested level nodes, as in the following schematic:
<root ... "Channel" ... >
<level ... "Placement" ... >
<level ... "Slot" ... />
</level>
</root>
In the Decision Manager user interface, this provides a perspective panel display similar to the following:
Properties of root:
choiceGroupId: the choice group that will be the root node of the tree
simpleViewCriteria (see later in this section)
viewCriteria (see later in this section)
Properties of level:
choiceGroupId: the choice group that will be the node of the tree at that level
relationshipTypeId: the relationship to follow between the previous level and this level
reversed: whether to follow the relationship from fromChoiceGroupId to toChoiceGroupId (reversed = false) or from toChoiceGroupId to fromChoiceGroupId (reversed = true, the default).
For the cardinalities *:1, *:0, *:*, and *:1..*, use reversed=true to display many child nodes under each node
showFolder
If showFolder=true, this shows a folder with the name of the relationship (when reversed=true, relationship types folder name is toName, when reversed=false, relationship types folder name is fromName)
If showFolder=false (the default value), this shows the children directly under the parent node without a folder.
simpleViewCriteria (see later in this section)
viewCriteria (see later in this section)
simpleViewCriteria and viewCriteria allow the application of a filter on which choices are displayed. You can specify multiple choices and the resulting filter will be the OR combination of all of them (that is, a choice will appear if it matches any of the criteria).
Properties of simpleViewCriteria:
attribute: the choice attribute to filter on (of the choice group defined by choiceGroupId for this root or level)
operator: the operator to use for filtering (see searchCriteriaOperator later in this section for a list of operators)
value: the value of the choice attribute to filter on
Example:
<perspective name="Draft Campaigns"> ...... <root choiceGroupId="Campaign"> <simpleViewCriteria attribute="approvalStatus" value="Draft"/>
Note:
To specify criteria for date attributes, the value must be in the format yyyy-mm-dd, such as in:
<simpleViewCriteria attribute="startDate" operator="AFTER" value="2012-11-25" />
Properties of viewCriteria:
name: the id of a criteria defined on the choice group of the same choiceGroupId as this root or level
You can put as many xml configuration files in the top-level application configuration folder (for the reference implementation, this is clm\Build\metadata\ref) as you wish.
These configuration files let you specify choice groups and relationship types between choice groups.
Relationship types are owned by one side. In other words, to add, edit or delete a relationship between two choices, the user must be able to lock the choice owning that relationship.
When defining choice groups, you also define all the attributes in each choice group and all the user interface views associated with displaying this choice group in the Decision Manager user interface.
When defining choice attributes, you can define which widget is used to display this attribute. Oracle RTD Decision Management automatically selects a default widget most appropriate for the attribute, but you can override that and specify a different widget.
For the purpose of defining objects and their attributes, projects are considered as choice groups in metadata. The only difference is that you cannot have relationship types between projects and other choice groups. You can define project attributes and project views similar to the way you describe choice group attributes and views. You can even have project attributes with type restrictions by having a choice group in your Inline Service with id Project.
Note: In the following lists, properties shown in bold mean that they are required.
Properties of choice groups:
id: the id of the choice group. It must match the id in the Inline Service
name: the name of the choice group. It will appear as such in the Decision Manager user interface
description: the description of the choice group.
searchSortOrder: the order in which this choice group will appear in the search dropdowns (sorted ascending based on this number)
If you do not put this property, then this choice group will not appear in the dropdowns
createSortOrder: the order in which this choice group will appear in the create dropdown (sorted ascending based on this number)
If you do not put this property, then this choice group will not appear in the dropdown
attributes: an array of attribute (see later in this section)
criteria: zero to many criteria used for perspective filtering (see later in this section)
Properties of attributes:
id: the id of the choice attribute. It must match the id in the Inline Service.
name: the name of the choice attribute. It will appear as such in the Decision Manager user interface.
description: the description of the choice attribute.This description will appear in tool tips in the user interface, and is a useful way to give advice to business users on how to enter values for this attribute.
searchCriteriaOperator: the operator used for the advanced search.
If you do not put this property, then this attribute will not show up in the advanced search (unless you use the Add Field dropdown).
Valid values for strings:
"<>" (Not equal to)
"NOTBETWEEN" (Not between)
"CONTAINS" (Contains)
"ISNOTBLANK" (Is not blank)
"=" (Equal to)
"<" (Less than)
">" (Greater than),
"ISBLANK" (Is blank)
"<=" (Less than or equal to)
">=" (Greater than or equal to)
"DOESNOTCONTAIN" (Does not contain)
"STARTSWITH" (Starts with),
"ENDSWITH" (End with)
"BETWEEN" (Between)
Valid values for dates:
"<>" (Not equal to)
"ISBLANK" (Is blank)
"ONORAFTER" (On or after)
"BEFORE" (Before)
"NOTBETWEEN" (Not between)
"ISNOTBLANK" (Is not blank)
"ONORBEFORE" (On or before)
"AFTER" (After)
"BETWEEN" (Between)
"=" (Equal to)
Valid values for numbers:
"<>" (Not equal to)
"ISBLANK" (Is blank)
">" (Greater than)
"<=" (Less than or equal to)
">=" (Greater than or equal to)
"NOTBETWEEN" (Not between)
"ISNOTBLANK" (Is not blank)
"BETWEEN" (Between)
"<" (Less than)
"=" (Equal to)
The text within each set of parentheses shows what appears in the user interface.
Note:
When using operators in metadata elements, make sure that the "less than" operator is written as "<" and the "greater than" operator is written as ">".
For example:
<perspective name="Offer Contents Expiring within 7 Days "> <root choiceGroupId="OfferContent"> <simpleViewCriteria attribute="expiringDays" operator="<=" value="7" />
genSysNote: controls whether changing the value of such an attribute should trigger a "Set Attribute" audit trail entry, true or false, true by default
type (see later in this section)
restriction (see later in this section)
default-value: (see later in this section)
control (see later in this section)
Properties of type:
name: the type of the attribute, either "string", "date", "number", or "clob".
length: for string types, the maximum number of characters that can be entered into the text control. This includes the characters representing the new line. If set to 0 or less, the maximumLength is ignored. Note that in some browsers like Internet Explorer, new line is treated as two characters.
precision: for number types, the precision is the total number of digits. It must be between 1 to 15. The default value for precision is 5.
scale: for number types, the scale is the number of digits to the right of the decimal point. It can range from 0 to the value of precision. The default value for scale is 2.
displayWidth: the size of the text control specified by the number of characters shown. The number of columns is estimated based on the default font size of the browser.
required: whether a non-null, non-empty value must be entered.
Properties of restriction:
kind: the kind of type restriction, either "lov" (only for string attributes), "regexp" (only for string attributes), or "range" (only for number and date attributes).
minDefined: for range type restrictions, whether the range has a min bound ("true" or "false")
maxDefined: for range type restrictions, whether the range has a max bound ("true" or "false")
minInclusive: for range type restrictions, whether the range min bound is included ("true" or "false")
maxInclusive: for range type restrictions, whether the range max bound is included ("true" or "false")
(all other type restriction information is retrieved at runtime from the Inline Service)
Properties of default_value:
The default-value tag has one required attribute "value" and two optional attributes: "expression" and "masterValue".
value: a value of the following types: "string", "date", "number" or a Groovy expression.
For date attributes, the value must be in the format yyyy-mm-dd, for example, 2012-10-08.
If a string, date or number value is defined for the "value" attribute, then the optional "expression" attribute must be set to "false" or omitted.
expression: a Boolean value that indicates whether the "value" attribute specifies a Groovy expression (default is "false"). If the "value" attribute contains a Groovy expression, then expression must be set to "true".
For example: <default-value value="adf.currentDate" expression="true"...... />
masterValue: for a project attribute, this specifies the default value for the project attribute in the Main Repository. It may contain a value of the following supported types: string, date, number.
The following considerations apply for default values for project attributes:
If the "required" attribute (a property of type) is set to "true", then the default-value "value" attribute must be non-empty.
If "expression" is set to "true", then "masterValue" must be non-empty.
During application generation, Oracle RTD Decision Manager sets the required attributes of the Main Repository project based on the default values for these attributes in the project choice group. Expressions cannot be used at that time. So if you use an expression as a default value on a project attribute, you must also add a static value in “masterValue” that will be used for the Main Repository project.
In other words, for project attributes where the "value" attribute contains a Groovy expression and where "masterValue" is non-empty, then "masterValue" is used for the column value (for example: <default-value value="adf.currentDate" expression="true" masterValue="2012-08-29" />), otherwise the contents of the "value" attribute are used (for example: <default-value value="2012-08-30" expression="false"/>).
Properties of control:
name: the widget name, which must be one of the following:
Image (see details later in this section)
InputDate - this widget creates a text field for entering dates and a glyph which opens a popup for picking dates from a calendar.
InputText (see details later in this section)
InputTextRange - this widget is used for attributes with Range Type Restriction.
InputTextRegexp - this widget is used for attributes with Regexp Type Restriction
ManyToManyRelationship - this widget is used to show the shuttle for selecting a choice participating in a many-to-many relationship.
OneToManyRelationship - this widget is used to show a dropdown list for selecting a choice participating in a one-to-many relationship.
OutputRelationship - this widget displays a choice participating in many-to-many or one-to-many relationships.
OutputText - this widget displays text (read only).
RTDRuleEditor - (see details later in this section)
SelectOneChoiceLOV - this widget displays list of values derived from a Type Restriction.
An Image widget is used to display an image when a choice is opened in view mode. The URL location of the image is determined at run time, during choice creation or editing.
An Image widget can have two optional attributes:
urlPrefix
urlPostfix
The values of urlPrefix and urlPostfix can be used to form the complete URL where the image is to be found. During choice creation or editing, the location of the image is provided either as a complete URL, or as a value to which the urlPrefix and urlPostfix values, if specified in the metadata, can be attached.
Typically, urlPrefix specifies a general directory that contains multiple images (for example, http://www.oracleimg.com/us/assets/), and choice creators and editors provide the name of a particular image file in that directory (for example, oralogo-small.gif).
An InputText widget is used to enter values for attributes. An InputText widget can have one optional attribute:
rows: This determines if a text field will have one or more rows. If rows is not specified, the default value is 1
A RTDRuleEditor widget displays the ADF RTD Rule Editor for the creation of rules in Decision Manager.
A RTDRuleEditor widget has the following optional attributes:
title
Specifies the message which is shown in the Rule Editor as the top Rule Editor entry. By default, the message is "{0} is eligible". Use {0} to refer to the choice group name.
object
Specifies the id of the choice group to which the rule applies. Leave this empty to enable the rule to be for the choice group of the attribute that contains this control.
inlineService
Specifies the Inline Service which this rule uses. By default this is the Inline Service specified in config/config.xml.
Properties of relationship types:
id: the id of the relationship type. You use this id in your Inline Service for methods such as CLMChoiceBag.getRelatedChoiceIds().
fromChoiceGroupId: the choice group source.
toChoiceGroupId: the choice group destination.
fromName: the owner to destination relationship type name. You use this name in your Inline Service for methods such as CLMChoiceBag.getRelatedChoiceIds().
toName: the destination to owner relationship type name. You use this name in your Inline Service for methods such as CLMChoiceBag.getRelatedChoiceIds().
fromDescription: the owner to destination relationship type description.
toDescription: the destination to owner relationship description.
cardinality: From the owner to the destination, can be:
*:1
Each source has one destination
Each destination has 0 to n sources
*:0
Each source has 0 or 1 destination
Each destination has 0 to n sources
*:*
Each source has 0 to n destinations
Each destination has 0 to n sources
*:1..*
Each source has 1 to n destinations
Each destination has 0 to n sources
Note:
For cardinalities *:* and *:1..*, the only valid value for onDelete is "O".
onDelete: 'C' to cascade delete destination choices, 'O' to make destination choices orphans (that is, only delete the relationship). Explicitly:
onDelete="C": Deleting a choice on the "zero or one" side of the relationship will attempt to also delete the choices on the "many" side
onDelete="O": Deleting a choice on the "zero or one" side of the relationship will not delete the choices on the "many" side
For cardinalities *:0 and *:1, the default onDelete value is "C".
propagateRules: 'N' to not propagate rules (the default), 'D' to propagate rules from owner to destination, 'S' to propagate rules from destination to owner, 'B' to propagate rules in both directions. For more details, see the section "Propagation of Rules" in Oracle Real-Time Decisions Base Application Installation and Reference Guide.
propagateEvents: 'N' to not propagate events (the default), 'D' to propagate events from owner to destination, 'S' to propagate events from destination to owner, 'B' to propagate events in both directions. For more details, see the section "Propagation of Events" in Oracle Real-Time Decisions Base Application Installation and Reference Guide
Properties of criteria:
id: the id of the criteria
xml: the <ViewCriteria> xml of a view criteria defined on this choice group's VO (view object).
Projects are a special kind of choice group. You can specify additional attributes to projects by specifying a choice-group with id Project. Project attributes appear in the Decision Manager interface when creating projects, viewing projects and project audit trail entries, and in the model layer, where they can be accessed by the Oracle RTD public Java APIs.
The layout of the pages and tabs used when creating, editing, and viewing choices and projects is determined by XML metadata. These metadata tags may be in any .xml file in the top-level application implementation folder (for the reference implementation, this is clm\Build\metadata\ref), but is typically included in the individual choice group and project XML files.
The metadata tags that control the user interface pages for choices and projects are the following:
views: top-level tag that is the container for the Decision Management user interface layout.
choice-view (within views): the Decision Management user interface view for choice data of a particular choice group.
Uniquely identified by choiceGroupId and view type. Supported types for choices and projects are "create", "edit", and "view". In addition, the view type "list" is supported for projects.
Note:
When type="list", the choice-view attribute can contain several <table> attributes, each of which can have multiple <column> attributes.
Each table must have a unique id (in the context of the choice-view) and the attribute viewObjectName (which defines the VO used for the table). ActiveProjectsVO and DeployedProjectsVO are the supported VOs.
Each column must have the attribute attribute-id. Attributes with type number, date, and string are supported, but not attributes with type clob.
Columns can have filterable and sortable boolean attributes, for example, <column attribute-id ="Name" filterable ="false" sortable ="false" />. By default, both filterable and sortable are "true" - however, filterable=true is not supported for date attributes.
For an example, see project.xml for the reference implementation.
page (within choice-view): the page or tab that contains the elements required for an operation to be performed on a choice or project. The actual contents of the page are specified in the page-attributes-group tag (see later in this section).
A page corresponds to either a tab (displayed when choices and projects are edited or viewed) or a train stop (displayed during choice creation).
Each page must have an id and a Name, and may have a description. As well as for identification, the page id is used to assign permissions to a page.
A page can have the viewType attribute, whose value designates which type of view it belongs to and for which operation it is displayed (one or more of the options "create", "edit", and "view"). If viewType is not specified, the page belongs to all the view types and is displayed for create, edit, and view operations.
For example, with <page id="Review" viewType="create edit"/>, the page is displayed on create and edit views only.
page-attributes-group (within page): the attributes, relationships, audit trail notes, and text to be displayed on the page that are required for an operation to be performed on a choice or project. On the page, page attribute groups are separated from each other by a dotted line.
Every page must have one and only one top level <page-attributes-group/>. Nested occurrences of <page-attributes-group/> are used to group attributes. In the Decision Manager user interface, dotted lines appear where nested page attribute groups are defined in the metadata.
attribute (within page-attributes-group): corresponds to the choice group or project attribute.
May contain the readonly and viewType attributes. As with the page tag, viewType controls whether the attribute appears on some or all types of view.
All attributes for viewType = "view" are readonly.
Note:
The following five built-in attributes are also supported: Name, Description, ChoiceId, EligibilityRule and LockOwner (this last one only when ownership-mode is on in the config XML file.
relationship (within page-attributes-group): corresponds to the relationship between choice groups.
May contain the readonly and viewType sub-tags.
All relationships for viewType = "view" are readonly.
As with the attribute tag, viewType controls whether the relationship appears on some or all types of view.
note (within page-attributes-group): renders an Audit Trail Note field.
Can be required, and, as with the attribute tag, it can have viewType.
Does not have the readonly option, and is not displayed for viewType = "view".
text (within page-attributes-group): appears as text message on the page.
<choice-view choiceGroupId="Placement" type="create edit view">
<page id="Overview">
<name>Overview</name>
<description>Overview</description>
<page-attributes-group>
<page-attributes-group>
<attribute id="Name"/>
<attribute id="Description"/>
<attribute id="ChoiceId" readonly="true" viewType="edit view"/>
</page-attributes-group>
<page-attributes-group>
<attribute id="type"/>
<attribute id="url"/>
</page-attributes-group>
<page-attributes-group>
<relationship id="Placement to Channel"/>
</page-attributes-group>
<note viewType="edit"/>
</page-attributes-group>
</page>
<page id="Rules">
<name>Rules</name>
<description>Rules</description>
<page-attributes-group>
<attribute id="EligibilityRule"/>
<note viewType="edit"/>
</page-attributes-group>
</page>
<page id="Confirm" viewType="create">
<name>Confirm</name>
<description>Confirm</description>
<page-attributes-group>
<text value="An Id was automatically generated based on the name you entered. You can change it now. It cannot be changed later."/>
<text value="Only letters, digits, underscores, hyphens, dots and spaces are allowed."/>
<attribute id="ChoiceId" readonly="false"/>
<note/>
<page-attributes-group>
<text value="Review the information you entered below. Press Back if you need to make changes, or OK to finish."/>
<attribute id="Name" readonly="true"/>
<attribute id="Description" readonly="true"/>
<attribute id="type" readonly="true"/>
<attribute id="url" readonly="true"/>
</page-attributes-group>
<page-attributes-group>
<relationship id="Placement to Channel" readonly="true"/>
</page-attributes-group>
</page-attributes-group>
</page>
</choice-view>
By default, all security metadata is in a file called security.xml but you may create as many files containing security information as you want.
There are different root nodes that apply to security:
<application-roles> contains the definition of application roles.
<enterprise-roles> contains the definition of enterprise roles, which are uploaded as WebLogic groups in a development environment, and can be used in production environment to map application roles to groups you define in the WebLogic or WebSphere console (see Section 1.6.4, "Mapping Users and Groups to Intermediary Roles in Production.")
<users> contains the definition of users, which are uploaded as WebLogic users in a development environment, but are not meant to be used in a production environment
<application-roles> contains multiple <application-role>.
Each application role has a <name> and <permissions>.
<permissions> has multiple <permission>, each having a <resource-name>, a <resource-type>, and <actions>.
The resource type can be perspective, choice group, project, choice view page, and cache. Cache is specifically for admin users.
For the perspective resource type:
The resource name is the name of the perspective as defined in perspectives.xml, or _all_ to mean all perspectives.
The only action is view, which means that the user having this application role will be able to see and select this perspective in the Decision Manager user interface.
For the choice group resource type:
The resource name is the id of the choice group as defined in one of the other configuration files, or _all_ to apply to all choice groups.
The actions are a comma separated list of one or multiples of:
create: to be able to create a choice of that choice group in a project
read: to be able to view choices of that choice group
update: to be able to edit a choice of that choice group in a project, and to be able to discard any changes (including addition and deletion) on a choice of that choice group
delete: to be able to delete a choice of that choice group in a project
own: to be able to edit (in the same project) and become owner of a choice that is owned by someone else
For the project resource type:
The resource name must be _all_.
The actions are a comma separated list of one or multiples of:
create: to be able to create a project
commit: to be able to commit a project
discard: to be able to discard a project and all changes within it
update: to be able to update a project
read: to be able to log in to the application and to use the Decision Manager user interface
For the choice view page resource type:
The resource name has the following format {choiceGroupId} / {pageId}.
Both {choiceGroupId} and {pageId} can be specific Ids or _all_:
_all_/_all_ means the permission is granted for all pages in all choice groups
_all_/Confirm means the permission is granted for all pages with pageId=Confirm in all choice groups
Offer/_all_ means the permission is granted for all pages in the Offer choice group.
The actions are a comma separated list of one or multiples of:
create: to be able to create objects in the pages specified by <resource name>
view: to be able to view objects in the pages specified by <resource name>
update: to be able to objects in the pages specified by <resource name>
list: to be able to view lists of projects in the pages specified by <resource name>
For "list" the choice group must be Project and the resource name must be a page representing a list of projects to be shown in the View Projects tab.
Example
The following <permission> metadata enables all pages of all choice groups to be viewed, and all Overview pages (technically, pages with pageId=Overview) in all choice groups to be edited:
<permission> <resource-type>choice view page</resource-type> <resource-name>_all_/_all_</resource-name> <actions>view</actions> </permission> <permission> <resource-type>choice view page</resource-type> <resource-name>_all_/Overview</resource-name> <actions>update</actions> </permission>
For the cache resource type:
This permission, to be used only by admin users, is for cleaning the RTD cache. This cache contains the type restrictions information retrieved from the Inline Service.
Example:
<permission> <resource-type>cache</resource-type> <resource-name>rtd-metadata</resource-name> <actions>reset</actions> </permission>
<enterprise-roles> has multiple <enterprise-role>.
Each <enterprise-role> has a name and <application-roles>, which is a comma separated list of application roles that are granted to members of that enterprise role.
<users> has multiple <user>.
Each <user> has a name, a display name, a description and credentials which is the password in an encrypted form. See previous sections for how to get the correct credential string.
Each <user> has <application-roles>, which is a comma separated list of application roles that are granted to members of that enterprise role.
For each choice group you have defined, add a 16x16 png image in the images\group folder (under <metadata_modules_home>\<your_application>) named after the choice group id.
The file must be called <choiceGroupId>.png.
Both parts of the file name are case-sensitive:
<choiceGroupId> must exactly match the name of the choice group id, as set up in the choice group configuration xml file (see Section 2.2.2.3, "Choice Group, Project, and Relationship-Types XML Files")
png must be all lower-case
The RTD_Base_Marketing Inline Service released with the RTD for Marketing Optimization application is in the service folder under <metadata_modules_home>\ref, that is, in clm\Build\metadata\ref\service. This Inline Service is described in more detail in Oracle Real-Time Decisions Base Application Installation and Reference Guide.
After you have modified the metadata, you need to run the application generation tool ant to generate the application.
The clm\Build directory contains the ant tasks to perform the generation.
The ant targets are as follows:
ear - creates EAR file for deployment in production mode
clean - cleans projects
generate - generates the application.
clean-generated - removes generated code
The ant option "generate" takes two optional parameters:
metadata.module: this specifies which subfolder of clm\Build\metadata must be used to generate the application. The default value is ref.
changes: this specifies whether to warn you and abort the generation if it is about to overwrite files that have been modified. Use value overwrite to overwrite files. The default value is to omit this parameter, in which case ant will warn and fail.
Example:
To generate an application in clm\Build\metadata\myapp, call:
ant -Dmetadata.module=myapp generate
Then
ant ear (for deploying to production, otherwise deploy from JDeveloper)
Notes:
After generation, the database schema may have changed. You should then run "drop ils.sql" then "drop core.sql" (or drop and recreate the database user), then "load core.sql" then "load ils.sql". This will delete any choice you have in the database. To preserve choices, you can compare the previous and new sql and just make these changes. For instance, if you added a choice attribute, you can alter the table to add a column, and recreate the view associated with it.
In most cases, you should not modify any of the files that are generated by ant generate, so you should not use –Dchanges=overwrite. There are a few exceptions, such as the steps described in Section 1.6.1.3, "Running Application Generation."
Customization can be achieved without modifying any of the files created by ant generate. Use the extensibility of the ADF Framework or the Oracle RTD Decision Management templates to extend the behavior of the application without modifying any of the core and generated files.
The behavior of the Oracle RTD Decision Management business layer and view controller layer can be further extended by the use of the Java API that comes with it. The javadoc for this Java API can be found in clm\lib\clm-model-api-javadoc.jar and also clm\lib\clm-ui-core-api-javadoc.jar.
This section contains the following topics:
Section 2.2.5.1, "Adding an Attribute to a Choice Group or Project"
Section 2.2.5.3, "Creating a Relationship Type Between Two Choice Groups"
In order to add an attribute to a choice group or project, follow these steps:
Modify the xml where the choice group or project is defined in folder clm\Build\metadata\ref.
Run application generation again: in folder clm\Build, run "ant generate".
Since adding an attribute to a project or choice group modifies the database, you have to recreate the database. In order to do this, call "drop ils.sql" then "drop core.sql" then "load core.sql" then "load ils.sql" (these files are in clm\Database\sql and clm\Database\sql\ils). If you do not want to lose your database data, you can compare the sql to the previous one and alter the table to add the column and recreate the associated view.
You can now deploy the new version of the Decision Management application using JDeveloper.
For new choice group attributes, you have to add the choice attribute to the choice group in your Inline Service as well. Make sure the id is the same as the one you entered in the xml metadata in the first step. Redeploy the Inline Service.
In order to add a choice group, follow these steps:
Add an xml file for this new choice group in folder clm\Build\metadata\ref.
Add an image for this choice group in folder clm\Build\metadata\ref\images\group.
Run application generation again: in folder clm\Build, run "ant generate".
Since adding a choice group modifies the database, you have to recreate the database. In order to do this, call "drop ils.sql" then "drop core.sql" then "load core.sql" then "load ils.sql" (these files are in clm\Database\sql and clm\Database\sql\ils). If you do not want to lose your database data, you can compare the sql to the previous one and add the new table, the new view and one row in the CHOICE_GROUP table.
You can now deploy the new version of the Decision Management application using JDeveloper.
You have to add the choice group in your Inline Service as well. Make sure the ids are the same as the ones you entered in the xml metadata in the first step. Make sure the choice group you add is under CLM Base choice group. Add the choice group in the CLM ILS Choice Groups application parameter. Redeploy the Inline Service.
In order to create a relationship type between two choice groups, follow these steps:
Edit relationship-types.xml in folder clm\Build\metadata\ref and add the new relationship type.
Run application generation again: in folder clm\Build, run "ant generate".
Since adding a choice group modifies the database, you have to recreate the database. In order to do this, call "drop ils.sql" then "drop core.sql" then "load core.sql" then "load ils.sql" (these files are in clm\Database\sql and clm\Database\sql\ils). If you do not want to lose your database data, you can compare the sql to the previous one and add one row in the RELATIONSHIP_TYPE table.
You can now deploy the new version of the Decision Management application using JDeveloper.
You can (but do not have to) add choice attributes in both choice groups in the Inline Service to follow the relationship. For an example, see how Offer has a "campaign" choice attribute and a "creatives" choice attribute. Redeploy the Inline Service.
In order to modify perspectives, follow these steps:
Edit perspectives.xml in folder clm\Build\metadata\ref\config.
Run application generation again: in folder clm\Build, run "ant generate".
You can now deploy the new version of the Oracle RTD Decision Management application using JDeveloper.
This section contains the following topics:
Oracle RTD Decision Management uses Java Logging API. There are two ways to configure Java Logging API (http://java.sun.com/j2se/1.5.0/docs/guide/logging/overview.html):
Update global logging configuration of the JRE which is used to start WebLogic: JAVA_HOME/jre/lib/logging.properties
Create separate logging properties file (for example c:\src\clm\logging.properties) and pass it in the -Djava.util.logging.config.file argument to the Weblogic.Server startup command.
To pass this argument append the line:
set JAVA_OPTIONS=%JAVA_OPTIONS% -Djava.util.logging.config.file= c:\src\clm\logging.properties
to
C:\Oracle\Middleware\user_projects\domains\<RTDCLM_domain>\bin\setDomainEnv.cmd
Sample logging.properties file:
# Specify the handlers to create in the root logger .level= INFO handlers = weblogic.logging.ServerLoggingHandler # Register handlers for the oracle.rtd.clm. and its child loggers oracle.rtd.clm.handlers = java.util.logging.FileHandler, java.util.logging.ConsoleHandler, weblogic.logging.ServerLoggingHandler oracle.rtd.clm..useParentHandlers = false oracle.rtd.clm.level = ALL #Console handler java.util.logging.ConsoleHandler.level = INFO java.util.logging.ConsoleHandler.formatter = java.util.logging.SimpleFormatter # Set the default logging level for new FileHandler instances weblogic.logging.ServerLoggingHandler.level = ALL #File handler java.util.logging.FileHandler.pattern = %h/java%u.log java.util.logging.FileHandler.limit = 50000 java.util.logging.FileHandler.count = 1 java.util.logging.FileHandler.formatter = java.util.logging.SimpleFormatter java.util.logging.FileHandler.level=ALL
This configuration logs message with level INFO to the WebLogic Server Startup Console and all messages to the java*.log file in the user home directory. To change log level for Oracle RTD Decision Management applications replace oracle.rtd.clm.level = ALL
with oracle.rtd.clm.level = SEVERE|WARNING|INFO|CONFIG|FINE|FINER|FINEST.
Additional info can be found at the following site:
http://download.oracle.com/docs/cd/E14571_01/web.1111/e13739/logging_services.htm
For WebSphere, logging can be configured as follows:
Login to the WebSphere console.
Navigate Troubleshooting > Logs and trace.
Open the server where Decision Manager is deployed.
Open Change Log Detail Levels.
To make a static change to the configuration, click the Configuration tab.
To change the configuration dynamically, click the Runtime tab.
In the All Components tree, right-click oracle.rtd.clm.* (or one of its sub packages), and set the logging level.
Click Apply.
If you changed the logging level on the Configuration tab then save changes to the configuration and restart the server.
Logs can be found in <server_log_root>/<server_name>-diagnostic.log (for example /AppServer/profiles/AppSrv01/logs/server1-diagnostic.log).
|
 Copyright © 2010, 2012, Oracle and/or its affiliates. All rights reserved. Legal Notices |
|