Business Data Director - Implementation Guide

Siperian Hub
Business Data Director™

Implementation Guide
© 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.
Siperian Hub Business Data Director Implementation Guide 2

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
3 Siperian Hub Business Data Director Implementation Guide

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 The expectation is that there should be only one child record for each
One:One 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 Cleanse is invoked when Save is selected. Save continues only if cleanse
(main form on succeeds and there are no validation errors.
the screen)
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 The most important property defined at the application level is
System 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 Description
Mechanism
Code Lookup Code lookup tables need to have the Lookup Indicator set to
tables TRUE.
Entity Lookups Entity Lookups in BDD can only be done to entities that are
in BDD 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 Create a new BDD application by importing the BDD
configuration only configuration XML. This can be used to replace an existing
(XML) 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 Create a new BDD application by importing a Zip file
application (Zip) containing the various component files (XML, resource
bundles, help files, and so on).
Import to existing BDD Update an existing BDD application by importing a single file.
application 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 Description

Level
-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 Description
Level
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 BDD application is deployed, but only users that are
deployment 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 All applications with active_ind that is not -1 are first validated. If the validation
Server level is not Fatal Error, then the application is deployed. At this time, only a
Startup partial validation is run to check for fatal errors.
Import / Any time an application is imported or saved, it is also deployed unless its
Save 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 This identifies the logical ORS group to which the child Subject Areas belong,
Area Group 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 Specifies whether this Subject Area represents an HM entity type. If not, but it
Area 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 For each child, you must specify the following information: the type of
Area Child 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 Javadoc-style documentation. Provides the same information
the XML schema 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 To be used with the sample schema.
configuration

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|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

C_PARTY
Validation and cleanse are
optional elements for a
primaryObject, one2ManyChild,
and many2ManyChild. The FIRST_NAME
Configuration tool does not MIDDLE_NAME
LAST_NAME
create the cleanseFunction
DISPLAY_NAME
element.
The cleanseFunction is very
similar to the mapping definition
Name Standardize
in the Hub. In this case,
Inputs Outputs
however, the base object record
firstName firstName
provides both the inputs and the
middleName middleName
outputs for the cleanse function.
lastName lastName
A cleanse function is called displayName
when: validationStatus
• Primary data – the Save

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 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|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 Minimum: 10 MBit
Application Server 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 Resource bundles with the labels for objects defined in
BDDBundle_XX.properties the BDD application (Subject Areas, and so on).
MetadataBundle.properties Resource bundles with the labels for objects define in
MetadataBundle_XX.properties the ORS (base objects, columns, and so on).
ErrorCodeBundle.properties Resource bundles with the text for error messages
ErrorCodeBundle_XX.properties generated by a BDD application.
MessageBundle.properties Resource bundles with text displayed in the BDD
MessageBundle_XX.properties application.
BDDHelp.zip Generic BDD help files. Help that generically describes
BDDHelp_XX.zip the features of a BDD application.
CustomBDDHelp.zip Custom BDD help files. Help that can be created so
CustomBDDHelp_XX.zip 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

Special
Use-case Requirements/ R U E
q Resource Group Name Sub-name Comments C D M
General
BDD_NA
Y
CUSTOM_RESOURCE ME SUBJECT_AREA
Toolbar New Primary BO and all
Y Y
Subject Area BASE_OBJECT NAME Logical one-to-ones
LIB_NAM
Y
CLEANSE_FUNCTION E FUNCTION_NAME
Search C R U D E M
BDD_NA
Y
Create Saved CUSTOM_RESOURCE ME SEARCH_QUERY/Create
Query BDD_NA
Y
CUSTOM_RESOURCE ME SUBJECT_AREA
Open (View) BDD_NA
Y
Saved Query CUSTOM_RESOURCE ME SUBJECT_AREA
Data View C R U D E M
CUSTOM_RESOURCE BDD_NAME SUBJECT_AREA Y
Create Subject Primary BO and all
Y Y
Area BASE_OBJECT NAME Logical one-to-ones
CLEANSE_FUNCTION LIB_NAME FUNCTION_NAME Y
Read Subject CUSTOM_RESOURCE BDD_NAME SUBJECT_AREA Y
Special
Area Primary BO and all
Y
BASE_OBJECT NAME Logical one-to-ones
CUSTOM_RESOURCE BDD_NAME SUBJECT_AREA Y Y
Update Subject Primary BO and all
Y Y
Delete Subject Primary BO, State
Area management is Y
BASE_OBJECT NAME enabled
Copy Subject Primary BO and all
Y Y
Show BO's CUSTOM_RESOURCE BDD_NAME SUBJECT_AREA Y

