business data director - implementation guide

Siperian Hub

Business Data Director™ Implementation Guide

Siperian Hub Business Data Director Implementation Guide 2

© 2009 Siperian, Inc. [Unpublished - all rights reserved under the Copyright Laws of the United States]

THIS DOCUMENTATION CONTAINS CONFIDENTIAL INFORMATION AND TRADE SECRETS OF SIPERIAN, INC. USE, DISCLOSURE OR REPRODUCTION IS PROHIBITED WITHOUT THE PRIOR EXPRESS WRITTEN PERMISSION OF SIPERIAN, INC.

Siperian and the Siperian logo are trademarks or registered trademarks of Siperian, Inc. in the US and other countries. All other products or services mentioned are the trademarks or service marks of their respective companies or organizations.

DISCLAIMER

All sample code is provided by Siperian for illustrative purposes only. These examples have not been thoroughly tested under all conditions.

Siperian, therefore, cannot guarantee or imply reliability, serviceability, or function of this sample code. This is provided to you "AS IS" without any warranties of any kind. The implied warranties of non-infringement, merchantability and fitness for a particular purpose are expressly disclaimed.

3 Siperian Hub Business Data Director Implementation Guide

Table of Contents

Introduction................................................................................................. 5 Intended Audience and Scope of Document .............................................................. 5 Prerequisites........................................................................................................ 5

BDD Concepts .............................................................................................. 5 BDD Application ................................................................................................... 5 Subject Area ........................................................................................................ 5

Subject Area Characteristics ............................................................................... 6 Subject Area Group ........................................................................................... 6 One:Many Child Relationships ............................................................................. 6 Many:Many Child Relationships............................................................................ 6

Siperian Hub Feature Usage ................................................................................... 7 SIF.................................................................................................................. 7 Base Objects .................................................................................................... 7 Match Paths...................................................................................................... 7 Search............................................................................................................. 7 Cleanse Functions.............................................................................................. 8 Trust ............................................................................................................... 8 Hierarchy Manager ............................................................................................ 9 SAM and Security .............................................................................................. 9 In-Flight Data ................................................................................................... 9 History............................................................................................................. 9 Lookup Tables................................................................................................. 10 Exclusions ...................................................................................................... 10

Implementation Process .............................................................................. 11 Before You Begin ................................................................................................ 11 Configuration Process.......................................................................................... 11

Step 1: Create the BDD Application.................................................................... 11 Step 2: Configure Subject Area Group ................................................................ 12 Step 3: Configure Subject Area ......................................................................... 12 Step 4: Configure Layout and Other Display Features (Manual) .............................. 13 Step 5: Configure Validation and Cleanse (Manual) .............................................. 14 Step 6: Configure Search ................................................................................. 14 Step 7: Configure Match and Duplicate Searches in BDD ....................................... 15 Step 8: Configure the Workflow......................................................................... 15 Step 9: Localize BDD Applications (If Applicable) ................................................. 15 Step 10: Configure Security .............................................................................. 15

BDD Configuration Tool ............................................................................... 16


ORS Binding ...................................................................................................... 16 Add Application .................................................................................................. 16 Import Application .............................................................................................. 16 Validation, Application State & Deployment ............................................................ 17

Validation....................................................................................................... 17 Application State ............................................................................................. 18 Deployment.................................................................................................... 18

Edit Application .................................................................................................. 19 Logical ORS Databases..................................................................................... 19 Subject Areas ................................................................................................. 19

Manual BDD Configuration ........................................................................... 20 XML Tools.......................................................................................................... 20 Working with the XML ......................................................................................... 21 BDD Application ................................................................................................. 22 Subject Area ...................................................................................................... 22

Layout ........................................................................................................... 23 Label ............................................................................................................. 23 Validation and Cleanse ..................................................................................... 23 Lookup Localization ......................................................................................... 24 Search........................................................................................................... 25 Match ............................................................................................................ 26 HM Configuration............................................................................................. 26

Tasks................................................................................................................ 26 Charts............................................................................................................... 26 User Interface Extensions .................................................................................... 26 Online Help........................................................................................................ 27

Generic Help................................................................................................... 27 Custom Help................................................................................................... 27

Localization........................................................................................................ 27 Sizing and Platform Requirements................................................................. 28

DB Server Sizing ................................................................................................ 28 Application Server Sizing ..................................................................................... 28 Client and Network Sizing .................................................................................... 28

Application Components .............................................................................. 29 Appendix A: BDD Security Configuration ........................................................ 30 Appendix B: Locale Codes ............................................................................ 37

Language Codes ................................................................................................. 37 Country Codes ................................................................................................... 39


Introduction This document describes:

• concepts that are useful for working with the Siperian Hub Business Data Director™ (BDD)

• the implementation process for BDD applications

• the BDD configuration tool

• manual BDD configuration (BDDConfig.xml)

• sizing and platform requirements

• BDD application components

Intended Audience and Scope of Document This document is intended to be used by customers, partners, and Siperian Solution Delivery consultants as a hands-on implementation guide for all BDD deployments.

Prerequisites The implementation guide requires familiarity with the Siperian Hub architecture and understanding of all of the Siperian Hub solution components.

BDD Concepts This section describes core concepts that are useful for working with the BDD.

BDD Application A BDD application is the main configuration and deployment unit for BDD deployments. A BDD application consists of a BDD configuration file that describes all of the configuration elements of the application, as well as other auxiliary files (internationalization message bundles, help, and so on).

Subject Area The Subject Area is a core organizing concept for a BDD application. Other terms or concepts that are related to, or similar to, the Subject Area include: business object, composite object, and hierarchical entity. BDD uses the Subject Area definition to determine how to treat each foreign key relationship in an ORS.

The Hub Store maintains detailed metadata about tables and relationships defined in an ORS. This metadata includes relationships between base object tables that can represent:

• references to lookup tables

• links between a parent and related child data

• links between top-level entities


The Hub Store provides some of the metadata that allows BDD to understand how relationships should be treated. For example, the base object lookup indicator tells us when to treat a related table as a lookup with a pre-populated dropdown list.

For other relationships, it might not be clear how BDD should interpret them – whether they should be interpreted as relationships among tables in a Subject Area, or relationships between Subject Areas. The BDD Configuration tool is used to specify this additional relationship information for BDD.

Subject Area Characteristics A Subject Area represents a collection of data that should be treated as a unit from a business perspective. A Subject Area:

• has a single root record in a base object

• has some number of child records (via 1:many and many:many relationships)

Subject Area Group Each Subject Area belongs to a Subject Area Group, which defines the base object that its Subject Areas have as their root (also called the primary object). A Subject Area Group can contain one or more Subject Areas.

An ORS using a Party model (a single base object representing different entity types) will have a Subject Area Group with multiple Subject Areas.

One:Many Child Relationships The child record has a direct foreign key to the primary object. BDD supports two kinds of one:many relationships:

Relationship Description

One:Many The list of child records will be displayed in a tab below the primary data.

Logical One:One

The expectation is that there should be only one child record for each primary object. The data is shown in the form with the primary object. If there is more than one child, BDD provides a means to resolve this.

Many:Many Child Relationships The child record is related to the primary object through a relationship table. BDD supports two kinds of relationships:


Part Of The child record belongs to the primary object. When adding a child, both the relationship and child records are added.

Reference The child is another Subject Area. When adding a child, only a relationship record is added. The BDD user must search for the Subject Area child to be related. In order to edit the child data, the Subject Area for that child must be opened.


Siperian Hub Feature Usage

SIF All interaction between a BDD application and an ORS is through the SIF APIs. There is no direct access to the ORS database. (The exception is that charts can be configured to use an application server datasource to fetch report data.)

The BDD Configuration tool uses SIF to access metadata about an ORS, but uses a datasource to directly access the CMX_SYSTEM.C_REPOS_DS_CONFIG table.

Base Objects In Siperian Hub XU SP2, the SIF APIs that operate on Packages were extended to also allow operation directly on base objects. Column-level security is now configured in SAM by defining role-based access to base objects and their columns.

