| Oracle® Retail Predictive Application Server Cloud Edition Configuration Tools User Guide Release 19.0 F25318-14 |
|
 Previous |
 Next |
| Oracle® Retail Predictive Application Server Cloud Edition Configuration Tools User Guide Release 19.0 F25318-14 |
|
Previous |
Next |
The RPASCE platform supports the integration of domains with a data store maintained within an Oracle Database instance. Once integrated, a domain can automatically push data into and pull data out of the database in order to perform operations such as workbook building and committing. By integrating multiple RPASCE domains with a single data store, it is possible for domains to share data automatically through transparent platform processes without the need for batch processes to synchronize information.
In order to support these behaviors, a Planning Data Store must be created within an Oracle Database instance. Because of the highly configurable nature of RPASCE domains, an equally flexible configuration of the objects and information must be present within the data store. The Integration configuration process consists of determining the objects required for a Planning Data Store and the specification of their relevant properties.
The Planning Data Store, or PDS, is a persistent data store maintained within an Oracle Database. The PDS is used as a central repository and storage of record for customer data that can be produced and/or consumed by the processes performed in one or more RPASCE domains that are integrated with that PDS.
The primary purpose of the PDS is to maintain a set of facts. These facts, which are stored within in tables of the Oracle Database, are conceptually equivalent to the measures of a RPASCE domain. In addition, the information within a fact is structured in a manner that is functionally equivalent to the multi-dimensional system present in a RPASCE domain.
It is therefore possible to access fact information through an address composed of a set of positions along discrete dimensions. Each row of a fact table, like a cell within an RPASCE array, corresponds to a unique combination of positions along one or more dimensions (for example, a single sku, store, and week). However, unlike a RPASCE array, a fact table may contain values for multiple facts within a single table. Each fact is represented by a distinct column within the fact table.
For any given column (fact) and row (position address), a table contains a value if the fact has a populated value for that address but contains an empty cell for that column if the fact has no value for that address.
The Planning Data Store also maintains tables to describe the hierarchies and dimensions used to structure the facts contained within the data store. This information is stored within a separate set of tables, known as dimension tables, in a manner analogous to the dimension arrays of an RPASCE domain. As with the hierarchies and dimensions of an RPASCE domain, the dimension tables of a PDS can be administered in order to add, remove, and modify individual positions and can represent the child/parent relationships that describe the multiple levels represented by the dimensions of a hierarchy.
In RPASCE, the PDS configuration, that is, the Integration Configuration, can be extended by EE-customers. EE-customers can add new shared hierarchies, shared facts, domain information, or integration mappings to a GA configuration. Certain rules should be applied to the extensibility. These rules should be applied to both the GA template application as well as the EE application.
GA fact or GA fact group can neither be removed nor modified.
GA Hierarchy can neither be removed nor modified.
GA Domain name can neither be removed nor modified.
GA Integration configuration allows:
New Domain name to be added
New custom facts group and facts to be added
New custom hierarchies to be added
No GA fact should be added to custom facts group.
No custom fact should be added to GA fact group.
In order to support this, the Integration Tools has a Custom component to identify the customer components for below tabs:
Domain Informations
Shared Hierarchies
Fact Groups
Integration Map
The objects used in Integration Configuration are exposed to a separate validation utility that ensures that the GA Integration configuration will be not be edited beyond the allowed PDS extensibility guidelines. For details, refer to Integration Guide for the Installation, Deployment, and Administration of the Planning Data Store and Oracle Retail Predictive Application Server Cloud Service Implementation Guide.
In order to properly configure the PDS, it is necessary to supply information about three components: the Shared Hierarchies and Dimensions, the Shared Facts, and the Integration Map. The information about these components is stored in an XML document referred to as the integration configuration, which is created and maintained by the RPASCE Configuration Tools. In addition, the integration configuration contains a fourth component used internally by the Configuration Tools to manage the configuration process.
The information contained within the fact tables of a PDS, like the information contained within the measures of a RPASCE domain, is structured to represent a set of multidimensional relationships. This structure is represented by a set of dimensions that are defined along hierarchies that describe the space in which the information is relevant. These hierarchies can represent common familiar constructs such as the Calendar, Location, or Product hierarchies. They can also represent concepts that are application specific.
The Integration Configuration contains information about the hierarchies represented within the PDS. It also contains information about the structure of the dimensions that are defined within a hierarchy. As with a domain configuration, dimensions are defined in a tree structure to allow the representation of roll-up information.
When configuring the hierarchies and dimensions of the PDS, it is not necessary to include every hierarchy and dimension within the domain configuration of a domain integrated with that PDS. It is only necessary to define the set of dimensions that form the intersections of the facts used to share measure data.
In cases where the domains integrated with a PDS have non-identical hierarchical representations, it may also be necessary to include one or more dimensions so that every hierarchy has a single root dimension and all dimensions within the hierarchy can be fully expressed by one-to-one or one-to-many parent-child relationships.
Furthermore, it may be desirable to include additional dimensions within a PDS even if their inclusion is not motivated by requirements of integration. For example, additional dimensions that are not used in fact intersections may be included in order to support reporting against the Oracle Database.
|
Note: RPASCE does not require every hierarchy or dimension defined as shared to exist in every domain integrated with PDS. These shared hierarchies or dimensions may exist in one domain but not in other domains and are still acceptable in the Integration Configuration. |
When defining a shared hierarchy, it is necessary to specify the following properties:
Hierarchy Name – This is the name of the hierarchy. The name of a hierarchy within the PDS must correspond to the RPASCE name of a domain hierarchy in order for that domain hierarchy to participate in sharing data with the PDS.
Hierarchy Label – The label is a user label used to identify the hierarchy in reporting and user notification.
Hierarchy Purge Age – The purge age is the amount of time RPASCE continues to store a hierarchy position after the position is no longer included in hierarchy load files. If the amount of time in days that has passed since the last hierarchy load contained an entry for a given position, that position will be marked for purging from the system.
Hierarchy Order – As with hierarchies in a RPASCE domain, the hierarchies of a PDS must be ordered. This ordering is used in the construction of the tables holding fact information within the PDS. For a RPASCE domain to participate in sharing data with a PDS, it is necessary for the relative order of the hierarchies within that domain to be the same as the relative ordering of the hierarchies within the PDS. It is not necessary for the hierarchies within a domain to have identical values for the order attribute as the PDS hierarchies, but the order of hierarchies relative to each other must be the same.
Virtual Hierarchy – As with virtual hierarchies in a RPASCE domain, this property specifies the virtual hierarchy for this shared hierarchy. The name of the virtual hierarchy must be the same as its virtual hierarchy in the domain. If this shared hierarchy has no virtual hierarchy in the domain, this property must be left blank.
Custom – This property is an optional, Boolean flag with a value of true, indicating this shared hierarchy is added by EE customers, instead of from the GA configuration. This property is used for PDS extensibility. EE customers can only add new shared hierarchies instead of removing/modifying existing ones. A newly added Shared Hierarchy will have the Custom column selected to a value of true by default.
EE customers cannot add new dimensions to existing shared hierarchies, and thus the Shared Dimension does not have the Custom property.
Shared facts are entities within the PDS that correspond to measures within a RPASCE domain. Like domain measures, facts are defined as either scalar or multi-dimensional. Once a RPASCE domain has been integrated with a PDS, it is possible to specify mappings of domain measures to PDS facts. These mappings allow a RPASCE domain to use the fact as it resides within the Oracle Database to store the information previously associated with the domain measure.
Information can be pulled from and pushed to the Oracle Database automatically as a part of domain operations, making the fact within the Oracle Database the store-of-record for the information. When multiple domains are integrated into a single PDS, there can be several mappings for a single fact, one in each domain. When this occurs, the domains can seamlessly share a single version of the fact information without requiring overt integration operations of data duplication and synchronization.
Within the PDS, facts are stored within fact tables. The PDS can store multiple facts within a single table. When this occurs, each fact is represented by a separate column within the table, while the rows of the table represent the positional addresses for the dimensional space of the fact.
By grouping multiple facts within a single table, the PDS can reduce the amount of time required to retrieve information from the Oracle Database. Measures that are often read and/or written together and that contain the same fill pattern (or sets of addresses that have data as opposed to addresses for which no data is present) can be quickly accessed together when grouped in a single table.
Conversely, grouping facts together in a single table can have an adverse impact on data access if those facts are not accessed together and if those facts do not tend to have similar fill patterns. For this reason, the assignment of facts to fact tables and the grouping of facts within a table can have a large impact on system performance.
Shared facts are defined by some properties. Many of the properties involve the definition of the type of data represented by the fact, while others describe where and how the fact is stored within the fact tables of the PDS. The properties of a shared fact are:
Fact Name – This is the identifier of the fact. It is used by RPASCE to determine which fact is required for any given operation.
Fact Label – This is a user label that represents the fact in reporting and user notification.
Fact Intersection – The intersection of a fact, like the intersection of a measure, describes which dimensions are used to define the address space of the fact. For a domain to share a measure's data with a PDS fact, the domain measure must have the same intersection as the PDS fact or a higher intersection than the PDS fact. If the domain measure's intersection is higher than the PDS fact, that domain measure will be read-only, meaning it cannot be calculated or committed from workbooks.
Fact Type – The fact type describes the type of data stored within the fact. These types are drawn from the set of defined RPAS CE measure types (real, integer, Boolean, Date, and string). For a domain to share a measure's data with a PDS fact, the domain measure must have the same type as the PDS fact.
Fact Group – The fact group is an organizational attribute that is used to distribute facts across fact tables within the PDS. A single fact table contains the information for all facts belonging to a single fact group. The efficient grouping of facts can have a large impact on system performance. A discussion of best practices regarding the assignment of facts to fact groups can be found in section 3.3.
Fact Table – The fact table is the physical name of the fact table within the Oracle Database that contains the data associated with the fact. This attribute is derived from the fact group and need not be configured separately.
Fact Description – The fact description is a property that describes the context of the data contained within a fact. It can be used for reporting or user notification.
Fact Na Value – The Na value of a fact is the implied value of that fact for any positional address for which the fact's fact table does not contain a value. It is analogous to the Na value of a measure within a RPASCE domain. In order for a domain to share a measure's data with a PDS fact, the domain measure must have the same Na value as the PDS fact.
Fact Purge Age – The fact purge age is an attribute used by RPASCE to determine how long information loaded into a fact must be maintained by the system before it is purged as obsolete.
Source Fact - The source fact is an attribute used by ORDS to update facts in RPASCE PDS. The Boolean value it contains indicates if the fact is a source fact that is used on the right side of the calculation expression. By default, this attribute is False. Users must set it to True to indicate it is a source fact so that ORDS can update this source fact in PDS through a web service call.
Fact Auditing – This provides the option of having an auditing column for each fact table. This option can be configured at the fact group level. Fact group auditing can be set to true or false per Fact Group Name. For the fact groups that have auditing on, an extra column, LAST_UPDATED, is added to the corresponding fact table. This auditing column captures the timestamp indicating when each row is updated.
The integration map is the structure that describes which domain measures share data with the facts contained within the PDS. The map is made up of a set of entries; each entry describes the fact within the PDS and the domain and measure that participate in the sharing.
Integration map properties include:
Shared Fact – The fact within the PDS that stores the data to be used by the domain measure participating in the sharing.
Domain ID – An identifier that describes domain for which the measure participating in the sharing is defined.
Domain Measure – The measure within the domain that participates in the data sharing.
Outbound Integration – Retail bulk data integration is used to transfer bulk data between other retail products and RPASCE PDS. The integration can be two-way, with the transfer from RPASCE PDS to other retail products called outbound and the reverse direction called inbound. The outbound integration property is a Boolean flag that indicates whether or not the shared fact is included in the outbound bulk data integration. By default, this property is false. To include the shared fact in outbound integration, this property must be explicitly set to true.
Custom – The Custom property is an optional, Boolean flag with the value of True, indicating that this integration mapping is configured by EE customers, instead of from the GA configuration. A newly added Integration Map entry will have the Custom field selected to True by default.
For a measure to be eligible to share data with a PDS fact, the measure must have compatible values for several of the properties of the fact.
Measure Type – The data type of the measure must be the same as the data type of the fact.
Measure Na Value – The Na value of the measure must be the same as the Na value of the fact.
Measure Base Intersection – The base intersection of the measure must be the same as the fact intersection. Note that, in configurations that make use of the hierarchy indirection feature of the Configuration Tools, the literal value of the intersection property of a measure may differ from the fact intersection due to use of the RPASCE Name dimension attribute or labeled intersections; in such cases, the RPASCE internal intersection is used in place of the literal value of the measure intersection property for this check.
The Integration Tool uses the domain information to identify the domain configurations of the domains that are being integrated into the PDS. This information is used internally by the Integration Tool for many of its processes.
Domain information properties include:
Domain Identifier – This is an identifier that describes the domain within the integration map.
Configuration Location – This is the location of the configuration that represents the domain. It is used by the Integration Tool to determine which version of a configuration should be used by the Integration Tool.
Custom – The Custom property is an optional property. If selected, it indicates that this domain information is added by EE customers, instead of from the GA configuration. Newly added domain information will have the Custom check box selected by default.
A new tool in Configuration Tools can be used to create and maintain the integration configuration. This tool, called the Integration Tool, specifies the metadata of the PDS by creating shared hierarchies, dimensions, and facts. You can maintain the integration map that describes which domain measures participate in data sharing with the PDS shared facts.
Unlike the other tools used within the RPASCE Configuration Tools, an instance of the Integration Tool is not tied to a domain configuration. Instead, an XML document, called the integration configuration, is used to store all integration-related information. As a result, there is no integration-related information in a domain configuration, and, therefore, it is not necessary to modify a domain configuration when specifying integration information. Multiple copies of domain configurations are not required to support different integration scenarios or to support integrated versus non-integrated domains.
Like domain configurations, access integration configurations within the Configuration Tools through the File menu. Use the Open Integration Configuration option to open an existing configuration or the New Integration Configuration option to create a new configuration.
Figure 10-1 New Integration Configuration Menu Item
Once an integration configuration has been created or loaded, the Integration Tool loads it into the Configuration Tools Workbench.
To create an integration configuration, you are prompted to give the new configuration a name and select a location in which to save the configuration. You can also specify the language of the labels entered within the Integration Tool. When the labels contained within the Integration Configuration are loaded, RPASCE associates the contained labels with the language of the configuration.
Figure 10-2 Integration Configuration Window
Once an integration configuration has been created, use the Configuration Properties Window to inspect and modify the language setting for the configuration.
Figure 10-3 Configuration Properties Window
The Integration Tool contains five tabs: Configurations, Shared Hierarchies, Fact Groups, Shared Facts, and Integration Map. Each tab is used to configure one of the five components described later.
Figure 10-4 Integration Tool Within the RPASCE Configuration Tools
Select either Save or Save As in the File menu to save changes to an integration configuration. Select either Close or Close All to close an open integration configuration.
When working with multiple integration configurations or with a mixture of integration configurations and domain configurations, use the Configuration Components pane to navigate to integration configurations, which are represented within the pane by the product database icon.
Figure 10-5 Configuration Components Pane
Use the Configurations tab to register domain configurations with an integration configuration. When working with the Integration Tool, create integration configuration content by referencing domain configuration content in registered domain configurations. You must add an entry to the Configurations tab for each domain configuration that will be used in conjunction with the configured PDS.
Figure 10-6 Configuration Tab of the Integration Tool
Click Add to register a domain configuration with the integration configuration. A Window is displayed that you use to select either a domain configuration currently open in the Configuration Tools or a domain configuration saved on disk to be registered by entering the location of the configuration.
Figure 10-7 Add Domain Configuration Window
Edit the Domain Identifier and Configuration Location properties within the Configuration tab. Click Remove to remove a currently registered domain configuration.
Use the Shared Hierarchies tab to configure the shared hierarchies and dimensions that exist within the Planning Data Store.
Figure 10-8 Shared Hierarchies Tab of the Integration Tool
The Shared Hierarchies tab is similar in appearance and functionality to the Hierarchy Tool of the Configuration Tools.
Hierarchies and dimension can be added and removed using the appropriate menu bar buttons. In addition, the structure of dimensions can be modified through drag-and-drop, just as in the Hierarchy Tool.
You can also modify the properties of a shared hierarchy or shared dimension by editing the table present in the Shared Hierarchy tab.
Click Import Hierarchy to launch a window to select multiple domain hierarchies and dimensions at one time from an open domain configuration. When you click OK, the shared hierarchies and dimensions are created based upon the properties of the imported domain hierarchies and dimensions.
In the Import Dimensions Window, hierarchies and dimensions that already exist inside the integration configuration displays as a dimmed and unavailable check box. Dimensions present in the selected domain configuration (should more than one be open) display as clear. You can check these hierarchies and dimensions to specify what content must be created in the Integration Configuration. When you click OK within the Import Dimensions Window, the Integration Tool creates the shared hierarchies and dimensions corresponding to the selected components.
Figure 10-10 Shared Hierarchies Tab with the Selected Content Imported
The Shared Hierarchies table has a Custom column from which customers can select either true or false from the drop-down list. The value of true indicates that the shared hierarchy is EE-customized instead of from the GA configuration. By default, a newly added shared hierarchy will have the Custom field set to true.
The Integration Tool supports several validations on hierarchy and dimension content. As with the traditional Configuration Tools, these validations are evaluated in real-time as content is rendered by the UI. When a property of a hierarchy or dimension violates a validity constraint, the field displaying that property will display with the Configuration Tools-standard red text color. In addition, the tool tip for the invalid cell will contain a message describing the validity constraint that has been violated.
The following validity constraints apply to shared hierarchies and dimensions:
Hierarchy name is a required property. It cannot be empty.
Hierarchy names must be valid names for RPASCE hierarchies. They cannot exceed four characters in length, must begin with a letter, and can contain only letters and numerals.
All hierarchy names must be unique. No other element in the Integration Configuration may share the name of a shared hierarchy.
Hierarchy order values must be positive integer values between 999 and 9999.
The Calendar hierarchy must be registered at order 999.
No hierarchy can have a lower order value than the hierarchy that precedes it.
If any registered domain configuration is currently loaded in the Configuration Tools, the order of the shared hierarchies will be compared to the domain hierarchies to validate that the relative ordering of hierarchies is identical.
Purge Age is a required property. It cannot be empty.
Purge Age must be a positive integer value.
If the Virtual Hierarchy column is left blank, it indicates that this shared hierarchy has no virtual hierarchy.
The Integration Tool can support multiple domains and the Shared Hierarchies table can only specify the common settings among all domains. If domain configurations have different Virtual Hierarchy settings, users cannot use shared hierarchies to specify which domain has which specific Virtual Hierarchy setting.
If Virtual Hierarchy is set, it will be validated against all domain configurations open in the Integration Tool. If the domain configuration contains its original hierarchy, then the hierarchy must have the same virtual hierarchy setting as in the shared hierarchy.
Dimension name is a required property. It cannot be empty.
Dimension names must be valid names for RPASCE dimensions. They cannot exceed four characters in length, must begin with a letter, and can contain only letters and numerals.
All dimension names must be unique. No other element in the Integration Configuration may share the name of a shared dimension.
The root dimension of the Calendar hierarchy must have a defined position format.
No dimension that is not the root dimension of the Calendar hierarchy may have a defined position format.
The supplied position format must be a valid RPASCE format.
The supplied position format must be a valid Oracle date format.
If an integration configuration includes the Calendar hierarchy, that hierarchy must include the day dimension.
If the Virtual Dimension is left blank, this shared dimension has no virtual dimension.
The Integration Tool can support multiple domains, and the Shared Dimensions table can only specify the common settings among all domains. If domain configurations have different Virtual Dimension settings, users cannot use Shared Dimensions to specify which domain has which specific Virtual Dimension setting.
If Virtual Dimension is set, it will be validated against all domain configurations open in the Integration Tool. If the domain configuration contains its original dimension, then the original dimension must have the same virtual dimension setting as in the shared dimension.
The Shared Facts tab is used to configure the shared facts that exist within the Planning Data Store.
This tab is used to configure the Auditing and Custom features. Each fact group can be set to true or false. Each fact group must exist in the next tab of Shared Facts tab. If not, an error occurs, and if it is not resolved, the RPASCE server will ignore the fact group.
For the Custom column, click the field to enable the drop-down list where customers can then select either the true or false value. A value of true indicates that the fact group is EE-customized. Since a GA-configured shared fact should not be added to an EE-customized fact group, customer can only set the Custom property in the Fact Groups table instead of the Facts table. All facts that belong to one custom fact group are custom facts. The granularity of setting the Custom flag for shared facts is therefore at the level of the fact group.
The main feature of the Shared Facts tab is the fact table. This table lists the shared facts that have been defined within the integration configuration. You can manage the properties of configured facts by editing the appropriate cell within the fact table. As is the case within the Measure Tool, many attributes support the use of smart editors. You can select from a drop-down list of options or launch a window to specify values. In addition, you are notified when the specified value is not permitted.
Click Add Fact to add new facts to the integration configuration. To remove a fact, select it and click Remove Fact. In addition, you can create a fact based upon a configured domain measure when you click Import Fact.
When the Import Fact window is launched, you are prompted to select the domain configuration (if more than one is open in the Configuration Tools) and solution you want to import information from. Once the domain and application are selected, the right-hand list is populatde with all measures contained within the application that have configured database values. You can filter the list to exclude all measures whose intersections contain dimensions that are not configured within the Shared Hierarchies tab. In addition, you can enter a string of text; only measures whose name contains that string will be shown.
After you select the desired measure within the list and click OK, the Integration Tool creates a new fact. The new fact has most of its properties automatically specified by using the value of the corresponding measure property (for example, the fact type will be set to be the data type of the selected measure).
The Integration Tool supports several validations on fact content. As with the traditional Configuration Tools, these validations are evaluated in real-time as content is rendered by the UI. When a property of a fact violates a validity constraint, the field displaying that property is displayed with the Configuration Tools-standard red text color. In addition, the tooltip for the invalid cell contains a message describing the validity constraint that has been violated.
The following validity constraints apply to shared facts.
Fact name is a required property. It cannot be empty.
Fact names must be between one and thirty characters in length. They must begin with a letter and can contain letters, numerals, and underscores.
All fact names must be unique. No other element in the integration configuration may share the name with a fact.
Some names are reserved for use by RPASCE. In addition, fact names may not end with certain strings, such as _id, _stg, _ft.
Fact intersection is a required property. It cannot be empty but may be scalar.
All dimension references in a fact's intersection must resolve to dimensions that exist in the PDS.
Intersections cannot contain references to more than one dimension in any single hierarchy within a fact intersection.
Fact type is a required property. It cannot be empty.
Fact type must conform to one of a set of valid RPASCE measure types.
Fact group is a required property. It cannot be empty.
Fact groups must be between one and twenty characters.
Fact groups must begin with a letter and can contain letters, numerals, and underscores.
No two facts may have the same fact group if they do not have the same intersection.
All facts within a fact group belong to the same set of domains.
Use the Integration Map tab of the Integration Tool to configure the domain measures that will share data with a PDS fact.
The primary feature of the Integration Map tab is the integration map entries table. You can specify the domain measures that will participate in sharing data with the PDS by adding entries to the table. Click Add Entry to add an entry. Click Remove Entry to remove an entry. To specify the values for Fact name, Domain and Measure, use the drop-down list for fact and domain or enter a measure name for measure.
In addition, click Specify Integration Mapping to launch a Specify Integration Mapping Window.
Figure 10-16 Specify Integration Mapping Window
Use this Window to select a domain (when more than one is open within the Configuration Tools) and an application. You can also select the shared fact that will participate in the data sharing. After you make your selection, the Available Measures list is populated with the measures present within the selected domain and application whose properties are compatible with the selected fact. You can also enter a string into the filter box to filter the list of candidate measures.
After you select a measure and click OK, the Integration Tool automatically creates an entry in the Integration Mapping table and populates that entry with the specified values for fact, domain, and measure.
Fact
Fact is a required property. It cannot be empty.
The name listed for fact must correspond to a fact defined in the Shared Facts tab.
Domain
Domain is a required property. It cannot be empty.
The name listed for domain must correspond to a domain registered in the Domain Configurations tab.
Measure
Measure is a required property. It cannot be empty.
If the domain configuration for the domain specified for this entry is loaded into the Configuration Tools, the value of measure will be validated and must correspond to a measure in that domain.
If the domain configuration for the domain specified for this entry is loaded into the Configuration Tools, the specified measure must share the values for type, intersection, and NA Value with the fact specified for this entry.
Outbound Integration
Outbound Integration is an optional property. When not set, this property uses the default value of false, indicating that the shared fact is not in the Retail Bulk Data Outbound Integration.
To include the shared fact in the outbound integration, click the field and select true in the list.
Custom – The Custom is an optional property. When not set, this property uses the default value of false, indicating that the integration mapping entry is of GA configuration and is not configured by EE customer.
To indicate the integration map entry is EE-customized, click the field to select "true" from the drop down list.
When a new integration mapping is added, the Custom field is set to "true" by default.
With the addition of shared facts within the PDS, a new performance consideration becomes important within RPASCE applications. Operations that access the Oracle Database are optimized to read or write fact data. Internal testing of PDS operations has shown that the organization of facts into fact groups can have a significant impact on the amount of time required to perform operations within the PDS.
Because the tables that store the fact data within the PDS can contain multiple facts, processing operations against those tables are affected not only by the number of populated values of a single fact but also of all other facts within the table. This becomes even more of a concern when writing data to the fact tables, as those facts being updated by the write operation must be merged with other facts within the fact table that are not affected by the write.
For this reason, it is possible to design the tables of the PDS so that every fact is contained within a separate table. While this would prevent performance issues related to having multiple facts within a single table, it would not result in optimal performance. If facts that are read and/or written together are placed within a single table, they can be processed together, greatly improving performance.
It is therefore desirable to group facts together in the fact tables, but to do so using a distribution that groups facts accessed together into common tables, but that excludes facts that would not benefit from being grouped into those tables.
To illustrate, consider the following scenario. Assume two workbooks with measures that load from and commit to a partially overlapping set of facts. The sets of facts associated with the load and commit rule groups of the two workbooks have a distribution of facts being loaded and committed (listed as a through z) such as the following:
Figure 10-18 Example of the Distribution of Loaded and Committed Facts
In such a case, the measures being loaded and committed can be organized into groups such as:
Figure 10-19 Sample Grouping of Facts for Rule Groups
By organizing the facts into the groups shown in Figure 10-19, the performance benefit from grouping facts accessed together into groups is maximized and the performance hit from having additional facts within the groups that are not involved in the access is avoided.
When performing fact analysis such as previously described, the presence of conditional commits should be taken into consideration. Some commit rules include a condition that acts as a mask to prevent some range of the available data from being committed. Take for example a measure that only commits values for non-elapsed periods:
Measure1.master = if (current > today, Measure1, ignore)
Because of the way RPASCE processes conditional commits, facts committed using different conditions must be separated from each other, as each condition must be merged separately. In the previous example, if it was determined that the measures associated with facts w, x, y, and z are committed using the same condition but that the condition was not used for the measures associated with facts f, g, h, I, j, and k, then it is preferable to assign w, x, y and z to a separate fact group from that used for f, g, h, i, j, and k.
Figure 10-20 Modified Grouping of Facts to Accommodate Conditional Commits
Internal testing suggests that merging data into the Oracle Database is the process whose overall performance is impacted the most by fact grouping. For this reason, it is recommended that facts be assigned to fact groups in such a way as to optimize the writing of data to the PDS. The following example process determines the fact groups to use for the facts within the PDS and determines which facts should be assigned to each fact group.
Create a fact group for each unique intersection used by facts within the PDS.
Divide each group from step one into subgroups such that facts committed or loaded together are partitioned from the other facts within the group from step one.
Divide each group from step two, if necessary, to accommodate the use of conditional commits.
All facts are defined along an intersection. The PDS does not allow facts with different intersections to be stored together in a single table. Because the fact group is the entity that corresponds to a single table within the Oracle Database, it is therefore impossible to place facts with different intersections within a single fact group.
Once facts have been assigned to groups based upon the fact intersection, the set of facts for the PDS is divided into a number of pools. Treat each of these pools as an input to the second step of the fact grouping process.
Figure 10-21 Dividing Global Fact Pool by Fact Intersection
Each group created by grouping by intersection must now be subdivided in order to partition the facts based upon the process by which their information enters the PDS. Fact data is assumed to enter the PDS through one of three processes: workbook commit, batch process, or import from external system (either data load or through the PDS interface tables).
For each of the previous processes, it should be possible to determine the set of facts whose data enters the PDS in each operation. These sets of facts should be used to partition the initial fact groups to create individual sub-groups for the facts in each process.
Note that it is possible that some facts may be populated from more than one source. For example, a fact may initially be populated with raw data from an external source that is then transformed by a batch process or workbook prior to use by other processes within the application. This possibility is potentially more likely when dealing with applications that have never been integrated within the PDS.
When dealing with a fact with multiple sources, the sources must be prioritized based upon which process is the most time-critical. Once this prioritization has been done, the grouping suggested by the highest priority must be used. In cases in which the priority cannot be identified, or when no process's grouping provides an acceptable trade-off, the fact or facts in question must be assigned to a separate fact group.
Figure 10-22 Subdivision of Group by Data Source
The final step in determining the grouping for the facts within the PDS is to take the groups identified in Figure 10-22 and split them to partition facts that use conditional commits. Any fact groups created based upon workbook commit processes should be examined.
If any rules for the commit make use of a conditional commit (that is, the rule makes use of an if statement to commit only a subset of the measure used with the fact), the processing of any facts that do not make use of a conditional commit will be impacted by those facts that do use the conditional commit. In order to reduce this impact, the group containing the facts for the conditional and non-conditional commits must be divided again to isolate the conditional commit facts from the non-conditional commit measures. In cases where the commit group contains multiple conditional commits that use different conditions, each distinct condition must be assigned to its own group.
Figure 10-23 Subdivision of Group Due to Conditional Commits
Once these steps have been performed, the initial set of facts must now be partitioned into the set of fact groups that must be optimized for processes that write data into the PDS.
Figure 10-24 Subdivision of Group Due to Conditional Commits