System columns BASE_OBJECT NAME BO is not new. Y
For one-to-many
children just BO itself,
for many-to-many
Create Child Y Y
children both BO and
Object its relation BO is
BASE_OBJECT NAME checked.
Read Child BASE_OBJECT NAME Y

Special
Object
For one-to-many
children just BO itself,
for many-to-many
Update Child Y
children both BO and
Object its relation BO is
BASE_OBJECT NAME checked.
State management
enabled. For one-to-
many children just BO
Delete Child
itself, for many-to- Y
Object
many children both
BO and its relation BO
BASE_OBJECT NAME is checked.
CM C R U D E M
BASE_OBJECT NAME BO is not new. Y
Primary BO and all
Logical one-to-ones.
View Xref
For one-to-many
children just child BO. Y
For many-to-many
children child BO and
BASE_OBJECT NAME XREF relation BO.
Find duplicates CUSTOM_RESOURCE BDD_NAME SUBJECT_AREA Y

Special
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
Primary BO and all
Logical one-to-ones,
Y Y
State management is
Send for
Many-to-many
approval (New
children, State
Primary Object) Y Y
management is
Primary Object and all
Y
CLEANSE_FUNCTION LIB_NAME FUNCTION_NAME logical one-to-ones
CUSTOM_RESOURCE BDD_NAME TASK_TYPE:SA Deafult for approval Y
Send for CUSTOM_RESOURCE BDD_NAME SUBJECT_AREA Y
approval
Primary BO and all
(Existing Primary
Object) Y Y
State management is

Special
Many-to-many
children, State
Y Y
management is
Y
CUSTOM_RESOURCE BDD_NAME TASK_TYPE:SA Deafult for approval Y
Open task from
BASE_OBJECT NAME Y
dashboard
CUSTOM_RESOURCE BDD_NAME TASK_TYPE:SA Y
Primary BO and all
Y
State management is
Many-to-many
Create Task children, State

management is
Y
Any creational task
Y
CUSTOM_RESOURCE BDD_NAME TASK_TYPE:SA type
View Task CUSTOM_RESOURCE BDD_NAME SUBJECT_AREA Y

Details CUSTOM_RESOURCE BDD_NAME TASK_TYPE:SA Y

Special
Merge Task TASK_TYPE:SA/Mer
Y
CUSTOM_RESOURCE BDD_NAME ge
Unmerge Task TASK_TYPE:SA/Un
Y
CUSTOM_RESOURCE BDD_NAME merge
Execute Task's CUSTOM_RESOURCE BDD_NAME SUBJECT_AREA Y

action CUSTOM_RESOURCE BDD_NAME TASK_TYPE:SA Y
History
C R U D E M
View
Primary BO is
View Subject persisted, history is
Area History enabled for primary
BO.
Primary BO and all
History View for BASE_OBJECT NAME HISTORY Y
Logical one-to-ones.
Primary Object
History should be
BASE_OBJECT NAME Y
enabled for BO.
History View for CUSTOM_RESOURCE BDD_NAME SUBJECT_AREA Y
Child BO
For many-to-many
children relationship
BASE_OBJECT NAME HISTORY Y
privileges are taked in
account.