BDD directly references base objects for all get and put operations. BDD uses packages only for displaying search results.

Match Paths The child relationships in BDD are defined using match paths. Before BDD, match paths have been used strictly for defining match columns. The match path definition works equally well for defining the child relationships in BDD.

In order to add a child to a Subject Area, it may be necessary to create a new match path for that child (if data in the child is not used for matching). No additional performance overhead is incurred by defining such a match path.

Note: The searchQuery API has been extended to allow advanced searching against a base object based on data in its child records – also referenced via match paths.

Search Search for data in a Subject Area can be based on either of our search APIs (searchQuery or searchMatch). In both cases, a display package is used to show the search results.

Basic (SQL-based) Search Basic Search uses the searchQuery API. A search can be based on data in the primary object record or any of its child records.

Extended - Match based Search Extended search uses the searchMatch API using matchType=NONE. This is the mode of match intended for searching – not using a predefined match rule set. Any of the data in the Subject Area that contributes to a match column can be used as search criteria. If one match column is defined, data for the fuzzy match key must be provided. BDD requires an entry in this field before you can run the search.


Cleanse Functions BDD uses the put API rather than cleansePut. However, BDD can call the cleanse API for each base object record before it is saved. The cleanse function can perform regular data cleansing and standardization, and it can also be used to perform custom validations on the data.

Each configured cleanse function is called before data is persisted:


primary data (main form on the screen)

Cleanse is invoked when Save is selected. Save continues only if cleanse succeeds and there are no validation errors.

child data Cleanse is invoked for add/edit child when Apply is selected on the child data dialog box. The dialog closes only if cleanse succeeds and there are no validation errors.

Note: The cleansePut API poses problems for an application such as BDD. The reason for this is that, when using cleansePut, the interface for a record is a mapping, while the interface for reading data is a package or base object. An application such as BDD needs a consistent record interface for reads and writes.

Cleansing & Standardization BDD configuration provides a simple means for connecting base object records to the inputs and outputs of a cleanse function. The data in the base object record is updated with the outputs from the cleanse function.

Note: Only those base object columns that are included in the layout in the Subject Area can be inputs or outputs for the cleanse function.

Validation A cleanse function can be used to perform custom data validation. Validation results are processed if the cleanse function has a validationStatus output parameter. If this parameter is blank, there are no validation errors and the process can continue.

If there are validation errors, the validationStatus parameter will include a series of validation messages that include the inputParameter name and a message. Each validation error is then associated with an input value on the BDD application UI.

Note: The Resource Kit contains the ValidationCleanseLib sample, which provides an example of a cleanse library with functions that perform validation.

Trust A BDD application uses a specified source system for all of its operations. Data entered and updated through a BDD application follows all the standard trust rules. The data entered in a BDD application is applied to the base object record based on the trust and validation rules configured in the Siperian Hub.

When viewing cross reference data, the user can choose to promote the value of a field from a specific cross reference record. This results in a trust override for that field.


Hierarchy Manager If Hierarchy Manager (HM) is configured for an ORS, BDD can be configured to work with this configuration according to the following rules:

• Each HM entity must be configured as a Subject Area. HM is used to model the relationships between Subject Areas.

• A BDD application operates against a single HM configuration (profile/sandbox combo). BDD uses the SAM access control configuration, rather than different HM configurations, to manage user access control. The HM configuration used by BDD should include all HM entity and relationship types to be supported in the BDD application.

SAM and Security BDD makes extensive use of the SAM access control as configured in the Hub Console. For more information, see “Appendix A: BDD Security Configuration” later in this guide.

Object and Column Security SAM provides role-based security on objects and columns defined in an ORS. A BDD application works closely with this security configuration. The data that is shown, and the operations that are available for an individual user, depends on the role(s) assigned to that user account.

Data Security SAM does not provide row-level data security (restricting users from seeing certain records based on the contents of those records). BDD, however, provides a simple data security model. Within the search configuration of each Subject Area, security filters can be defined. A security filter specifies a filter that is to be applied for all searches by users assigned to a specific role.

For example, a security filter can specify COUNTRY_CODE = ‘US’ , which can apply to users with the US Data Steward role. Each filter can apply to multiple roles. Any number of filters can be created for a Subject Area.

In-Flight Data In-flight data is business data that can go through different states (ACTIVE, PENDING, or DELETED) while progressing through a workflow. BDD provides support for in-flight data using the state management features introduced in Siperian Hub XU SP1 and in its task management features.

Data can be added or updated and ‘Submitted for Approval’ rather than saved. The data changes are stored as PENDING changes – the data is not applied to the base object. A task is created for another user to approve this change. Once approved, the PENDING data is promoted to ACTIVE and is then applied to the base object.

History BDD provides a Subject Area view of the history of changes for each record (history must be enabled on the Base Objects). BDD shows a timeline view of events for the record and its child records. A point-in-time view of the data can also be shown.


Lookup Tables BDD provides support for lookup tables. BDD will populate a dropdown list of values to choose from for a foreign key to a lookup table.

In Siperian Hub XU SP2, a new indicator (lookup_ind) was added to c_repos_table to indicate whether a table contains lookups or regular data. This option is set in the Hub Console (the Advanced tab of the Base Object properties in the Schema Manager). By default, this indicator is disabled. It should be enabled in the Schema Manager for base objects that contain lookup codes. For more information about the Schema Manager, see the Siperian Hub Administration Guide or the Admin Help in the Hub Console.

When BDD sees that a column has a foreign key to another table, it checks the other table to determine whether it is a lookup table. If it is, BDD creates a dropdown list in the BDD UI for that column, populated with values from the lookup table. The column in the lookup table that is used depends on the ‘Lookup Display Name’ configured for the relationship in the Schema Manager.

If the related table is not a lookup table, BDD expects that table to be configured is a Subject Area. In the BDD UI, a button is be provided to allow searching for the Subject Area record to relate to.

Exclusions

Dependent Objects Dependent Objects are a deprecated feature of the Siperian Hub and are not supported by BDD.


Implementation Process This section describes the recommended high-level process for configuring BDD applications. This process should be used as a template for creating BDD implementation plans. The main goal is to outline the steps in the build/test cycle that would provide an efficient cycle for rapid BDD development, and using the intermediate stages of the configuration process for getting additional feedback and validating requirements with the customer.

Before You Begin We are assuming the following prerequisites:

• Siperian Hub, cleanse adapters, and Cleanse Match Servers are already configured and operational. For more information, see the Siperian Hub Installation Guide for your platform.

• The ORS schemas are configured and contain some test data. You need to use both the BDD Configuration tool and the Hub Console for BDD instance configuration. The Hub Console is used to create the necessary configuration elements in the target ORS to enable the BDD application configuration (such as lookups, match path components, and so on).

• All base objects required for this BDD instance need to be configured as SECURE in the Secure Resources tool in the Siperian Console.

• Configuration and initial testing should be done using a Siperian Hub user account with unrestricted privileges for the target ORS schemas. You can either use the admin account or any other account that is configured with all privileges to ALL_GLOBAL_RESOURCES group .

• The analysis and modeling for defining the subject areas and the business rules has been completed.

For more information about Hub Console tools, see the Admin Help or the Siperian Hub Administration Guide.

Configuration Process The BDD configuration process involves the following steps. Bear in mind that this is an iterative rather than simply a linear, one-time process.

Step 1: Create the BDD Application Create the BDD application in the BDD Configuration tool. For BDD instances that span multiple ORS databases, it is recommended that you create the individual subject areas separately, and then integrate the individual XML configuration files to create a multi-ORS BDD instance.


Consider the following configuration issues: Consideration Description

Application Source System

The most important property defined at the application level is the source system used by BDD for updates. You should either use the Admin system or create a separate source system as the BDD source system. The BDD source system needs to have the highest level of trust to guarantee that the changes applied by BDD users override the other contributing values and end up in the BVT (master record).

