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 subtype, 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.
Heres 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|MIDDLE_NAME"
parameterName="middleName"/>
<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"
<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"
<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|MIDDLE_NAME" parameterName="middleName"/>
</cleanseInput>
<cleanseOutput>
<cleanseColumn columnUid="C_PARTY|MIDDLE_NAME" parameterName="middleName"/>
<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 users 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|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|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 organizations
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_NA
ME SUBJECT_AREA
Y
BASE_OBJECT NAME
Primary BO and all
Logical one-to-ones
Y Y

Toolbar New
Subject Area
CLEANSE_FUNCTION
LIB_NAM
E FUNCTION_NAME
Y
Search C R U D E M
CUSTOM_RESOURCE
BDD_NA
ME SEARCH_QUERY/Create
Y

Create Saved
Query
CUSTOM_RESOURCE
BDD_NA
ME SUBJECT_AREA
Y

Open (View)
Saved Query CUSTOM_RESOURCE
BDD_NA
ME SUBJECT_AREA
Y
Data View C R U D E M
CUSTOM_RESOURCE BDD_NAME SUBJECT_AREA Y
BASE_OBJECT NAME
Primary BO and all
Logical one-to-ones
Y Y

Create Subject
Area
CLEANSE_FUNCTION LIB_NAME FUNCTION_NAME Y

Read Subject
q
Use-case
Special
Requirements/
Comments C
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
BASE_OBJECT NAME
Primary BO and all
Logical one-to-ones
Y Y

Update Subject
Area

Delete Subject
Area
BASE_OBJECT NAME
Primary BO, State
management is
enabled
Y
BASE_OBJECT NAME
Primary BO and all
Logical one-to-ones
Y 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
Special
Requirements/
Comments C
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
Special
Requirements/
Comments C
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
Primary BO and all
State management is
enabled
Y Y
q
Use-case
Special
Requirements/
Comments C
R

U
D
E
M
BASE_OBJECT NAME
Many-to-many
children, State
management is
enabled
Y Y
logical one-to-ones
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
Primary BO and all
State management is
enabled
Y
BASE_OBJECT NAME
Many-to-many
children, State
management is
enabled

logical one-to-ones
Y

Create Task
CUSTOM_RESOURCE BDD_NAME TASK_TYPE:SA
Any creational task
type
Y

View Task
Details
q
Use-case
Special
Requirements/
Comments C
R

U
D
E
M

Merge Task
CUSTOM_RESOURCE BDD_NAME
TASK_TYPE:SA/Mer
ge
Y

Unmerge Task
CUSTOM_RESOURCE BDD_NAME
TASK_TYPE:SA/Un
merge
Y

Execute Task's
action
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
Special
Requirements/
Comments C
R

U
D
E
M

BASE_OBJECT NAME
History should be
enabled for BO.
Y
BASE_OBJECT NAME XREF_HISTORY Y

View BO Xref
History
BASE_OBJECT NAME

History should be
enabled for BO.
Y

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
Country Two-
letter
Code
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
Country Two-
letter
Code
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
Country Two-
letter
Code
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
Country Two-
letter
Code
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
Country Two-
letter
Code
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
Country Two-
letter
Code
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
Country Two-
letter
Code
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
Country Two-
letter
Code
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
Country Two-
letter
Code
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

Uploaded by

Document Information

Original Title

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

Business Data Director Implementation Guide

Uploaded by

Copyright:

Available Formats

Siperian Hub

Business Data Director

Appendix A: BDD Security Configuration

You might also like