Special
History should be
BASE_OBJECT NAME Y
enabled for BO.
View BO Xref BASE_OBJECT NAME XREF_HISTORY Y
History
History should be
BASE_OBJECT NAME Y
enabled for BO.
View BO Merge CUSTOM_RESOURCE BDD_NAME SUBJECT_AREA Y

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
ISO Code Language
Language Codes et Estonian
Language Codes eu Basque
ISO Code Language fa Persian
Aa Afar fi Finnish
Ab Abkhazian fj Fiji
af Afrikaans fo Faroese
am Amharic fr French
ar Arabic fy Frisian
as Assamese ga Irish
ay Aymara gd Scots Gaelic
az Azerbaijani gl Galician
ba Bashkir gn Guarani
be Byelorussian gu Gujarati
bg Bulgarian ha Hausa
bh Bihari he Hebrew (formerly iw)
bi Bislama hi Hindi
bn Bengali, Bangla hr Croatian
bo Tibetan hu Hungarian
br Breton hy Armenian
ca Catalan ia Interlingua
co Corsican id Indonesian (formerly in)
cs Czech ie Interlingue
cy Welsh ik Inupiak
da Danish is Icelandic
de German it Italian
dz Bhutani iu Inuktitut
el Greek ja Japanese
en English jw Javanese
eo Esperanto ka Georgian
es Spanish
Language Codes Language Codes
ISO Code Language ISO Code Language
kk Kazakh pl Polish
kl Greenlandic ps Pashto, Pushto
km Cambodian pt Portuguese
kn Kannada qu Quechua
ko Korean rm Rhaeto-Romance
ks Kashmiri rn Kirundi
ku Kurdish ro Romanian
ky Kirghiz ru Russian
la Latin rw Kinyarwanda
ln Lingala sa Sanskrit
lo Laothian sd Sindhi
lt Lithuanian sg Sangho
lv Latvian, Lettish sh Serbo-Croatian
mg Malagasy si Sinhalese
mi Maori sk Slovak
mk Macedonian sl Slovenian
ml Malayalam sm Samoan
mn Mongolian sn Shona
mo Moldavian so Somali
mr Marathi sq Albanian
ms Malay sr Serbian
mt Maltese ss Siswati
my Burmese st Sesotho
na Nauru su Sundanese
ne Nepali sv Swedish
nl Dutch sw Swahili
no Norwegian ta Tamil
oc Occitan te Telugu
om (Afan) Oromo tg Tajik
or Oriya th Thai
pa Punjabi ti Tigrinya

Language Codes
ISO Code Language
Country Codes
tk Turkmen Country Codes
tl Tagalog Country Two- ISO #

letter
tn Setswana Code
to Tonga AALAND ISLANDS AX 248
tr Turkish AFGHANISTAN AF 4
ts Tsonga ALBANIA AL 8
tt Tatar ALGERIA DZ 12
tw Twi AMERICAN SAMOA AS 16
ug Uighur ANDORRA AD 20
uk Ukrainian ANGOLA AO 24
ur Urdu ANGUILLA AI 660
uz Uzbek ANTARCTICA AQ 10
vi Vietnamese ANTIGUA AND AG 28
vo Volapuk BARBUDA
wo Wolof ARGENTINA AR 32
xh Xhosa ARMENIA AM 51
yi Yiddish (formerly ji) ARUBA AW 533
yo Yoruba AUSTRALIA AU 36
za Zhuang AUSTRIA AT 40
zh Chinese AZERBAIJAN AZ 31
zu Zulu 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 Codes
Country Two- ISO # Country Two- ISO #
letter letter
Code Code
HERZEGOWINA COTE D'IVOIRE CI 384
BOTSWANA BW 72 CROATIA (local HR 191
BOUVET ISLAND BV 74 name: Hrvatska)
BRAZIL BR 76 CUBA CU 192
BRITISH INDIAN IO 86 CYPRUS CY 196

OCEAN TERRITORY CZECH REPUBLIC CZ 203
BRUNEI BN 96 DENMARK DK 208
DARUSSALAM
DJIBOUTI DJ 262
BULGARIA BG 100
DOMINICA DM 212
BURKINA FASO BF 854
DOMINICAN DO 214
BURUNDI BI 108 REPUBLIC
CAMBODIA KH 116 ECUADOR EC 218
CAMEROON CM 120 EGYPT EG 818
CANADA CA 124 EL SALVADOR SV 222
CAPE VERDE CV 132 EQUATORIAL GQ 226
CAYMAN ISLANDS KY 136 GUINEA
CENTRAL AFRICAN CF 140 ERITREA ER 232

REPUBLIC ESTONIA EE 233
CHAD TD 148 ETHIOPIA ET 231
CHILE CL 152 FALKLAND ISLANDS FK 238
CHINA CN 156 (MALVINAS)
CHRISTMAS ISLAND CX 162 FAROE ISLANDS FO 234
COCOS (KEELING) CC 166 FIJI FJ 242

ISLANDS FINLAND FI 246
COLOMBIA CO 170 FRANCE FR 250
COMOROS KM 174 FRENCH GUIANA GF 254
CONGO, Democratic CD 180 FRENCH PF 258
Republic of (was POLYNESIA
Zaire)
FRENCH TF 260
CONGO, Republic of CG 178 SOUTHERN
COOK ISLANDS CK 184 TERRITORIES
COSTA RICA CR 188 GABON GA 266