HM Configuration You need to define the HM profile that will be used for configuring the BDD Hierarchy Manager functionality. The HM configuration needs to be specified up front if you are planning to use the BDD HM functionality in order to ensure that the subject area definitions are consistent with the HM Entity definitions.

Step 2: Configure Subject Area Group Create the subject area group using the BDD Configuration Tool.

Step 3: Configure Subject Area Identify the data attribute of the subject area root object that will be used to differentiate the subject areas that belong to the same subject area group.

Step 3.1: Configure Subject Area in the Hub Console In the Hub Console:

1. In the Schema Manager, review the match path components that are configured for the root object of the subject area and verify that there are match paths for each and all of the child objects that need to be included in the Subject Area.

2. In the Packages tool, create the search display package, which will be used to display the search results for the given subject area.

3. In the Schema Manager, validate Subject Area lookup dependencies. Lookup Mechanism

Description

Code Lookup tables

Code lookup tables need to have the Lookup Indicator set to TRUE.

Entity Lookups in BDD

Entity Lookups in BDD can only be done to entities that are configured as subject areas. This can introduce complex dependencies between the subject areas. You can exclude the entity lookups from the initial BDD config if there are dependencies on the other subject areas have not been configured. The lookup fields can be added after all subject area dependencies are satisfied


Step 3.2: Configure Subject Areas in the BDD Configuration Tool In the BDD Configuration tool:

1. Create the basic Subject Area configuration and test it by validating deploying the application.

2. Add the children to the Subject Area. All children need to have a properly-configured match path to the root object of the subject area. The Config tool displays the names of the match path components rather than the names of child objects.

To simplify troubleshooting for issues with child configuration, you should add children one at a time, and then deploy/test the configuration when each child is added.

Validate, deploy and test the changes.

1. Create a query for the new search. Verify that all appropriate attributes are available.

2. Create a new Subject Area entity instance

a. Validate that all children can be created and that all fields display in the expected order.

b. Validate that all lookup fields display correctly and have the correct lists of values. If fields do not display the lookup controls, you need to adjust the Lookup field configuration.

In order to execute the configuration tasks in the next steps, you need to export the BDD application and edit the BDDConfig.xml file manually. Once saved, the changes need to be imported back into the BDD Configuration tool in order to take effect.

Note: You should use an XML authoring environment that support XML schema validation. The configuration file should be validated against the BDD configuration schema (siperian-bdd-config-1.xsd) before it is imported into the BDD Configuration tool.

Step 4: Configure Layout and Other Display Features (Manual) This section provides a high-level overview of the configuration elements that can be specified manually in the BDDConfig.xml file. See the “Manual BDD Configuration” section later in this document for more information about the following configuration steps.

In the BDDConfig.xml file:

1. Specify the number of columns for the object layouts.

2. Configure the fields to date fields to use the proper date / datetime format

3. Specify the field size for all attributes.

4. Control the different subsets of fields to be visible in the data view, merge, and comparison dialogs

5. Create labels for the data view tabs.

Deploy and test the layout changes by viewing the existing subject area instances and creating the new ones.


Step 5: Configure Validation and Cleanse (Manual) In the BDDConfig.xml file:

1. Set required attribute to “true” for the fields that need to be validated by BDD.

2. Implement the cleanse and validation functions. BDD uses Siperian cleanse functions for all cleanse and validation in BDD. The validation functions use the outbound parameters to communicate validation status and validation error messages to BDD.

a. Create the validation function library using the ValidationCleanseLib sample in the Siperian ResourceKit as a template.

b. Deploy the created cleanse library into the ORS.

c. Create the regular cleanse functions and mappings to be used by BDD.

d. Add the cleanseFunction element for all BDD objects that require cleanse and validation.

Deploy and test cleanse and validation functions by creating a new Subject Area entity with all the children for which you added the cleanse/validation functions. Verify that all fields are properly validated.

Step 6: Configure Search Search configuration involves basic and extended search as well as public queries.

Step 6.1: Configure Basic Search Basic search allows users to search for the Subject Area instances by creating and executing queries using all available attributes on the Subject Area. The results are displayed using a Siperian Hub package. BDD uses the new mode of searchQuery API that were introduced in Siperian Hub XU SP2. This mode provides support for separating the objects that filters are executed against from the view used to display the results.

The search package needs to satisfy the following criteria:

• is based on the root BO of the Subject Area

• returns a single result row for each Subject Area entity

• contains the ROWID_OBJECT of the root base object of the Subject Area

The search package must contain only the columns that are needed to present the search results to the user, and not the attributes to facilitate searching and filtering.

BDD does not enforce the de-duplication of search results, so that package needs to be constructed to return a single row for every found entity.

1. Test the search package directly via SQL to ensure that it returns a single row for each entity. You can do this by running spot-checks on the entities with a known number of children of a different types

2. Identify the primary searchable attributes. In the Schema Manager, create the appropriate custom indexes to support these searches.


3. Test the searches by creating the different types of queries and running them in BDD. Use different combinations of search criteria to ensure the satisfactory performance of these searches.

Step 6.2: Configure Extended Search Extended search uses the searchMatch API to request fuzzy searches through the data. You need to ensure that all necessary match columns have been created. No extra configuration is required in BDD to enable the fuzzy search. BDD will automatically map the search criteria supplied by the user to the available match columns and execute the search.

Before testing the extended search configuration, verify that the data has been properly tokenized. Then test the fuzzy search facilities by creating the search queries that include the Subject Area attributes that have underlying match columns.

Step 6.3: Configure the Public Queries BDD allows administrators and expert users to share the queries that they create with all other users. We recommend that you configure at least one most commonly-used search as public for each of the subject areas in the BDD instance. This will allow users to quickly navigate through all subject areas without needing to create their own versions of the common queries.

Step 7: Configure Match and Duplicate Searches in BDD See “Match” in “Manual BDD Configuration” later in this document for details on configuring the match rules to be used by a Subject Area for duplicate checks.

Step 8: Configure the Workflow For instructions on configuring the BDD tasks, refer to the Siperian Hub Business Data Director Workflow and Task Configuration on SHARE.

Step 9: Localize BDD Applications (If Applicable) See “Lookup Localization” and “Localization” later in this document for details on creating locale-specific versions of BDD applications.

Step 10: Configure Security All application security in BDD is controlled by Siperian Hub Security Access Manager (SAM) policies configured in the Hub Console. BDD application behaviors can be very sensitive to the security configuration. We recommend using the admin user or a user with full privileges to all secure resources for the configuration of BDD and the initial functional tests.

For more information, see “Appendix A: BDD Security Configuration” later in this document.

Note: The date security rules can be set up according to the instructions in “Data Security” later in this document.


BDD Configuration Tool The BDD Configuration tool is used to add, modify and manage BDD applications.

A BDD application consists of an XML configuration file, resource bundles, help files, and other components, as described in “Application Components” later in this document. A complete application can be imported or exported as a ZIP file containing all of these components.

In its initial releases, the BDD Configuration tool is intended to be used to create the initial configuration version of a BDD application. It does not yet expose all of the configuration options. Any features that are not supported in this version of the BDD Configuration tool can be configured manually by exporting and editing the XML configuration file directly, then re-importing the file back into the BDD Configuration tool. For more information, see “Manual BDD Configuration” later in this document.

ORS Binding A BDD application configuration declares one or more ”logical ORS databases.” All Siperian Hub objects that are referenced in a configuration are always in the context of a specific logical ORS. For a BDD configuration to be valid, the objects it references must exist in a physical ORS.

When a BDD application is added or imported, the logical ORS databases it declares must be bound to a physical ORS that is registered with the Siperian Hub. This binding is used:

• to validate the configuration

• by the BDD Configuration tool to fetch metadata about the ORS, and

• as the ORS for the running BDD application to connect to

Add Application The Add command is used to create a new application from scratch. The Import command can be used to create an application by importing an existing configuration. A new BDD application is defined by its name, display name, description, and list of logical ORS databases.

After adding the application, choose the Edit command to make changes to the application configuration.

Import Application The Import command provides the following three import options. Two options are for importing a full application, and one option is for importing a component into an existing application.

Import Option Description

Import BDD configuration only (XML)

Create a new BDD application by importing the BDD configuration XML. This can be used to replace an existing BDD application with the same name. If so, the existing application is entirely replaced (as if you performed a delete followed by an import).


Import Option Description

Import complete BDD application (Zip)

Create a new BDD application by importing a Zip file containing the various component files (XML, resource bundles, help files, and so on).

Import to existing BDD application

Update an existing BDD application by importing a single file. This is used to add or replace any of the component files of the BDD application.

Validation, Application State & Deployment The following persisted parameters determine how and if a BDD application is deployed:

Parameter Description

valid_ind Contains the most recent validation status for the application. The validation status is a single value that represents the highest (most severe) error that has been found.

active_ind Managed directly by the user to reflect the intention for deployment of the application.

Validation BDD configuration is loosely coupled with the metadata in an ORS. The configuration contains references to an object in an ORS. However, changes to an ORS (addition, modification or removal of base objects, columns, cleanse functions, and so on) are not automatically reflected in the BDD configuration. For this reason, the BDD validation process is necessary and must be repeated periodically.

Validation is run in the following circumstances:

• when requested by the user in the BDD configuration tool

• when importing a BDD configuration

• before deploying an application when the application server is started up

Available validation levels are similar to those used for the Metadata Manager, with the addition of the Not Validated and No Errors levels.

valid_ind Validation

Level Description

-1 Not Validated The BDD application has not been validated.

0 No Error No errors or warnings were found during validation.

1 Information Provides information to the user. No configuration changes are required.

2 Warning A configuration might need to be changed, but should cause no run-time problems.

3 Error A configuration error must be fixed. Run-time problems can be expected.


valid_ind Validation Level

Description

4 Critical Error Same as Error, but indicates a problem that requires even more urgent attention.

5 Fatal Error An error that prevents the BDD application from running at all. The application will not be deployed under any circumstance.

Application State The application state is controlled by the user in the BDD Configuration tool. It stores the intended deployment for the BDD application.

Note: A BDD application can be deployed even if the configuration contains errors. Only fatal errors (as described above) will prevent a BDD application from being deployed. It can be useful to deploy a BDD application that contains errors when building out an application, allowing the implementer to test parts of the configuration while other parts are incomplete.

active_ind Name Description

-1 Not deployed BDD application is not deployed. Useful when the application is in development. Changes can be made and saved without the additional overhead of deploying the application.

0 Limited deployment

BDD application is deployed, but only users that are administrators can log in. The application will not show up in the list of available applications. You must access the application using its full URL (http://xxx/bdd?bdd_name=Name)

1 Full Deployment BDD application is deployed for full use. It shows up in the list of applications and any authorized users can use the application.

Deployment Deployment is the process of taking a BDD configuration and making it available as an application. An application is not deployed if active_ind is -1.

Deployment occurs in response to the following events:

Event Description

Application Server Startup

All applications with active_ind that is not -1 are first validated. If the validation level is not Fatal Error, then the application is deployed. At this time, only a partial validation is run to check for fatal errors.

Import / Save

Any time an application is imported or saved, it is also deployed unless its active_ind is -1.


Edit Application The Edit command displays a screen that allows you to view and modify the configuration for a BDD application. It will guide you through the configuration details, loading metadata about the physical ORS to present the options available.

The following command buttons are available at the top of the screen:

Button Description

Save Saves the latest changes to the database. If the application state is anything but Not Deployed (-1), the BDD application is redeployed after it is saved.

Validate Runs validation on the current BDD application configuration and displays the validation report.

Bind ORS Used to change the ORS binding.

Logical ORS Databases When editing a configuration, the first task to complete is the configuration for the logical ORS databases. For each of these ORS databases, you must select a source system. If Hierarchy Manager is to be used, then the HM configuration must also be selected.

Subject Areas The lower portion of the screen provides a tree that shows how the Subject Areas are configured. The levels in the tree are: 1) BDD Application, 2) Subject Area Group, 3) Subject Area and 4) Subject Area Child.

Tree Level Description

Subject Area Group

This identifies the logical ORS group to which the child Subject Areas belong, and which base object is the Primary table for these Subject Areas. A Subject Area Group can have one or more child Subject Areas – all sharing the same Primary table. These Subject Areas are grouped together in the BDD application.

Subject Area

Specifies whether this Subject Area represents an HM entity type. If not, but it uses a column sub–type, this can also be specified using the subTypeQualifier. Other items specified are: the package to use to display search results, the match rule set and match type to use for duplicate checks, and the columns from the Primary table that are part of this Subject Area.

Subject Area Child

For each child, you must specify the following information: the type of relationship, which match path leads to the child table (the match path list is populated based on the relationship type selection), and the columns from the child table that are to be displayed. Information about the types of relationships can be found in “Subject Area.”


Manual BDD Configuration The BDD configuration file is an XML document that can be modified in the BDD Configuration tool or exported and edited manually. To edit the configuration for an existing application:

1. Export the application to a zip file.

2. Unzip the application file.

3. Edit the configuration file (BDDConfig.xml).

4. Import the edited configuration file directly to replace the one in the database. Alternatively, the BDD application can be re-zipped and the full application can be imported to replace all the files for the application.

XML Tools The Siperian Hub Resource Kit includes an XML schema for the BDD configuration file. This is very useful when working with XML editors. It can guide you in editing the file and, most importantly, is used by the editor to verify the correctness of the XML in the BDD configuration file. The BDD configuration file should pass this test before being imported into the BDD Configuration tool.

While a simple text editor can be used to modify the BDD configuration, there are many XML editing tools that make working with XML much easier, including:

Editor URL

XML Copy Editor http://xml-copy-editor.sourceforge.net/

XML Spy http://www.altova.com/products/xmlspy/xmlspy.html

oXygen http://www.oxygenxml.com/

The BDD sample in the Resource Kit contains the following components that can help with manual configuration.

Resource Kit Item Description

siperian-bdd-config-1.xsd XML schema for the BDD configuration file.

HTML documentation for the XML schema

Javadoc-style documentation. Provides the same information found in the XML schema, but in a form that is easier to browse. NOTE: Please refer to this for the most detailed information on the elements and attributes in the XML.

Sample BDD configuration

To be used with the sample schema.


Working with the XML A BDD configuration XML file can easily ru to hundreds of lines. A full file will not be shown here, only relevant snippets. You can find a full configuration file in the Resource Kit or by exporting it from the Configuration tool.