letter letter
Code Code
GAMBIA GM 270 JORDAN JO 400
GEORGIA GE 268 KAZAKHSTAN KZ 398
GERMANY DE 276 KENYA KE 404
GHANA GH 288 KIRIBATI KI 296
GIBRALTAR GI 292 KOREA, KP 408
DEMOCRATIC
GREECE GR 300
PEOPLE'S
GREENLAND GL 304 REPUBLIC OF
GRENADA GD 308 KOREA, REPUBLIC KR 410
OF
GUADELOUPE GP 312
KUWAIT KW 414
GUAM GU 316
KYRGYZSTAN KG 417
GUATEMALA GT 320
LAO PEOPLE'S LA 418
GUINEA GN 324
DEMOCRATIC
GUINEA-BISSAU GW 624 REPUBLIC
GUYANA GY 328 LATVIA LV 428
HAITI HT 332 LEBANON LB 422
HEARD AND MC HM 334 LESOTHO LS 426
DONALD ISLANDS
LIBERIA LR 430
HONDURAS HN 340
LIBYAN ARAB LY 434
HONG KONG HK 344 JAMAHIRIYA
HUNGARY HU 348 LIECHTENSTEIN LI 438
ICELAND IS 352 LITHUANIA LT 440
INDIA IN 356 LUXEMBOURG LU 442
INDONESIA ID 360 MACAU MO 446
IRAN (ISLAMIC IR 364 MACEDONIA, THE MK 807
REPUBLIC OF) FORMER
YUGOSLAV
IRAQ IQ 368 REPUBLIC OF
IRELAND IE 372 MADAGASCAR MG 450
ISRAEL IL 376 MALAWI MW 454
ITALY IT 380 MALAYSIA MY 458
JAMAICA JM 388 MALDIVES MV 462
JAPAN JP 392

letter letter
Code Code
MALI ML 466 NORFOLK ISLAND NF 574
MALTA MT 470 NORTHERN MP 580
MARIANA ISLANDS
MARSHALL MH 584
ISLANDS NORWAY NO 578
MARTINIQUE MQ 474 OMAN OM 512
MAURITANIA MR 478 PAKISTAN PK 586
MAURITIUS MU 480 PALAU PW 585
MAYOTTE YT 175 PALESTINIAN PS 275
TERRITORY,
MEXICO MX 484
Occupied
MICRONESIA, FM 583
PANAMA PA 591
FEDERATED
STATES OF PAPUA NEW PG 598
GUINEA
MOLDOVA, MD 498
REPUBLIC OF PARAGUAY PY 600
MONACO MC 492 PERU PE 604
MONGOLIA MN 496 PHILIPPINES PH 608
MONTSERRAT MS 500 PITCAIRN PN 612
MOROCCO MA 504 POLAND PL 616
MOZAMBIQUE MZ 508 PORTUGAL PT 620
MYANMAR MM 104 PUERTO RICO PR 630
NAMIBIA NA 516 QATAR QA 634
NAURU NR 520 REUNION RE 638
NEPAL NP 524 ROMANIA RO 642
NETHERLANDS NL 528 RUSSIAN RU 643
FEDERATION
NETHERLANDS AN 530
ANTILLES RWANDA RW 646
NEW CALEDONIA NC 540 SAINT HELENA SH 654
NEW ZEALAND NZ 554 SAINT KITTS AND KN 659
NEVIS
NICARAGUA NI 558
SAINT LUCIA LC 662
NIGER NE 562
SAINT PIERRE AND PM 666
NIGERIA NG 566
MIQUELON
NIUE NU 570

letter letter
Code Code
SAINT VINCENT VC 670 REPUBLIC
AND THE TAIWAN TW 158
GRENADINES
TAJIKISTAN TJ 762
SAMOA WS 882
TANZANIA, UNITED TZ 834
SAN MARINO SM 674 REPUBLIC OF
SAO TOME AND ST 678 THAILAND TH 764
PRINCIPE
TIMOR-LESTE TL 626
SAUDI ARABIA SA 682
TOGO TG 768
SENEGAL SN 686
TOKELAU TK 772
SERBIA AND CS 891
MONTENEGRO TONGA TO 776
SEYCHELLES SC 690 TRINIDAD AND TT 780
TOBAGO
SIERRA LEONE SL 694
TUNISIA TN 788
SINGAPORE SG 702
TURKEY TR 792
SLOVAKIA SK 703
TURKMENISTAN TM 795
SLOVENIA SI 705
TURKS AND CAICOS TC 796
SOLOMON ISLANDS SB 90 ISLANDS
SOMALIA SO 706 TUVALU TV 798
SOUTH AFRICA ZA 710 UGANDA UG 800
SOUTH GEORGIA GS 239 UKRAINE UA 804
AND THE SOUTH
SANDWICH UNITED ARAB AE 784
ISLANDS EMIRATES
SPAIN ES 724 UNITED KINGDOM GB 826
SRI LANKA LK 144 UNITED STATES US 840
SUDAN SD 736 UNITED STATES UM 581
MINOR OUTLYING
SURINAME SR 740 ISLANDS
SVALBARD AND JAN SJ 744 URUGUAY UY 858
MAYEN ISLANDS
UZBEKISTAN UZ 860
SWAZILAND SZ 748
VANUATU VU 548
SWEDEN SE 752
VATICAN CITY VA 336
SWITZERLAND CH 756 STATE (HOLY SEE)
SYRIAN ARAB SY 760 VENEZUELA VE 862