Here’s an example of a Subject Area Group with a single Subject Area: <subjectAreaGroup name="Customer" primaryObjectUid="C_PARTY"> <subjectArea name="Person"> <primaryObject hmEntityTypeUid="Person"> <subTypeQualifier columnUid="C_PARTY|PARTY_TYPE" filterValue="Person"/> <cleanseFunction cleanseFunctionUid="BDD Cleanse and Validation Library|CVPerson"> <cleanseInput> <cleanseColumn columnUid="C_PARTY|FIRST_NAME" parameterName="firstName"/> <cleanseColumn columnUid="C_PARTY|MIDDLE_NAME" parameterName="middleName"/> <cleanseColumn columnUid="C_PARTY|LAST_NAME" parameterName="lastName"/> </cleanseInput> <cleanseOutput> <cleanseColumn columnUid="C_PARTY|FIRST_NAME" parameterName="firstName"/> <cleanseColumn columnUid="C_PARTY|MIDDLE_NAME" parameterName="middleName"/> <cleanseColumn columnUid="C_PARTY|LAST_NAME" parameterName="lastName"/> <cleanseColumn columnUid="C_PARTY|DISPLAY_NAME" parameterName="displayName"/> </cleanseOutput> </cleanseFunction> <layout columnsNum="3"> <column columnUid="C_PARTY|NAME_PREFIX_CD" editStyle="FIELD" horizontalStyle="SMALL"/> <column columnUid="C_PARTY|FIRST_NAME" editStyle="FIELD" horizontalStyle="MEDIUM" required="true"/> <column columnUid="C_PARTY|MIDDLE_NAME" editStyle="FIELD" horizontalStyle="MEDIUM"/> <column columnUid="C_PARTY|LAST_NAME" editStyle="FIELD" horizontalStyle="MEDIUM" required="true"/> <column columnUid="C_PARTY|GENERATION_SUFFIX_CD" editStyle="FIELD" horizontalStyle="SMALL"/> <column columnUid="C_PARTY|BIRTHDATE" editStyle="CALENDAR" horizontalStyle="MEDIUM"/> <column columnUid="C_PARTY|GENDER_CD" editStyle="FIELD" horizontalStyle="SMALL"> <columnI18NLookup languageCdUid="C_LU_GENDER_LCL|LANGUAGE_CODE" countryCdUid="C_LU_GENDER_LCL|COUNTRY_CODE" lookupFKUid="C_LU_GENDER_LCL|GENDER_CODE" localizedNameUid="C_LU_GENDER_LCL|LOCALIZED_STRING"/> </column> <column columnUid="C_PARTY|TAX_ID" editStyle="FIELD" horizontalStyle="MEDIUM"/> <column columnUid="C_PARTY|DISPLAY_NAME" editStyle="FIELD" horizontalStyle="LARGE"/> </layout> <label existsFormat="{1},{2}"> <column columnUid="C_PARTY|LAST_NAME"/> <column columnUid="C_PARTY|FIRST_NAME"/> <column columnUid="C_PARTY_ELECT_ADDR|ELECTRONIC_ADDRESS"/> </label> </primaryObject> <search displayPackageUid="PKG_PERSON_SEARCH"> <dataSecurity>


<securityFilter columnUid="MATCH_PATH_COMPONENT.C_MT_ADDRESS|STATE_CD" filterValue='CA'> <securityRole roleUid="Customer-CA"/> </securityFilter> </dataSecurity> </search> <match> <matchRuleSet uid="C_PARTY|IDL" type="BOTH"/> </match> <taskAssignmentConfig task="UpdateWithApproval" roleUid="DataSteward"/> <taskAssignmentConfig task="UpdateWithOptionalApproval" roleUid="DataSteward"/> <taskAssignmentConfig task="ReviewNoApprove" roleUid="Manager"/> <taskAssignmentConfig task="FinalReview" roleUid="SrManager"/> <taskAssignmentConfig task="Merge" roleUid="DataSteward"/> <taskAssignmentConfig task="Unmerge" roleUid="DataSteward"/> </subjectArea> </subjectAreaGroup>

Items in this XML that are not currently managed by the BDD Configuration tool (and therefore require manual editing) are bolded.

In some cases, as with the cleanseFunction element (which is optional), the BDD Configuration tool will not place this element in the XML. It is necessary to add the element.

In other cases, as with the editStyle and horizontalStyle column attributes, the items are already in the XML with default values that can be edited.

Refer to the HTML documentation for the XML schema for details on the elements, attributes, and allowed values.

BDD Application The top-level element in the XML is the bddApplication. All but one of its one attributes are managed by the BDD Configuration tool.

If you want to change the session timeout from its default of 5 minutes, you can set the sessionTimeoutMinutes attribute. as shown in the following example (set to 30 minutes).

<bddApplication xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" name="AppName" displayName="Application Name" defaultLocale="en" sessionTimeoutMinutes="30" xsi:noNamespaceSchemaLocation="./siperian-bdd-config-1.xsd"> ... </bddApplication>

Subject Area The BDD Configuration tool creates a more complete template for this area of the configuration file. The items described in this section might need modification directly in the XML.


Layout The following items in the layout are not configured in the BDD Configuration tool:

Layout Item Description

columnsNum Change this to modify the form layout of the primary or child data.

Column The following attributes are initialized with default values and can be modified:

• editStyle

• horizontalStyle

• required

• visibleForCM

• visibleForDV

• visibleforXREF

Label The default label element is included in the XML export file. This shows the Subject Area name in the label. It can be customized by specifying the columns from the Subject Area that should be used in the label, and the format patterns. For example, you can specify a label that will show the name for a Person Subject Area.

In the following example, the label for an existing Subject Area will be “<LastName>, <FirstName>”.

<label existsFormat="{1},{2}"> <column columnUid="C_PARTY|LAST_NAME"/> <column columnUid="C_PARTY|FIRST_NAME"/> </label>

Validation and Cleanse Validation and cleanse are optional elements for a primaryObject, one2ManyChild, and many2ManyChild. The Configuration tool does not create the cleanseFunction element.

The cleanseFunction is very similar to the mapping definition in the Hub. In this case, however, the base object record provides both the inputs and the outputs for the cleanse function.

A cleanse function is called when:

• Primary data – the Save

Name Standardize

C_PARTY

FIRST_NAME MIDDLE_NAME LAST_NAME DISPLAY_NAME

lastName

middleName

firstName

Inputs

validationStatus

displayName

lastName

middleName

firstName

Outputs


button is selected.

• Child data – the Apply button is selected.

The data the user has entered in the base object record is fed into the cleanse function as specified. This record is then updated by the outputs from the cleanse function.

The cleanse function can report validation errors if it has a validationStatus output. If there are validation errors, the Save or Apply action does not proceed, and the errors are displayed in the BDD Configuration tool UI next to any field(s) with problems.

The following example shows the configuration for the cleanse function just described:

<primaryObject hmEntityTypeUid="Person"> <cleanseFunction cleanseFunctionUid="BDD Cleanse and Validation Library|CVPerson"> <cleanseInput> <cleanseColumn columnUid="C_PARTY|FIRST_NAME" parameterName="firstName"/> <cleanseColumn columnUid="C_PARTY|MIDDLE_NAME" parameterName="middleName"/> <cleanseColumn columnUid="C_PARTY|LAST_NAME" parameterName="lastName"/> </cleanseInput> <cleanseOutput> <cleanseColumn columnUid="C_PARTY|FIRST_NAME" parameterName="firstName"/> <cleanseColumn columnUid="C_PARTY|MIDDLE_NAME" parameterName="middleName"/> <cleanseColumn columnUid="C_PARTY|LAST_NAME" parameterName="lastName"/> <cleanseColumn columnUid="C_PARTY|DISPLAY_NAME" parameterName="displayName"/> </cleanseOutput> </cleanseFunction> </primaryObject>

Note: Each columnUid in the configuration above must also be included in the associated layout for the primary object or child.

Lookup Localization BDD automatically populates a dropdown list of acceptable values for columns that are configured in the Schema Manager as lookups, as described above in “Lookup Tables”.

BDD also supports the localization of the lookup display values. The following example shows how to configure a base object to support this.

In a normal ORS, the tables C_PARTY and C_LU_SALUTATION would exist as shown here. The only change is the addition of C_LCL_SALUTATION.

To generate the list of values for a particular user’s locale, BDD first looks for a lookup name in C_LCL_SALUTATION based on the locale (language and / or country). If a name is not found, then the lookup name (SALUTATION_DISP) from the lookup table is used.


The configuration for this specifies that the column has localized lookup values and which table and columns are used. The following samle XML shows how the previous example would be configured:

For the above example, it would look like: <column columnUid="C_PARTY|SALUTATION_CODE" editStyle="FIELD" horizontalStyle="SMALL"> <columnI18NLookup languageCdUid="C_LCL_SALUTATION|LANGUAGE_CODE" countryCdUid="C_LCL_SALUTATION|COUNTRY_CODE" lookupFKUid="C_LCL_SALUTATION|SALUTATION_CODE" localizedNameUid="C_LCL_SALUTATION|LOCALIZED_STRING"/> </column>

The values for LANGUAGE_CODE and COUNTRY_CODE are two-letter ISO codes. For more information, see “Appendix B: Locale Codes” later in this document.

Search

Match Columns Extended search uses the searchMatch API with matchType=NONE. In the default configuration, all possible match columns get generated on each searchMatch request.

The matchColumns element can be used to fine-tune the searchMatch operation. For example, if the telephone number column is used for both exact and fuzzy match columns, you might not want both of those to be used in the search. When the matchColumns element is specified, only the specified columns are used in the searchMatch request. <matchColumns> <matchColumn matchColumnUid="C_PARTY|Person_Name"/> <matchColumn matchColumnUid="C_PARTY|Organization_Name"/> <matchColumn matchColumnUid="C_PARTY|Ex_Party_Type"/> <matchColumn matchColumnUid="C_PARTY|Address_Part1"/> <matchColumn matchColumnUid="C_PARTY|Address_Part2"/> <matchColumn matchColumnUid="C_PARTY|Postal_Area"/> <matchColumn matchColumnUid="C_PARTY|Telephone_Number"/> </matchColumns>

Data Security As described previously in “Data Security”, row-level security filters can be configured for each Subject Area. By default no security filters are defined. In the following example, multiple securityFilters are defined for each Subject Area. Each securityFilter can apply to multiple roles. <dataSecurity> <securityFilter columnUid="MATCH_PATH_COMPONENT.C_MT_ADDRESS|STATE_CD" filterValue='CA'> <securityRole roleUid="Customer-CA"/> <securityRole roleUid="Customer-US-West"/> <securityRole roleUid="Customer-US"/> </securityFilter> <securityFilter columnUid="MATCH_PATH_COMPONENT.C_MT_ADDRESS|STATE_CD" filterValue='NY'> <securityRole roleUid="Customer-NY"/> <securityRole roleUid="Customer-US-East"/> <securityRole roleUid="Customer-US"/> </securityFilter> </dataSecurity>

For each user, all securityFilters that apply are joined by a logical OR (someone in the Customer-US role would see results where state=’CA’ or state=’NY’). If a user


is assigned to a role that has no securityFilters defined, no filters are applied, and such a user has access to all data.

Match Find Duplicates uses the searchMatch API with the match rule set and match type configured in the match element. In the default configuration, all possible match columns get generated on each searchMatch request.

The matchColumns element can be used to fine-tune the searchMatch operation. For example, if the telephone number column is used for both exact and fuzzy match columns, you might not want both of those to be used in the search. When the matchColumns element is specified, only the specified columns are used in the searchMatch request. <matchColumns> <matchColumn matchColumnUid="C_PARTY|Person_Name"/> <matchColumn matchColumnUid="C_PARTY|Organization_Name"/> <matchColumn matchColumnUid="C_PARTY|Ex_Party_Type"/> <matchColumn matchColumnUid="C_PARTY|Address_Part1"/> <matchColumn matchColumnUid="C_PARTY|Address_Part2"/> <matchColumn matchColumnUid="C_PARTY|Postal_Area"/> <matchColumn matchColumnUid="C_PARTY|Telephone_Number"/> </matchColumns>

HM Configuration If an HM Configuration has been set in the BDD Configuration tool, an hmConfiguration element is set up in the configuration XML file. The optional hmOneHopLimits and hmManyHopLimts are not included, but they can be added with appropriate values, as shown in the following example. <hmConfiguration hmConfigurationUid="Default|Master"> <hmOneHopLimits totalRels="1000"/> <hmManyHopLimits hops="20" relsPerEntity="50" totalRels="1000"/> </hmConfiguration>

Tasks For more information, refer to the Siperian Hub Business Data Director Workflow and Tasks Configuration Guide on SHARE.

Charts The Configuration tool does not provide any support for charts. For more information, refer to the Siperian Hub Business Data Director Charts Configuration on SHARE.

User Interface Extensions The BDD Configuration tool does not provide support for UI extensions. By default, the uiExtensions element is not specified in the configuration XML file. Refer to the sample BDDConfig.xml file in the Siperian Hub Resource Kit for examples on configuring the custom top-level tabs and the dashboard extensions.


Online Help BDD supports both generic and custom help. The generic help describes the standard functionality of a BDD application. However, it does not provide any information about the Subject Areas or other configuration for any specific implementation of a BDD application. Custom help can be added to the application to provide this information.

By default a BDD application has a link only for the generic help. The following element can be modified to change this (change customBddHelp to “true” to enable custom help): <help bddHelp="true" customBddHelp="false"/>

Generic Help When a BDD application is created, the generic help (BDDHelp.zip) is added to it. Implementer can modify this file if desired. The contents of this file can also be localized to provide multi-language support. Each localized version of the file must be named BDDHelp_XX.zip, where XX is a two-character ISO language code.

This ZIP file must contain a file “bdd_help/bdd_help.htm” to provide the entry point to the help system.

Help files can be added to the application either by including them in the application ZIP file that is imported, or by importing the help ZIP file into an existing application.

Custom Help Custom help can be added to a BDD application that provides users with information specific to that implementation – details about the Subject Areas and other information about the application usage.

Custom help is also added as a ZIP file named CustomBDDHelp.zip or CustomBDDHelp_XX.zip for localized help, where XX is a two-character ISO language code.

This ZIP file must contain a file “bdd_help/bdd_help.htm” to provide the entry point to the help system.

Help files can be added to the application either by including them in the application ZIP file that is imported, or by importing the help ZIP file into an existing application.

Localization As described in “Application Components” later in this document, four sets of resource bundles contain the strings that are displayed in a BDD application. Each set includes the default file, a placeholder English language file (this file can be empty), and localized versions of the file (there do not need to be any). For example, for the MessageBundle set, there the default file MessageBundle.properties and the placeholder English language file MessageBundle_en.properties.

Each resource bundle file is a UTF-8 encoded properties files. Each entry in the file is a name/value pair like <name>=<value>. A few examples:


title=Business Data Director locale=Locale search=Search

‘Name’ is a fixed value that is referenced by the BDD application. <Value> is the part that can be localized.

Message bundle files can be added to the application either by including them in the application ZIP file that is imported, or by importing them into an existing application.

Sizing and Platform Requirements

DB Server Sizing BDD deployments do not have direct impact on the DB server sizing. BDD transaction requirements should be considered in defining the API section of the sizing model.

Application Server Sizing BDD runs on the application server co-located with the other Siperian Hub Server components. The application servers should be sized to allow 1 CPU core / 1 GB of memory for every 10 concurrent BDD “heavy user” sessions. The “heavy user” for the purpose of the sizing model is defined as a user producing a constant load of 5-6 BDD operations per minute.

Client and Network Sizing BDD requires Internet Explorer 7 or Firefox 3 on the client. Here is the minimum and the recommended configuration for the client machines accessing BDD.

Parameter Value

CPU Minimum: 1.6 GHz Recommended: 2 GHz

Memory Minimum: 1 GB Recommended: 2GB

Effective network bandwidth to the MRM Application Server

Minimum: 10 MBit Recommended: 100 MBit


Application Components A BDD application is stored in the database (C_REPOS_DS_CONFIG) as a ZIP file containing component files. This ZIP file results when an application is exported in the BDD Configuration tool. This ZIP file can also be imported into the BDD Configuration tool.

File name Usage

BDDConfig.xml Main configuration file for the application. It must conform to the siperian-bdd-config.xsd XML schema.

BDDBundle.properties BDDBundle_XX.properties

Resource bundles with the labels for objects defined in the BDD application (Subject Areas, and so on).

MetadataBundle.properties MetadataBundle_XX.properties

Resource bundles with the labels for objects define in the ORS (base objects, columns, and so on).

ErrorCodeBundle.properties ErrorCodeBundle_XX.properties

Resource bundles with the text for error messages generated by a BDD application.

MessageBundle.properties MessageBundle_XX.properties

Resource bundles with text displayed in the BDD application.

BDDHelp.zip BDDHelp_XX.zip

Generic BDD help files. Help that generically describes the features of a BDD application.

CustomBDDHelp.zip CustomBDDHelp_XX.zip

Custom BDD help files. Help that can be created so that it is specific and unique to a particular BDD application. In addition to providing implementation-specific usage instructions, this help file can provide any other information, including an organization’s procedures and policies.

Appendix A: BDD Security Configuration

BDD Security Configuration

q Use-case

Resource Group Name Sub-name