Country Codes
Country Two- ISO #
letter
Code
VIET NAM VN 704
VIRGIN ISLANDS VG 92
(BRITISH)
VIRGIN ISLANDS VI 850
(U.S.)
WALLIS AND WF 876
FUTUNA ISLANDS
WESTERN SAHARA EH 732
YEMEN YE 887
ZAMBIA ZM 894
ZIMBABWE ZW 716

Business Data Director - Implementation Guide

Hochgeladen von

Dokumentinformationen

Originalbeschreibung:

Copyright

Verfügbare Formate

Dieses Dokument teilen

Dokument teilen oder einbetten

Freigabeoptionen

Stufen Sie dieses Dokument als nützlich ein?

Sind diese Inhalte unangemessen?

Copyright:

Verfügbare Formate

Business Data Director - Implementation Guide

Hochgeladen von

Copyright:

Verfügbare Formate

Siperian Hub

Business Data Director™

Siperian Hub Business Data Director Implementation Guide 2

3 Siperian Hub Business Data Director Implementation Guide

Siperian Hub Business Data Director Implementation Guide 4

Intended Audience and Scope of Document

5 Siperian Hub Business Data Director Implementation Guide

Subject Area Characteristics

Subject Area Group

One:Many Child Relationships

Many:Many Child Relationships

Siperian Hub Business Data Director Implementation Guide 6

Basic (SQL-based) Search

Extended - Match based Search

7 Siperian Hub Business Data Director Implementation Guide

Cleansing & Standardization

SAM and Security

Object and Column Security

9 Siperian Hub Business Data Director Implementation Guide

Siperian Hub Business Data Director Implementation Guide 10

Before You Begin

Step 1: Create the BDD Application

11 Siperian Hub Business Data Director Implementation Guide

Step 2: Configure Subject Area Group

Step 3: Configure Subject Area

Step 3.1: Configure Subject Area in the Hub Console

Siperian Hub Business Data Director Implementation Guide 12

Step 4: Configure Layout and Other Display Features (Manual)

13 Siperian Hub Business Data Director Implementation Guide

Step 6: Configure Search

Step 6.1: Configure Basic Search

Siperian Hub Business Data Director Implementation Guide 14

Step 6.2: Configure Extended Search

Step 6.3: Configure the Public Queries

Step 7: Configure Match and Duplicate Searches in BDD

Step 8: Configure the Workflow

Step 9: Localize BDD Applications (If Applicable)

Step 10: Configure Security

15 Siperian Hub Business Data Director Implementation Guide

Import Option Description

Siperian Hub Business Data Director Implementation Guide 16

Validation, Application State & Deployment

valid_ind Validation Description

17 Siperian Hub Business Data Director Implementation Guide

active_ind Name Description

Siperian Hub Business Data Director Implementation Guide 18

Logical ORS Databases

Tree Level Description

19 Siperian Hub Business Data Director Implementation Guide

Resource Kit Item Description

Siperian Hub Business Data Director Implementation Guide 20

21 Siperian Hub Business Data Director Implementation Guide

Siperian Hub Business Data Director Implementation Guide 22

Layout Item Description

Validation and Cleanse

• Primary data – the Save

Siperian Hub Business Data Director Implementation Guide 24

25 Siperian Hub Business Data Director Implementation Guide

User Interface Extensions

Siperian Hub Business Data Director Implementation Guide 26

<help bddHelp="true" customBddHelp="false"/>

27 Siperian Hub Business Data Director Implementation Guide

Sizing and Platform Requirements