Special Requirements/ Comments C

R

U D

E M

General

CUSTOM_RESOURCE BDD_NAME SUBJECT_AREA Y

BASE_OBJECT NAME Primary BO and all Logical one-to-ones Y Y

Toolbar New Subject Area

CLEANSE_FUNCTION LIB_NAME FUNCTION_NAME Y

Search C R U D E M

CUSTOM_RESOURCE BDD_NAME SEARCH_QUERY/Create Y

Create Saved Query


Open (View) Saved Query CUSTOM_RESOURCE

BDD_NAME SUBJECT_AREA Y

Data View C R U D E M



Create Subject Area


Read Subject CUSTOM_RESOURCE BDD_NAME SUBJECT_AREA Y



q Use-case



R

U D

E M

Area

BASE_OBJECT NAME Primary BO and all Logical one-to-ones Y

CUSTOM_RESOURCE BDD_NAME SUBJECT_AREA Y Y


Update Subject Area



Delete Subject Area

BASE_OBJECT NAME

Primary BO, State management is enabled

Y



Copy Subject Area



Show BO's System columns BASE_OBJECT NAME BO is not new. Y

BASE_OBJECT NAME

For one-to-many children just BO itself, for many-to-many children both BO and its relation BO is checked.

Y Y

Create Child Object


Read Child BASE_OBJECT NAME Y



q Use-case



R

U D

E M

Object

BASE_OBJECT NAME

For one-to-many children just BO itself, for many-to-many children both BO and its relation BO is checked.

Y

Update Child Object


Delete Child Object

BASE_OBJECT NAME

State management enabled. For one-to-many children just BO itself, for many-to-many children both BO and its relation BO is checked.

Y

CM C R U D E M


BASE_OBJECT NAME BO is not new. Y

View Xref

BASE_OBJECT NAME XREF

Primary BO and all Logical one-to-ones. For one-to-many children just child BO. For many-to-many children child BO and relation BO.

Y

Find duplicates CUSTOM_RESOURCE BDD_NAME SUBJECT_AREA Y



q Use-case



R

U D

E M

BASE_OBJECT NAME Y


Merge

BASE_OBJECT NAME Y


Unmerge

BASE_OBJECT NAME Y

View Raw Data BASE_OBJECT NAME RAW Y

Tasks C R U D E M


BASE_OBJECT NAME

Primary BO and all Logical one-to-ones, State management is enabled

Y Y

BASE_OBJECT NAME

Many-to-many children, State management is enabled

Y Y

CLEANSE_FUNCTION LIB_NAME FUNCTION_NAME Primary Object and all logical one-to-ones Y

Send for approval (New Primary Object)

CUSTOM_RESOURCE BDD_NAME TASK_TYPE:SA Deafult for approval Y


Send for approval (Existing Primary Object)

BASE_OBJECT NAME


Y Y



q Use-case



R

U D

E M

BASE_OBJECT NAME


Y Y


CUSTOM_RESOURCE BDD_NAME TASK_TYPE:SA Deafult for approval Y


BASE_OBJECT NAME Y

Open task from dashboard

CUSTOM_RESOURCE BDD_NAME TASK_TYPE:SA Y


BASE_OBJECT NAME


Y

BASE_OBJECT NAME



Create Task

CUSTOM_RESOURCE BDD_NAME TASK_TYPE:SA Any creational task type Y


View Task Details CUSTOM_RESOURCE BDD_NAME TASK_TYPE:SA Y



q Use-case



R

U D

E M


Merge Task

CUSTOM_RESOURCE BDD_NAME TASK_TYPE:SA/Merge Y


Unmerge Task

CUSTOM_RESOURCE BDD_NAME TASK_TYPE:SA/Unmerge Y


Execute Task's action CUSTOM_RESOURCE BDD_NAME TASK_TYPE:SA Y

History View C R U D E M

View Subject Area History CUSTOM_RESOURCE BDD_NAME SUBJECT_AREA

Primary BO is persisted, history is enabled for primary BO.

Y


BASE_OBJECT NAME HISTORY Primary BO and all Logical one-to-ones. Y

History View for Primary Object

BASE_OBJECT NAME History should be enabled for BO. Y


History View for Child BO

BASE_OBJECT NAME HISTORY

For many-to-many children relationship privileges are taked in account.

Y



q Use-case



R

U D

E M



BASE_OBJECT NAME XREF_HISTORY Y

View BO Xref History



View BO Merge History BASE_OBJECT NAME Y

Charts C R U D E M

View Chart CUSTOM_RESOURCE BDD_NAME CHART/View Y

Appendix B: Locale Codes

Language Codes Language Codes

ISO Code Language

Aa Afar

Ab Abkhazian

af Afrikaans

am Amharic

ar Arabic

as Assamese

ay Aymara

az Azerbaijani

ba Bashkir

be Byelorussian

bg Bulgarian

bh Bihari

bi Bislama

bn Bengali, Bangla

bo Tibetan

br Breton

ca Catalan

co Corsican

cs Czech

cy Welsh

da Danish

de German

dz Bhutani

el Greek

en English

eo Esperanto

es Spanish

Language Codes

ISO Code Language

et Estonian

eu Basque

fa Persian

fi Finnish

fj Fiji

fo Faroese

fr French

fy Frisian

ga Irish

gd Scots Gaelic

gl Galician

gn Guarani

gu Gujarati

ha Hausa

he Hebrew (formerly iw)

hi Hindi

hr Croatian

hu Hungarian

hy Armenian

ia Interlingua

id Indonesian (formerly in)

ie Interlingue

ik Inupiak

is Icelandic

it Italian

iu Inuktitut

ja Japanese

jw Javanese

ka Georgian


Language Codes

ISO Code Language

kk Kazakh

kl Greenlandic

km Cambodian

kn Kannada

ko Korean

ks Kashmiri

ku Kurdish

ky Kirghiz

la Latin

ln Lingala

lo Laothian

lt Lithuanian

lv Latvian, Lettish

mg Malagasy

mi Maori

mk Macedonian

ml Malayalam

mn Mongolian

mo Moldavian

mr Marathi

ms Malay

mt Maltese

my Burmese

na Nauru

ne Nepali

nl Dutch

no Norwegian

oc Occitan

om (Afan) Oromo

or Oriya

pa Punjabi

Language Codes

ISO Code Language

pl Polish

ps Pashto, Pushto

pt Portuguese

qu Quechua

rm Rhaeto-Romance

rn Kirundi

ro Romanian

ru Russian

rw Kinyarwanda

sa Sanskrit

sd Sindhi

sg Sangho

sh Serbo-Croatian

si Sinhalese

sk Slovak

sl Slovenian

sm Samoan

sn Shona

so Somali

sq Albanian

sr Serbian

ss Siswati

st Sesotho

su Sundanese

sv Swedish

sw Swahili

ta Tamil

te Telugu

tg Tajik

th Thai

ti Tigrinya


Language Codes

ISO Code Language

tk Turkmen

tl Tagalog

tn Setswana

to Tonga

tr Turkish

ts Tsonga

tt Tatar

tw Twi

ug Uighur

uk Ukrainian

ur Urdu

uz Uzbek

vi Vietnamese

vo Volapuk

wo Wolof

xh Xhosa

yi Yiddish (formerly ji)

yo Yoruba

za Zhuang

zh Chinese

zu Zulu

Country Codes Country Codes

Country Two-letter Code

ISO #

AALAND ISLANDS AX 248

AFGHANISTAN AF 4

ALBANIA AL 8

ALGERIA DZ 12

AMERICAN SAMOA AS 16

ANDORRA AD 20

ANGOLA AO 24

ANGUILLA AI 660

ANTARCTICA AQ 10

ANTIGUA AND BARBUDA

AG 28

ARGENTINA AR 32

ARMENIA AM 51

ARUBA AW 533

AUSTRALIA AU 36

AUSTRIA AT 40

AZERBAIJAN AZ 31

BAHAMAS BS 44

BAHRAIN BH 48

BANGLADESH BD 50

BARBADOS BB 52

BELARUS BY 112

BELGIUM BE 56

BELIZE BZ 84

BENIN BJ 204

BERMUDA BM 60

BHUTAN BT 64

BOLIVIA BO 68

BOSNIA AND BA 70


Country Codes


ISO #

HERZEGOWINA

BOTSWANA BW 72

BOUVET ISLAND BV 74

BRAZIL BR 76

BRITISH INDIAN OCEAN TERRITORY

IO 86

BRUNEI DARUSSALAM

BN 96

BULGARIA BG 100

BURKINA FASO BF 854

BURUNDI BI 108

CAMBODIA KH 116

CAMEROON CM 120

CANADA CA 124

CAPE VERDE CV 132

CAYMAN ISLANDS KY 136

CENTRAL AFRICAN REPUBLIC

CF 140

CHAD TD 148

CHILE CL 152

CHINA CN 156

CHRISTMAS ISLAND CX 162

COCOS (KEELING) ISLANDS

CC 166

COLOMBIA CO 170

COMOROS KM 174

CONGO, Democratic Republic of (was Zaire)

CD 180

CONGO, Republic of CG 178

COOK ISLANDS CK 184

COSTA RICA CR 188

Country Codes


ISO #

COTE D'IVOIRE CI 384

CROATIA (local name: Hrvatska)

HR 191

CUBA CU 192

CYPRUS CY 196

CZECH REPUBLIC CZ 203

DENMARK DK 208

DJIBOUTI DJ 262

DOMINICA DM 212

DOMINICAN REPUBLIC

DO 214

ECUADOR EC 218

EGYPT EG 818

EL SALVADOR SV 222

EQUATORIAL GUINEA

GQ 226

ERITREA ER 232

ESTONIA EE 233

ETHIOPIA ET 231

FALKLAND ISLANDS (MALVINAS)

FK 238

FAROE ISLANDS FO 234

FIJI FJ 242

FINLAND FI 246

FRANCE FR 250

FRENCH GUIANA GF 254

FRENCH POLYNESIA

PF 258

FRENCH SOUTHERN TERRITORIES

TF 260

GABON GA 266


Country Codes


ISO #

GAMBIA GM 270

GEORGIA GE 268

GERMANY DE 276

GHANA GH 288

GIBRALTAR GI 292

GREECE GR 300

GREENLAND GL 304

GRENADA GD 308

GUADELOUPE GP 312

GUAM GU 316

GUATEMALA GT 320

GUINEA GN 324

GUINEA-BISSAU GW 624

GUYANA GY 328

HAITI HT 332

HEARD AND MC DONALD ISLANDS

HM 334

HONDURAS HN 340

HONG KONG HK 344

HUNGARY HU 348

ICELAND IS 352

INDIA IN 356

INDONESIA ID 360

IRAN (ISLAMIC REPUBLIC OF)

IR 364

IRAQ IQ 368

IRELAND IE 372

ISRAEL IL 376

ITALY IT 380

JAMAICA JM 388

JAPAN JP 392

Country Codes


ISO #

JORDAN JO 400

KAZAKHSTAN KZ 398

KENYA KE 404

KIRIBATI KI 296

KOREA, DEMOCRATIC PEOPLE'S REPUBLIC OF

KP 408

KOREA, REPUBLIC OF

KR 410

KUWAIT KW 414

KYRGYZSTAN KG 417

LAO PEOPLE'S DEMOCRATIC REPUBLIC

LA 418

LATVIA LV 428

LEBANON LB 422

LESOTHO LS 426

LIBERIA LR 430

LIBYAN ARAB JAMAHIRIYA

LY 434

LIECHTENSTEIN LI 438

LITHUANIA LT 440

LUXEMBOURG LU 442

MACAU MO 446

MACEDONIA, THE FORMER YUGOSLAV REPUBLIC OF

MK 807

MADAGASCAR MG 450

MALAWI MW 454

MALAYSIA MY 458

MALDIVES MV 462


Country Codes


ISO #

MALI ML 466

MALTA MT 470

MARSHALL ISLANDS

MH 584

MARTINIQUE MQ 474

MAURITANIA MR 478

MAURITIUS MU 480

MAYOTTE YT 175

MEXICO MX 484

MICRONESIA, FEDERATED STATES OF

FM 583

MOLDOVA, REPUBLIC OF

MD 498

MONACO MC 492

MONGOLIA MN 496

MONTSERRAT MS 500

MOROCCO MA 504

MOZAMBIQUE MZ 508

MYANMAR MM 104

NAMIBIA NA 516

NAURU NR 520

NEPAL NP 524

NETHERLANDS NL 528

NETHERLANDS ANTILLES

AN 530

NEW CALEDONIA NC 540

NEW ZEALAND NZ 554

NICARAGUA NI 558

NIGER NE 562

NIGERIA NG 566

NIUE NU 570

Country Codes


ISO #

NORFOLK ISLAND NF 574

NORTHERN MARIANA ISLANDS

MP 580

NORWAY NO 578

OMAN OM 512

PAKISTAN PK 586

PALAU PW 585

PALESTINIAN TERRITORY, Occupied

PS 275

PANAMA PA 591

PAPUA NEW GUINEA

PG 598

PARAGUAY PY 600

PERU PE 604

PHILIPPINES PH 608

PITCAIRN PN 612

POLAND PL 616

PORTUGAL PT 620

PUERTO RICO PR 630

QATAR QA 634

REUNION RE 638

ROMANIA RO 642

RUSSIAN FEDERATION

RU 643

RWANDA RW 646

SAINT HELENA SH 654

SAINT KITTS AND NEVIS

KN 659

SAINT LUCIA LC 662

SAINT PIERRE AND MIQUELON

PM 666


Country Codes


ISO #

SAINT VINCENT AND THE GRENADINES

VC 670

SAMOA WS 882

SAN MARINO SM 674

SAO TOME AND PRINCIPE

ST 678

SAUDI ARABIA SA 682

SENEGAL SN 686

SERBIA AND MONTENEGRO

CS 891

SEYCHELLES SC 690

SIERRA LEONE SL 694

SINGAPORE SG 702

SLOVAKIA SK 703

SLOVENIA SI 705

SOLOMON ISLANDS SB 90

SOMALIA SO 706

SOUTH AFRICA ZA 710

SOUTH GEORGIA AND THE SOUTH SANDWICH ISLANDS

GS 239

SPAIN ES 724

SRI LANKA LK 144

SUDAN SD 736

SURINAME SR 740

SVALBARD AND JAN MAYEN ISLANDS

SJ 744

SWAZILAND SZ 748

SWEDEN SE 752

SWITZERLAND CH 756

SYRIAN ARAB SY 760

Country Codes


ISO #

REPUBLIC

TAIWAN TW 158

TAJIKISTAN TJ 762

TANZANIA, UNITED REPUBLIC OF

TZ 834

THAILAND TH 764

TIMOR-LESTE TL 626

TOGO TG 768

TOKELAU TK 772

TONGA TO 776

TRINIDAD AND TOBAGO

TT 780

TUNISIA TN 788

TURKEY TR 792

TURKMENISTAN TM 795

TURKS AND CAICOS ISLANDS

TC 796

TUVALU TV 798

UGANDA UG 800

UKRAINE UA 804

UNITED ARAB EMIRATES

AE 784

UNITED KINGDOM GB 826

UNITED STATES US 840

UNITED STATES MINOR OUTLYING ISLANDS

UM 581

URUGUAY UY 858

UZBEKISTAN UZ 860

VANUATU VU 548

VATICAN CITY STATE (HOLY SEE)

VA 336

VENEZUELA VE 862


Country Codes


ISO #

VIET NAM VN 704

VIRGIN ISLANDS (BRITISH)

VG 92

VIRGIN ISLANDS (U.S.)

VI 850

WALLIS AND FUTUNA ISLANDS

WF 876

WESTERN SAHARA EH 732

YEMEN YE 887

ZAMBIA ZM 894

ZIMBABWE ZW 716

business data director - implementation guide

Documents