API Dev Guide
API Dev Guide
Version 6.9
Contents
CHAPTER 1
ROM and PROM APIs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7
The Repository Object Model (ROM) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7
Connecting to a Repository . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7
Exploring the ROM Model. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8
Repository Item Typing Attributes. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8
Project Repository Object Model (PROM) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9
The PROM Project (NdPromProject) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9
Exploring the PROM Model . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10
PROM Item Content (NdPromItemContent) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11
NdPromEntity (and its sub-interfaces). . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11
NdPromTemplate . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12
NdPromInstance . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12
NdPromProvider . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12
Entity Object Model . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12
Accessing Entity Content . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12
SRL Entity Object Model . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14
Ruleflow Object Model . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15
Question Set Object Model. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15
Common ROM API and PROM API Tasks . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15
Specifying a Location (NdLocation) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15
Creating Directories . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16
Creating a PROM Project . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17
Loading a PROM Project . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18
Creating an SRL Ruleset . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18
Creating an SRL Function (NdPromSrlFunction). . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21
Creating a Ruleflow (NdPromFlowRuleflow) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22
Creating a Question Set (NdPromAaiQuestionSet) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22
Creating an SRL Class (NdPromSrlClassContent) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23
Creating an SRL Enumeration (NdPromSrlEnumerationContent) . . . . . . . . . . . . . . . . . . . . . . . 24
CHAPTER 2
BOM Admin APIs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 27
Manipulating Imported External Classes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 27
NdPromBomAdmin . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 27
NdClassMappingInfo . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 27
NdClassNameCustomizingInfo . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 28
Creating a New XML BOM . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 28
Saving a New or Existing BOM . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 28
Saving a New BOM . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 28
Saving an Existing BOM . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 29
CHAPTER 3
Metaphor APIs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31
Loading a Metaphor Instance . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31
Creating a Metaphor Model . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31
Decision Table Editing API . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 32
Example: Display an Overview of a Decision Table . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 34
Decision Tree Editing API . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 34
Example: Create a Subtree . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 36
Score Model Editing API . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 37
Example: List Contents of a Score Model . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 40
CHAPTER 4
Custom Provider API . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 43
Responsibilities of Provider Classes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 43
Overview of the Custom Provider API . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 44
NdTemplateValueProvider Interface . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 44
NdDefaultTemplateValueProvider . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 45
NdConstrainedListProvider Interface. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 45
NdDefaultConstrainedListProvider . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 46
NdDesignProvider Interface . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 46
NdProvidesDefaultValue Interface . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 47
Creating Custom Provider Classes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 47
Simple Value List Provider . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 48
Simple SRL and Display List Provider . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 49
Customizing Provider Behavior Using Arguments . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 51
Defining Argument Descriptors . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 52
Processing Arguments . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 54
The Example Base Class . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 55
Custom Provider Implementation Guidelines . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 56
CHAPTER 5.............................................
RMA Service and Session APIs . . . . . . . . . . . . . . . . . . . . . . 59
The RMA Service API . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 59
The RMA Repository (NdRmaRepository) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 59
RMA Project (NdRmaProject) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 60
RMA Entry (NdRmaEntry). . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 63
RMA Directory (NdRmaDirectory). . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 64
RMA Files . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 65
File (NdRmaFile) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 65
Project (NdRmaProject) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 66
Subproject (NdRmaSubProject) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 66
Template File (NdRmaTemplateFile) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 67
Instance File (NdRmaInstanceFile) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 67
Editable File (NdRmaEditableFile) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 67
File Content (NdRmaFileContent). . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 68
RMA Template (NdRmaTemplate) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 68
RMA Instance (NdRmaInstance) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 69
Instance Element Node (NdInstanceElementNode) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 74
Versioning. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 75
Versioning Operations (NdRmaEntryVersioningOperations) . . . . . . . . . . . . . . . . . . . . . . . 75
Versioning Information (NdRmaEntryVersioningInfo) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 76
RMA Queries . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 77
Query Instance (NdRmaQueryInstance) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 77
Query Results (NdRmaQueryResultItem) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 78
Filtering Entries in an RMA Project . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 78
RMA Entry Filter Manager (NdRmaEntryFilterManager) . . . . . . . . . . . . . . . . . . . . . . . . . . . 79
Entry Exclusion Filter (NdRmaEntryExclusionFilter) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 80
RMA Session API . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 81
RMA Session (NdRmaSession) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 82
RMA Session Properties (NdRmaSessionProperties) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 84
RMA View (NdRmaView) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 84
RMA View Properties (NdRmaViewProperties) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 87
CHAPTER 6
Base Repository and Version Management APIs . . . . . . . . . 89
Storage Layer Interfaces . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 89
About the Workspace . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 90
Version Management Client Interfaces . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 90
Version Management System Interfaces . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 91
Administration Interfaces . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 91
Repository Connections . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 92
Repository Configurations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 92
Repository Entry Filters . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 92
The FICO™ Blaze Advisor® business rules management system ROM and PROM APIs
allow you to programmatically read, modify and create entries in the repository. You
can use the APIs to navigate a repository, modify or create a project, create directories
and add them to a project, inspect and modify the contents of a repository item, create
fixed entities, and perform various versioning operations.
The PROM API provides the ability to load templates and providers and to load, create,
and modify instances. The PROM API also supports the ability to programmatically
create and modify entities with fixed content. The term fixed content, as used in this
chapter, signifies that an entity’s content does not contain dynamic elements like
placeholders.
The “Entity Creation” example contains Java code which demonstrates how to use the
ROM and PROM APIs to create a named object and add it to an existing project; as well
as how to create a new project with several entities. The example is located in
<ADVISOR_HOME>/examples/repositories/ExamplesRepository/API Examples/
PROM API/Entity Creation.
Connecting to a Repository
The NdRomConnectionManager interface provides methods to connect and disconnect
from a repository. Pass an NdWorkspaceConnection object to the
newRepositoryConnectionManager() method of NdRomFactory to obtain an
NdRomConnectionManager instance. The connection context (NdRomConnectionContext)
is used to access ROM once you are connected.
The example code below shows how to obtain a connection to a file-based repository.
// Change the path to the repository as appropriate. The repository should exist.
connection.setRepositoryFolder("C:/repository");
// Connect to repository
NdRomConnectionManager connectionMgr =
NdRomFactory.newRepositoryConnectionManager(connection);
connectionMgr.connect();
NdRomConnectionContext conContext = connectionMgr.getConnectionContext();
NdRomDirectory romRoot = conContext.getRoot();
A client can explore the ROM starting from the root directory, which can be obtained by
calling the getRoot() method on NdRomConnectionContext. From the root, or any other
directory, you can call getEntries() to get all directories and items contained in the
directory.
// connContext is an NdRomConnectionContext
// romRoot is the root directory of the repository.
NdRomDirectory romRoot = connContext.getRoot();
NdRomEntry[] allEntriesInRepository = romRoot.getEntries();
If you know the location of a repository item, you can look up the entry by calling
lookupEntry(NdLocation) on the directory. The location is specified from the root
directory. NdLocation is discussed in “Specifying a Location (NdLocation)” on page 15.
Here is a list of repository items and their typing information by type, subtype, content
type, and target.
In the ROM, the four typing attributes are aggregated into NdRomSchemaElementInfo,
which is accessed from NdRomSchemaElement. The schema elements are managed by
NdRomSchemaManager. It contains a list of all schema elements known to the connected
repository and can lookup the schema element for any repository item.
NdRomSchemaManager is obtained from NdRomConnectionContext.
This code retrieves the type and subtype attributes of a repository item.
/ project is an NdPromProject
NdPromSrlEnumerationContent enumeration =
NdPromBomConstructContentFactory.newSrlEnumerationContent(project);
NdRomSchemaElement schemaElement = schemaManager.lookupSchemaElement(
TYPE_SRL_ENUMERATION, SUB_TYPE_NONE, CONTENT_TYPE_FIXED, TARGET_SRL);
NdPromItemFactory factory = schemaElement.getItemFactory();
NdPromItem enumItem = factory.newItem((NdPromEntity)enumeration, project);
...
The integer constants for the repository schema typing attributes, including those in the
code above, are declared in the NdRomSchemaConstants interface.
project. Such a definition effectively defines a scope, which includes all the directories
included by this project, and all the directories included by its subprojects. An instance
of NdPromProject gives access to all the repository entries in the scope. These repository
directories and repository items and their contents form the PROM.
// connContext is an NdRomConnectionContext
// “/directory” represents a directory directly under the repository root
NdRomDirectory root = connContext.getRoot();
NdLocation location = NdLocationFactory.createLocation(“/directory/projectItem”);
NdRomProject romProject = (NdRomProject)root.lookupEntry(location);
NdPromProjectFactory factory = context.getProjectFactory();
NdPromProject project = factory.createProject(romProject);
To create a new project at a location, the client should use the same project factory. The
following is an example of creating a new project. The new project repository item is
created in the directory.
The topics of loading and creating a project are discussed in greater detail in “Loading a
PROM Project” on page 18 and “Creating a PROM Project” on page 17.
The PROM API builds on the raw access to the repository which is defined in ROM API
by providing access to the repository with typing and caching. The getItemContent()
method in NdPromItem returns a typed object. This is different from NdRomItem which
has content that is always a String.
The content of a repository item is only loaded after the getItemContent() method is
called. The content is loaded to cache. Once loaded, any change to the content is not
persisted to the storage until the save() method of NdPromItem is called. Any change in
the storage is not reflected in the loaded content until revert() is called and
getItemContent() is called again to load the content from storage.
The addItem() method and removeItem() method in NdPromDirectory only affect the in
memory object model until the save() method is called on the NdPromItem.
// project is an NdPromProject
NdLocation location = NdLocationFactory.createLocation(“item/location”);
NdPromItem item = (NdPromItem)project.lookupEntry(location);
NdPromItemContent content = item.getItemContent();
// project is an NdPromProject
NdLocation location = NdLocationFactory.createLocation(“directory”);
NdPromDirectory directory = (NdPromDirectory)project.lookupEntry(location);
NdPromItem item = factory.newItem(content, project);
directory.addItem(item);
item.save();
The following is an example of deleting an existing repository item. Note that the item is
removed in PROM and then saved in order to persist the change to storage.
// project is an NdPromProject
NdLocation parentLoc = NdLocationFactory.createLocation(“directory/item”);
NdPromDirectory directory = (NdPromDirectory)project.lookupEntry(parentLoc);
NdLocation itemLoc = NdLocationFactory.createLocation(“item/location”);
NdPromItem item = (NdPromItem)project.lookupEntry(itemLoc);
directory.removeItem(item);
item.save();
More details of the entity API can be found in “Entity Object Model” on page 12.
NdPromTemplate
If the content of the repository item is an Innovator template of an entity, the content
object must be an NdPromTemplate object. NdPromTemplate gives the client access to the
templatized entity through getEntityContent() method, which returns a specific
instance of NdPromEntityContent. For example, if the content of the repository item is
an Innovator template of an SRL ruleset, getEntityContent() method returns an
instance of NdPromSrlRulesetContent, which extends NdPromEntityContent.
NdPromInstance
If the content of the repository item is an instance of template, the content object must be
an NdPromInstance object. NdPromInstance gives the client access to the instantiation
object model, i.e., a tree of instance nodes. It allows access to the entity resolved from
this instance and its linked template. The resolved entity can be obtained through
getResolvedEntity() method, which returns a specific instance of NdPromEntity. For
example, if the content of the repository item is an Innovator instance of an SRL ruleset,
getResolvedEntity() returns an instance of NdPromSrlRuleset, which extends
NdPromEntity.
NdPromProvider
If the content of the repository item is a provider, the content object must be an
NdPromProvider object. NdPromProvider gives client access to the provider's definition,
including the provider class name.
The interfaces of the string-based API represent any field that is text in nature as a
String. This set of interfaces is used to access entities that are not templatized, but are
resolved entities. It provides read-only access. It is primarily used for inspecting the
object model.
The interfaces of the content-based API represent any field that is text in nature by
NdPromTextContent, which is a data structure that may contain dynamic elements like
These two sets of APIs are almost parallel to each other. The naming convention is that
the interface names and method names in the content-based API have the word Content
appended to their counterparts in the string-based API. For example, the content-based
counterpart to the string-based interface NdPromSRLRuleset is
NdPromSRLRulesetContent. NdPromSrlRule is the string-based correlary to
NdPromSrlRuleContent, and so on.
The following code demonstrates how to access a ruleset using string-based interfaces.
A ruleset is represented by the string-based NdPromSrlRuleset interface. The method
getName() returns the ruleset name as a String.
// item is an NdPromItem
NdPromSrlRuleset ruleset = (NdPromSrlRuleset) item.getItemContent();
String name = ruleset.getName();
An SRL rule (NdPromSrlRule) is obtained from the array of ruleset items. NdPromSrlRule
and the other types of ruleset items, such as NdPromSrlPattern, subclass
NdPromSrlRulesetItem.
The rule body (NdPromSrlRuleBody) is obtained from a rule in a ruleset that is not
templatized using the getSrlRuleBody() method.
Here is code which performs similar work using the corresponding content-based
interfaces. The ruleset name is obtained as an NdPromTextContent object.
NdPromSrlRuleContent extends NdPromSrlRuleContent and represents an SRL rule
which could be either templatized or contain fixed content. Similarly, the
NdPromSrlRuleBodyTextContent ruleBody can contain templatized content or fixed
content.
// item is an NdPromItem
NdPromSrlRulesetContent ruleset = (NdPromSrlRulesetContent) item.getItemContent();
NdPromTextContent name = ruleset.getNameContent();
NdPromSrlRulesetItemContent[] items = ruleset.getSrlRulesetItemContents();
// assumes the ruleset item content is a rule
NdPromSrlRuleContent rule = NdPromSrlRulesetItemContent[0];
NdPromSrlRuleBodyTextContent ruleBody = rule.getRuleBodyContent();
As already mentioned, the content-based API contains methods for creating and
modifying the entity content. Use the static newTextContent() method of the
This example uses the string-based API to find a particular rule in a ruleset, then it casts
the rule to an NdPromSrlRuleContent object, which is content-based, in order to change
the rule body content.
// project is an NdPromProject
NdLocation rulesetLocation = NdLocationFactory.createLocation("Cross-sell Rules/crossSell");
NdPromItem rulesetPromItem = (NdPromItem)project.lookupEntry(rulesetLocation);
NdPromSrlRuleset ruleset = (NdPromSrlRuleset) rulesetPromItem.getItemContent();
NdPromSrlRulesetItem[] rulesetItems = ruleset.getSrlRulesetItems();
For examples on how to create SRL entities, see “Creating an SRL Ruleset” on page 18,
“Creating an SRL Enumeration (NdPromSrlEnumerationContent)” on page 24 and
“Creating an SRL Function (NdPromSrlFunction)” on page 21.
For an example of how to create a question set, see “Creating a Question Set
(NdPromAaiQuestionSet)” on page 22.
NdLocationFactory contains these static methods, as well as others, which are used to
create an NdLocation.
In the first method, if the location is absolute (in which case the value of the boolean
absolute is true), each element in the String array represents the name of one of the
repository folders in a path from the root of the repository to the item in question, with
the last element of the array being the storage name of the item. When the location is
relative (the value of the boolean absolute is false), the elements in the String array
represent a directory path that is processed in the context of another location.
The following two method calls are equivalent. They create an NdLocation that is a
relative location.
These method calls are also equivalent. They create an NdLocation that is an absolute
location.
// projectFactory is an NdPromProjectFactory
NdPromProject project = projectFactory.createProject(NdLocationFactory.createLocation(
new String[]{"PROM API Example", "Entity Creation"}, true));
NdPromProject project = projectFactory.createProject(NdLocationFactory.createLocation(
"/PROM API Example/Entity Creation"));
In the first method call the components are elements in a String array. The latter
method call represents the components in a String. The leading ‘/’ character indicates
that the location is absolute.
Whether you should specify the location as absolute or relative will depend on the task
at hand. As mentioned, relative locations are processed in the context of another
location. When a directory is created the location is processed in the context of a parent
directory or the root of the repository. For this reason, you must use a relative location
when created a directory. When looking up a repository item or directory in a project
using the lookupEntry() method of the NdPromProject interface, the location is relative
since the project provides the context. The lookupEntry() method of the
NdRomDirectory interface, however, looks up the entry from the root of the respository
when the supplied location is absolute. If the location is relative the lookup is performed
from the directory. The NdPromProject interface addDirectory() method, which is used
to add a directory to the project, requires an absolute location. The Blaze Advisor API
Reference entry for each method that takes an NdLocation parameter specifies whether to
use an absolute or a relative location.
Creating Directories
You can create directories with the createDirectory() method of the
NdRomMutableDirectory class. NdRomMutableDirectory is a repository directory that is
mutable. NdRomMutableDirectory extends NdRomDirectory. A mutable directory allows
entries to be added or deleted. Recall that a directory contains entries, which are either
other directories or repository items. NdRomMutableDirectory has methods for creating
both. The deleteEntry() method physically deletes the given repository entry from the
directory.
To create a directory under the repository root directory, obtain the root
NdRomDirectory by calling getRoot() on the repository context object
(NdRomConnectionContext). Call createDirectory() on the root directory with the
NdLocation parameter that specfies the location of the new directory. Whenever you
create a directory, the location must be relative and contain only one element in the
String array. The absolute parameter to createLocation() is false when the location
is relative. A new directory is always created with the NdRomMutableDirectory object of
the parent directory and therefore the location is relative to the parent directory. See
“Specifying a Location (NdLocation)” on page 15 for discussion of relative and absolute
locations.
// conContext is an NdRomConnectionContext
NdRomDirectory romRoot = conContext.getRoot();
NdLocation topDirectoryLocation = NdLocationFactory.createLocation(
new String[]{"Prom API Example"}, false);
NdRomDirectory topDirectory = ((NdRomMutableDirectory) romRoot).createDirectory(topDirectoryLocation);
((NdRomMutableDirectory) topDirectory).setDisplayName("PROM API Example");
The directory is created in storage immediately. Note that romRoot must be cast to
NdRomMutableDirectory. NdRomDirectory does not contain methods for creating
repository entries. Set the directory's display name in the GUI with setDisplayName().
The steps are similar for creating a directory in another directory. First, create an
NdLocation that is a relative location with one component. Pass the NdLocation object to
the NdRomMutableDirectory createDirectory() method of the NdRomMutableDirectory
object obtained for the parent directory.
// topDirectory is an NdRomDirectory
NdLocation projectLocation = NdLocationFactory.createLocation(new String[]{"Entity Creation"}, false);
NdRomDirectory entityCreationDirectory =
((NdRomMutableDirectory) topDirectory).createDirectory(projectLocation);
// project is an NdPromProject
NdPromDirectory projectDirectory = project.addDirectory(entityCreationDirectory.getLocation());
The next section, “Creating a PROM Project” on page 17, completes the discussion of
creating a directory structure for your project.
This code creates a PROM project in the Entity Creation directory and adds the
directory to the project.
When the project is saved, a repository item of type Project is created in the Entity
Creation directory (entityCreationDirectory). Note that the directory must still be
added to the project by passing the directory location to the NdPromProject
addDirectory() method. As you create more directories for your project, each directory
must be added to the project in this manner.
In like fashion, you can add any directory within the repository to a project. The
NdLocation must be an absolute location. All repository directories that are traversed
from the repository root must be named in component parameter's String array.
// conContext is an NdRomConnectionContext
NdPromProjectFactory projectFactory = conContext.getProjectFactory();
NdLocation projectLocation = NdLocationFactory.createLocation(
new String[]{"PROM API Example", "Entity Creation", "Entity Creation"}, true));
NdRomProject romProject = (NdRomProject)romRoot.lookupEntry(projectLocation);
NdPromProject project = projectFactory.createProject(romProject);
Note When you use the PROM API to work with multiple projects, you can release the
resources that a project holds on to by calling the dispose() method of the
NdPromProject interface. To access the project after calling dispose() you must load the
project again.
The example in this section creates a fixed-content SRL ruleset. The public PROM APIs
in the current release of the FICO Blaze Advisor do not support creating templatized
content.
Creating a ruleset and ruleset items follows the general pattern of creating the ruleset
with the rewSrlRulesetContent() of NdPromSrlConstructContentFactory interface;
creating each ruleset item with the appropriate NdPromSrlConstructContentFactory
method; creating the content for the ruleset item, usually with methods of
NdPromSrlConstructContentFactory and NdPromTextContentFactory; setting the
content on the ruleset item; and then inserting the ruleset item into the ruleset and
saving the ruleset.
// project is an NdPromProject
// Create 'Cross-sell' ruleset, with rule and two patterns, in 'Cross-sell Rules' directory
NdPromSrlRulesetContent ruleset = NdPromSrlConstructContentFactory.newSrlRulesetContent(project);
ruleset.setNameContent(NdPromTextContentFactory.newTextContent("crossSell"));
// Create NdPromItem for the ruleset, add to a PROM directory and save.
// schemaManager is an NdRomSchemaManager
NdRomSchemaElement schemaElement = schemaManager.lookupSchemaElement(TYPE_SRL_RULESET,
SUB_TYPE_NONE, CONTENT_TYPE_FIXED, TARGET_SRL);
NdPromItemFactory rulesetFactory = schemaElement.getItemFactory();
NdPromItem rulesetItem = rulesetFactory.newItem((NdPromItemContent)ruleset, project);
// crossSellDiretory is an NdPromDirectory
crossSellDirectory.addItem(rulesetItem);
rulesetItem.save();
// project is an NdPromProject
project.save();
NdPromSrlBodyTextContent functionBody =
NdPromSrlConstructContentFactory.newSrlBodyContent(functionBodyString);
function.setSrlBodyContent(functionBody);
// Create NdPromItem for function and add to "Test" directory
schemaManager = project.getRomConnectionContext().getSchemaManager();
schemaElement = schemaManager.lookupSchemaElement(TYPE_SRL_FUNCTION, SUB_TYPE_NONE,
CONTENT_TYPE_FIXED, TARGET_SRL);
NdPromItemFactory functionItemFactory = schemaElement.getItemFactory();
NdPromItem functionItem = functionItemFactory.newItem((NdPromItemContent)function, project);
testDirectory.addItem(functionItem);
functionItem.save();
// project is an NdPromProject
// testDirectory is an NdPromDirectory that has been added to the project
NdPromFlowRuleflowContent ruleflow =
NdPromFlowConstructContentFactory.newFlowRuleflowContent(project);
ruleflow.setNameContent(
NdPromTextContentFactory.newTextContent("newRuleflow"));
// Create a flow.
NdPromFlowFlowContent flow =
NdPromFlowConstructContentFactory.newFlowFlowContent();
ruleflow.setFlowFlowContent(flow);
// Create a task.
NdPromFlowTaskContent task =
NdPromFlowConstructContentFactory.newFlowTaskContent();
task.setNameContent(
NdPromTextContentFactory.newTextContent("newTask"));
task.setImplementationNameContent(
NdPromTextContentFactory.newTextContent("newRuleset"));
task.insertFlowParameterContentAt(
NdPromFlowConstructContentFactory.newFlowParameterContent("param1"), 0);
task.insertFlowInputContentAt(
NdPromFlowConstructContentFactory.newFlowInputContent("foo"), 0);
flow.insertFlowFlowItemContentAt(task, 0);
schemaManager = project.getRomConnectionContext().getSchemaManager();
schemaElement = schemaManager.lookupSchemaElement(TYPE_RULEFLOW, SUB_TYPE_NONE,
CONTENT_TYPE_FIXED, TARGET_SRL);
NdPromItemFactory factory = schemaElement.getItemFactory();
NdPromItem item = factory.newItem((NdPromFlowRuleflow) ruleflow, project);
testDirectory.addItem(item);
item.save();
Note The getType() method in the NdPromFlowTask interface has been renamed
getImplementationType().
// project is an NdPromProject
// testDirectory is an NdPromDirectory that has been added to the project
NdPromAaiQuestionSetContent questionSet =
NdPromAaiConstructContentFactory.newAaiQuestionSetContent(project);
questionSet.setNameContent(
NdPromTextContentFactory.newTextContent("newQuestion"));
questionSet.setCommentContent(
NdPromTextContentFactory.newTextContent("Sample question set"));
// Add a question.
NdPromAaiQuestionContent question =
NdPromAaiConstructContentFactory.newAaiQuestionContent();
question.setPromptContent(
NdPromTextContentFactory.newTextContent("What is the driver's age?"));
NdPromAaiClassPropertyContent classProperty =
question.getAaiClassPropertyContent();
classProperty.setClassNameContent(
NdPromTextContentFactory.newTextContent("Driver"));
classProperty.setPropertyNameContent(
NdPromTextContentFactory.newTextContent("age"));
questionSet.insertAaiQuestionContentAt(question, 0);
schemaManager = project.getRomConnectionContext().getSchemaManager();
schemaElement = schemaManager.lookupSchemaElement(TYPE_QUESTION_SET, SUB_TYPE_NONE,
CONTENT_TYPE_FIXED, TARGET_SRL);
NdPromItemFactory factory = schemaElement.getItemFactory();
NdPromItem item = factory.newItem((NdPromAaiQuestionSet) questionSet, project);
testDirectory.addItem(item);
item.save();
This code creates class content for the SRL class, inserts a field definition into the
content, and saves the class as a PROM item in the appropriate directory which has
been previously added to the project.
NdPromSrlClassContent classContent =
NdPromBomConstructContentFactory.newSrlClassContent(project);
NdPromTextContent className =
NdPromTextContentFactory.newTextContent("SimpleSRLClass");
classContent.setNameContent(className);
NdPromSrlPropertyContent prop =
NdPromBomConstructContentFactory.newSrlPropertyContent();
NdPromTextContent propName = NdPromTextContentFactory.newTextContent("customerName");
prop.setNameContent(propName);
NdPromSrlGenericTypeContent propType =
NdPromSrlConstructContentFactory.newSrlGenericTypeContent("string");
prop.setSrlGenericTypeContent(propType);
classContent.insertSrlPropertyContentAt(prop, 0);
The FICO™ Blaze Advisor® business rules management system BOM Admin APIs
allow you to o programmatically update imported external classes represented as BOM
project-level item contents in a repository. The APIs enable you to obtain mapping
information, customize a class name, or create and save a new XML BOM. This chapter
provides an introduction to some of those capabilities. Consult the Blaze Advisor API
Reference for more detailed information. The API Reference is available by selecting API
Reference from the Builder Help menu.
The BOM Admin APIs are used to programmatically access and manipulate the
imported external classes represented in a Blaze Advisor repository as BOM PROM
item contents. The engine layer APIs are used to manage the imported classes within an
engine layer class provider resource.
You can use these APIs to add imported classes from an external object model resource,
remove classes from the BOM and its associated class provider resource, customize the
imported classes by renaming them in the BOM, and retrieve imported class mapping
information.
Note The code snippets provided show how to use the APIs and are not necessarily
complete working examples.
NdPromBomAdmin
The main entry point for BOM manipulation is the NdPromBomAdmin class.
NdClassMappingInfo
Mapping information is used to provide the names of the raw input to the underlying
BOM. This means that mapping information is different for each BOM supported by
Blaze Advisor. For example, you would need to use the API differently to obtain
mapping information for a Java BOM than to obtain mapping information for an XML
BOM.
Package names:
com.blazesoft.engine.rules
com.blazesoft.engine.rules.java (for NdJavaClassMappingInfo)
com.blazesoft.engine.rule.xml (for NdXmlClassMappingInfo)
Example:
or
NdXmlClassMappingInfo xi = new NdXmlClassMappingInfo();
xi.setXmlSchema(“mySchema.xsd”);
NdClassNameCustomizingInfo
If you want to customize a class name during BOM manipulation, you use the
NdClassNameCustomizingInfo class. The NdClassNameCustomizingInfo class has a
name pair holder for the native class name and the customized Blaze Advisor class
name.
Example:
Package names:
com.blazesoft.template.repository.objects.bom.NdPromBomConstructContentFactory
com.blazesoft.template.repository.objects.NdPromTextContent
Example:
...
_bomType = 24; //XML BOM Type
NdPromExternalBomContent bomContent = NdPromBomConstructContentFactory.
newExternalBomContent((NdPromRulesProject) _project, _bomType);
NdPromTextContent pc = NdPromTextContentFactory.newTextContent(_bomItemName);
bomContent.setNameContent(pc);
...
Package names:
com.blazesoft.template.repository.PromItemContent
com.blazesoft.template.repository.PromItem
Example:
...
//Save the BOM item-- needs to change
NdPromItemContent itemContent = (NdPromItemContent) bomContent;
//Create a NdPromItem for the BOM and add it to a directory
schemaManager = project.getRomConnectionContext().getSchemaManager();
schemaElement = schemaManager.lookupSchemaElement(TYPE_BUSINESS_OBJECT_MODEL,
SUB_TYPE_XML_BOM, CONTENT_TYPE_FIXED, TARGET_SRL);
NdPromItemFactory itemFactory = schemaElement.getItemFactory();
NdPromItem promItem = itemFactory.newItem(itemContent, _project);
_projectDirectory.addItem(promItem);
promItem.save();
...
Package names:
com.blazesoft.template.repository.PromItemContent
com.blazesoft.template.repository.PromItem
Example:
...
//Save the BOM item
NdPromItemContent itemContent = (NdPromItemContent) bomContent;
NdPromItem promItem = itemFactory,getItem();
promItem.save();
...
Metaphor APIs
The FICO™ Blaze Advisor® business rules management system Metaphor APIs
provide programatic access to the Blaze Advisor metaphors: decision table, decision
tree, and score model. The APIs enable you to examine and edit the contents of
metaphor instances as well as create new instances. This chapter provides an
introduction to some of those capabilities. Consult the Blaze Advisor API Reference for
more detailed information. The API Reference is available by selecting API Reference
from the Builder Help menu.
Once a project has been opened, you can load the metaphor instance in this fashion:
In the example code throughout this chapter instantiationElt will refer to the
instance. If the instance is global (i.e. the metaphor instance is a direct child of a
repository directory), then this is sufficient. The metaphor instance will be what
instantiationElt refers to. Otherwise, you need to navigate the instance to find the
instantiation element that corresponds to the metaphor instance, as shown here:
instanceElt = instantiationElt.safeLookup(metaphorInstanceName);
if (NdMetaphorSupport.isDecisionTableInstance(instanceElt)) {
// execute code to deal with decision tables
}
NdDecTableModelFactory.createDecTableModel()
Creates a new instance of a decision table model, returned as an NdDecTableModel.
NdDecTreeModelFactory.createDecTreeModel()
Creates a new instance of a decision tree model, returned as an NdDecTreeModel.
NdScoreModelModelFactory.createScoreModelModel()
Creates a new instance of a score model, returned as an NdScoreModelModel.
Each factory class has a method to set the instantiation element on the model.
For a decision table, call the NdDecTableModelFactory.setDecTableInstance()
method.
For a decision tree, call the NdDecTreeModelFactory.setDecTreeInstance()
method.
For a score model, call the NdScoreModelModelFactory.setScoreModelInstance()
method.
The decision table model instance decTableModel in the code below is used to edit the
decision table, as described in the following section, “Decision Table Editing API” on
page 32. Similar code is used to create decision tree and score model instances. These
models are discussed in “Decision Tree Editing API” on page 34 and “Score Model
Editing API” on page 37.
if (NdMetaphorSupport.isDecisionTableInstance(instanceElt)) {
NdDecTableModel decTableModel = NdDecTableModelFactory.createDecTableModel();
NdDecTableModelFactory.setDecTableInstance(decTableModel, instanceElt);
}
The “Decision Table Import” example demonstrates how to use the Decision Table
Editing APIs to create an instance of a single-axis (columns) decision table template and
populate it with data obtained from a CSV file that was generated in Microsoft Excel.
The example is located in <ADVISOR_HOME>/examples/ExamplesRepository/API
Examples/Metaphor APIs/Decision Table Import.
Several of the methods in NdDecTableModel access cells in a decision table by row and
column coordinates. NdDecTableCellCoordinates represents the coordinates of a cell.
This statement sets the field value of the cell at row 2, col 3 in a decision table. The cell
template for this cell is = ‘string’, which has only one placeholder. The index of the
placeholder, or field, within the cell is 0.
When you specify a numeric range, set the first number at placeholder index 0 and the
second number at placeholder index 1 of the cell. The cell template display name for this
cell is 'real1' < .. <= 'real2', which has two placeholders. These statements set the
range 1.0 < .. <= 3.5 on the cell.
The selectCellTemplate() method selects the cell template display name on the cell at
the specified coordinates. This process is called binding. The cell template display name
selected must be one of the allowed cell templates specified for the cell, just as a user in
the GUI selects a cell template from a drop-down list of allowed cell templates. The
allowed cell templates have been defined in the decision table wizard or manually in
// decTreeModel is an NdDecTreeModel
NdDecTreePath root = new NdDecTreePath();
NdDecTreePath path1 = decTreeModel.getNodeOutgoingNodeAt(root, 0);
NdDecTreePath path2 = decTreeModel.getNodeOutgoingNodeAt(path1, 0);
path2 is the first child of the first child of the root node. For the decision tree diagramed
below, that is the path to the "Model Year" node for "Charger".
The image below depicts a portion of the decision tree in the “Decision Tree with
Patterns” example in <ADVISOR_HOME>/examples/repositories/ExamplesRepository/
Metaphors and Templates/Decision Trees/Decision Tree with Patterns.
You can obtain the incoming link condition value ("Charger") and the node label
("Model Year") with these methods:
// returns "Charger"
String condition = decTreeModel.getIncomingLinkConditionValue(path2,0));
// returns "Model Year"
String label = decTreeModel.getNodeLabel(path2));
The “incoming link selected condition format label” is the name of template that is used
with the incoming link condition value. Use the
getIncomingLinkSelectedConditionFormatLabel() method to obtain it.
You can examine a template to determine the number of placeholders. There is one
placeholder for a string value in Model = 'string'. You can use the
setIncomingLinkConditionValue() method to change the value of the incoming link
condition from "Charger" to "Corvette". The middle parameter is the placeholder index.
decTreeModel.setIncomingLinkConditionValue(path2, 0, "Corvette");
The set of allowed condition group labels for outgoing links for this node is obtained
with the getAllowedConditionGroupLabelsForOutgoingLinks() method.
You can change the condition group to any of the allowed values using the
selectConditionGroupForOutgoingLinks() method.
// returns: 2
int count = decTreeModel.getNodeOutgoingLinksCount(path2));
This example code uses the getNodeOutgoingNodeAt() method to obtain the first
outgoing child node (path3) of the node at path2.
// returns:
// "Model Year = 'integer'", "Model Year > 'integer'", "Model Year < 'integer'",
// "Model Year >= 'integer'", "Model Year <= 'integer',
// "Model Year 'integer1' <= .. <= 'integer2', "otherwise"
String[] allowedFormats = decTreeModel.getIncomingLinkAllowedConditionFormatLabels(path3);
To change the condition to 1962 - 1964, select the appropriate condition format label
from the allowed list. Then, set the value on each placeholder separately.
decTreeModel.selectIncomingLinkConditionFormat(
path3,"Model Year 'integer1' <= .. <= 'integer2'");
decTreeModel.setIncomingLinkConditionValue(path3,0, "1962");
decTreeModel.setIncomingLinkConditionValue(path3,1, "1964");
To obtain the current action value (the rating), use the getActionValue() method.
// returns: 4
int actionValue = decTreeModel.getActionValue(path3, 0, 0));
To change the rating from 4 to 3 and set the node label appropriately, use this code.
decTreeModel.setActionValue(path3, 0, 0, "3.0");
decTreeModel.setNodeLabel(path3, "Rating: 3");
// returns: "GPA_Score"
int chr = 0;
String characteristicLabel = scoreModel.getCharacteristicLabel(chr));
Similarily, to obtain the label of the same characteristic’s first bin, supply the index of
characteristic and the index of the first bin (0) as parameters to the getBinLabel()
method.
To obtain the number of characteristics in the score model and number of bins defined
for a particular characteristic, use the getCharacteristicCount() and getBinCount()
methods.
// returns: 4
int characteristicCount = scoreModel.getCharacteristicCount();
// returns: 5
int binCount = scoreModel.getBinCount(chr);
The Academic Score Instance file is part of the “Basic Score Model” example in
<ADVISOR_HOME>/examples/repositories/ExamplesRepository/
Metaphors and Templates/Score Models/Basic Score Model.
getCharacteristicLabel(), setCharacteristicLabel(),
getCharacteristicDescription(), setCharacteristicDescription(),
getCharacteristicBaselineScore(), setCharacteristicBaselineScore(),
getBinLabel(), setBinLabel(), getBinScoreWeight(), setBinScoreWeight(),
getBinReasonCodeName(), and setBinReasonCodeName().
int range = 0;
NdRangeTableCellTemplatesInfo templatesInfo =
scoreModel.getRangeFormatTemplatesInfo(chr, bin, range);
// returns: "GPA_Score 'real1' <= .. <= 'real2'"
String cellTemplate = templatesInfo.getCurrentCellTemplateDisplayName());
NdRangeTableCellRenderingInfo renderingInfo =
scoreModel.getRangeRenderingInfo(chr, bin, range);
// returns: “3.6” and “4”
String[] cellPHValues = renderingInfo.getValues();
In the example score model, the GPA range is between 3.6 and 4.0, inclusive. Suppose
you want to change the bin to accomodate some advanced placement students whose
GPA can exceed 4.0. You will change the bin label of the “Between 3.6 and 4.0” bin to
“Greater than 3.6”, as well as replace the cell range template and placeholder value.
You may want to begin by obtaining the list of allowed cell template display names by
calling getAllowedCellTemplateDisplayNames() on the
NdRangeTableCellTemplatesInfo object.
The appropriate cell template is GPA_Score >= 'real': GPA is greater than the
placeholder value, inclusive. For the example, the value of the placeholder will be “3.6”.
The following code sets the new bin label, selects the appropriate template for range
cell, and sets the value of the single placeholder defined in the template.
After running the completed API application and reopening the project in the GUI, you
can confirm that the bin is redefined.
The NdScoreModelModel interface has a several other methods that pertain to ranges
which have not been discussed, including: getRangeCount(), getRangeDescription(),
deleteRange(), and insertNewRange().
The NdScoreModelModel interface has methods which are used to move characteristics,
bins, and ranges in a score model. Those methods are: moveBinUp(), moveBinDown(),
moveCharacteristicsUp(), moveCharacteristicsDown(), moveRangeUp(),
moveRangeDown().
NdRangeTableCellTemplatesInfo templatesInfo;
NdRangeTableCellRenderingInfo renderingInfo;
String[] cellPHValues;
This is the output of the code when run against the “Academic Score” score model:
Characteristic: GPA_Score
Bin #0 'Between 3.6 and 4.0' Weight: 50 Reason Code: ACAD01
GPA_Score 'real1' <= .. <= 'real2' (3.6 - 4)
Bin #1 'Between 2.9 and 3.6' Weight: 30 Reason Code: ACAD02
GPA_Score 'real1' <= .. < 'real2' (2.9 - 3.6)
Bin #2 'Between 2.1 and 2.9' Weight: 20 Reason Code: ACAD03
GPA_Score 'real1' <= .. < 'real2' (2.1 - 2.9)
Bin #3 'Less than 2.1 ' Weight: 5 Reason Code: ACAD05
GPA_Score 'real1' <= .. < 'real2' (0 - 2.1)
Bin #4 'All Other' Weight: 0 Reason Code: UEXP
Characteristic: SAT_Score
Bin #0 'Greater than 1400' Weight: 50 Reason Code: ACAD01
SAT_Score >= 'real' (1,400)
Bin #1 'Between 1200 and 1400' Weight: 30 Reason Code: ACAD02
SAT_Score 'real1' <= .. < 'real2' (1,200 - 1,400)
Bin #2 'Between 1000 and 1200' Weight: 20 Reason Code: ACAD03
SAT_Score 'real1' <= .. < 'real2' (1,000 - 1,200)
Bin #3 'Between 800 and 1000' Weight: 10 Reason Code: ACAD04
SAT_Score 'real1' <= .. < 'real2' (800 - 1,000)
Bin #4 'Less than 800' Weight: 5 Reason Code: ACAD05
SAT_Score 'real1' <= .. < 'real2' (0 - 800)
Bin #5 'All Other' Weight: 0 Reason Code: UEXP
<..portion removed..>
Characteristic: Academic Honors
Bin #0 'National Honors' Weight: 50 Reason Code: ACAD01
Academic Honors = 'string' (AP_Scholar)
Academic Honors = 'string' (National_Merit_Scholar)
Academic Honors = 'string' (National_Honors_Scholar)
Bin #1 'Local Honors' Weight: 40 Reason Code: ACAD01
Academic Honors = 'string' (Honor_Roll)
Academic Honors = 'string' (Deans_Award)
Academic Honors = 'string' (Citizenship_Award)
Bin #2 'Service Awards' Weight: 20 Reason Code: ACAD02
Academic Honors = 'string' (Merit_Award)
Bin #3 'No Awards' Weight: 0 Reason Code: ACAD06
Academic Honors = 'string' (none)
Bin #4 'All Other' Weight: 0 Reason Code: UEXP
NdTemplateValueProvider Interface
All providers implement the NdTemplateValueProvider interface. The interface
defines the basic features of a provider. The interface includes conversion methods
which every provider must support. The methods allow the values passed in from the
Innovator engine to be transformed in a manner determined by the provider. The
convertToDisplayValue() method returns the value that should be used for display
purposes in an RMA for a given instantiation value. Conversely,
convertFromDisplayValue() returns the value that should be stored in the
instantiation object for a given display value. (The instantiation object is the binary
representation of the instantiation file.) The convertToContentValue() method is used
to convert an instantiation value to the content value. However, when the instantiation
value and SRL value are the same, which is usually the case with custom providers, no
translation occurs and the method simply returns the instance value that is passed to it.
The setArgs() method sets the values of control variables that customize the behavior
of the provider. For a discussion on designing custom providers with arguments see
“Creating Custom Provider Classes” on page 47.
Other methods return descriptive information about the provider to the Innovator
engine. getProviderType() returns the type of the provider class as a String.
getValueType() returns a constant which indicates the type of value provided by the
provider.
com.blazesoft.template.engine
public interface NdTemplateValueProvider
{
public void checkInstantiationValue(NdProviderContext context, String instantiationValue);
public String convertFromDisplayValue(NdProviderContext context, Object displayValue);
public String convertFromJavaObject(NdProviderContext context, Object javaObject);
public String convertToContentValue(NdProviderContext context, String instantiationValue);
public Object convertToDisplayValue(NdProviderContext context, String instantiationValue);
public Object convertToJavaObject(NdProviderContext context, String instantiationValue);
public Class getDisplayValueClass(NdProviderContext context);
public String getProviderType(NdProviderContext context);
public Class getValueClass(NdProviderContext context);
public int getValueType(NdProviderContext context);
public void reset(NdProviderContext context);
public void setArgs(NdProviderContext context, NdProviderStaticArg[] args);
}
NdDefaultTemplateValueProvider
NdDefaultTemplateValueProvider is an abstract class that provides default
implementations of the methods in the NdTemplateValueProvider interface. The
convert methods (convertToDisplayValue(), etc.) pass values without change.
validateInstantiationValue() does not apply any constraints on the instantiation
value. It returns true for any instantiation value passed to it. setArgs() does not process
any arguments.
As a convenience, providers can subclass this class and override only those methods
needed to define their specific functionality.
NdConstrainedListProvider Interface
NdConstrainedListProvider is a subinterface to the NdTemplateValueProvider
interface. This interface is implemented by a provider when the value it provides must
be constrained to one of a discrete set of values.
NdDefaultConstrainedListProvider
NdDefaultConstrainedListProvider is an abstract class that extends
NdDefaultTemplateValueProvider and implements the
NdConstrainedListProvider interface. It provides default implementations for two of
the methods in the NdConstrainedListProvider interface,
getAllowedDisplayValues() and getAllowedJavaValues(). Providers that extend
NdDefaultContrainedListProvider must implement
getAllowedInstantiationValues(). The getAllowedDisplayedValues() method
first invokes the getAllowedInstantiationValues() method (on the subclass which
implements it) to obtain an array of the allowed instantiation values, and then invokes
convertToDisplayValue() on each element of the array to generate the array of
allowed display values. The default implementation of getAllowedJavaValue() is
identical to getAllowedDisplayValues(). Both methods return an array of allowed
display values.
NdDesignProvider Interface
The NdDesignProvider interface defines the methods that supply meta information
about the provider. This interface is implemented by every standard Blaze Advisor
provider, as well as the example custom providers in the <ADVISOR_HOME>/examples/
customProviders/java/stateProvince directory. The Custom Provider API does not
include a class that provides default implementation of these methods. Your provider
must implement each of these methods.
The NdDesignProvider interface defines the methods that supply meta information
about the provider. This interface is implemented by every standard Blaze Advisor
provider, as well as the example custom providers in the <ADVISOR_HOME>/examples/
customProviders/java/stateProvince directory. The Custom Provider API does not
include a class that provides default implementation of these methods. Your provider
must implement each of these methods.
The getDisplayName() method returns the display name of the provider. The display
name of the provider appears in the provider editor. The getDisplayKey() method
returns a key value which identifies the provider’s icon bitmap and its label.
getDescription() returns the description of the provider. The description is displayed
In New Provider dialog box when the provider’s icon is selected. This method is not used
with custom providers, since custom provider icons do not appear in the New Provider
dialog box.
NdProvidesDefaultValue Interface
The NdProvidesDefaultValue interface defines the way for value providers to provide
the default values. Providers implement this interface if they are capable of providing a
meaningful default value for the type of value that they represent.
The provideDefaultValue() method returns a default value for the type of value
represented by this value provider. provideUniqueDefaultValues() returns a
sequence of unique default values for the type of value represented by this value
provider. If the provider cannot generate the number of values specified in the
numValues parameter, then it should return an array of smaller size that contains all of
the values that it was able to generate.
com.blazesoft.template.engine
public interface NdProvidesDefaultValue
{
public String provideDefaultValue(NdProviderContext context);
public String[] provideUniqueDefaultValues(NdProviderContext context, int numValues);
}
Two very simple custom providers are presented first. These custom providers
demonstrate some of the essential features of the Custom Provider API with minimal
code. The source code for the simple custom providers is not included in the custom
providers example folder.
// SimpleValueListProvider.java
public class SimpleValueListProvider extends NdDefaultConstrainedListProvider
{
public final static String PROVINCES_ABBREV[] =
{"AB", "BC", "MB", "NB", "NL", "NT", "NS", "NU", "ON", "PE", "QC", "SK", "YT"};
public SimpleValueListProvider()
{
}
public String[] getAllowedInstantiationValues(NdProviderContext context)
throws com.blazesoft.template.engine.NdTemplateException
{
return PROVINCES_ABBREV;
}
}
The list of allowed display values appears in the provider editor, as shown below.
The Innovator engine determines the list of display values which appear in a drop-
down list in an RMA by calling convertToDisplayValue() for every value in the array
returned by getInstantiationValues(). The default implementation of
convertToDisplayValue() in NdDefaultTemplateValueProvider returns the value
that is passed to it, so no conversion occurs. The display value is the same as the
instantiation value.
DisplayValuesProvider is the base class for the custom providers examples, which are
described in “Custom Providers Example” on page 33 of Examples.pdf.
DisplayValuesProvider is discussed in “The Example Base Class” on page 55.
public SimpleSRLAndDisplayListProvider()
{
}
protected String[] getInstantiationValues() throws NdTemplateException
{
instantiationValues = PROVINCES_ABBREV;
return instantiationValues;
}
protected String[] getDisplayedValues() throws NdTemplateException
{
displayValues = PROVINCES;
return displayValues;
}
public NdDesignProviderArg[] getArgumentDescriptors(NdProviderContext parm1)
throws com.blazesoft.template.engine.NdTemplateException
{
return new NdDesignProviderArg[0];
}
public String getDisplayName(NdProviderContext parm1)
throws com.blazesoft.template.engine.NdTemplateException
{
return "";
}
public String getDescription(NdProviderContext parm1)
throws com.blazesoft.template.engine.NdTemplateException
{
return "SRL and display value provider for list of Canadian provinces and
territories.";
}
public String getDisplayKey(NdProviderContext parm1)
throws com.blazesoft.template.engine.NdTemplateException
{
return "Custom Provider";
}
}
// from DisplayValuesProvider.java
public Object convertToDisplayValue(NdProviderContext context, String value)
throws NdTemplateException
{
String displayValue = "";
String[] displayedValues = getDisplayedValues();
String[] storedValues = getInstantiationValues();
if (displayedValues != null && storedValues != null) {
for (int index = 0; index < storedValues.length; index++) {
if (storedValues[index].equals(value)) {
displayValue = displayedValues[index];
break;
}
}
}
return displayValue;
}
Compare the code below with the image of the ConstantDisplayValuesProvider editor
in the previous section (“Customizing Provider Behavior Using Arguments” on page
51).
// from ConstantDisplayValuesProvider.java
public NdDesignProviderArg[] getArgumentDescriptors(NdProviderContext parm1)
throws com.blazesoft.template.engine.NdTemplateException
{
NdDesignProviderSelectableArg displayType = new NdDesignProviderSelectableArg("DisplayType");
displayType.setDisplayName("Display Value");
displayType.setDescription("Display the full name or abbreviation");
// displayType.setChoices(new String[] {"Full name", "Abbreviated name");
displayType.setChoices(new String[] {DISPLAY_TYPE_FULL, DISPLAY_TYPE_ABBREV});
displayType.setDisplayChoices(new String[] {DISPLAY_TYPE_FULL, DISPLAY_TYPE_ABBREV});
// displayType.setDefaultValue("Full name");
displayType.setDefaultValue(DISPLAY_TYPE_FULL);
displayType.setMandatory(true);
// from UserDefinedDisplayValuesProvider.java
public NdDesignProviderArg[] getArgumentDescriptors(NdProviderContext context)
throws NdTemplateException
{
NdDesignProviderTypedArg storedValue = new NdDesignProviderTypedArg("StoredValue");
storedValue.setDisplayName("Content Value");
storedValue.setDescription("SRL value generated during runtime");
storedValue.setType(NdTemplateManager.BUILTIN_STRING_PROVIDER);
storedValue.setDefaultValue("");
Processing Arguments
As mentioned above, the setArgs() method of a provider is called by the Innovator
engine. The setArgs() method is passed NdProviderStaticArg arguments which are
processed in the method.
// from ConstantDisplayValuesProvider.java
public void setArgs(NdProviderContext context, NdProviderStaticArg[] args)
throws NdTemplateException
{
if (args != null & args.length > 0) {
for (int index = 0; index < args.length; index++) {
if (args[index].getName().equals("DisplayType")) {
displayType = args[index].getValue();
}
else if (args[index].getName().equals("ListType")) {
listType = args[index].getValue();
}
}
}
}
// from ConstantDisplayValuesProvider.java
protected String[] getInstantiationValues()
throws NdTemplateException
{
if(listType.equals(LIST_TYPE_STATE)) {
initializationValues = STATES_ABBREV;
}
else if(listType.equals(LIST_TYPE_PROVINCE)) {
initializationValues = PROVINCES_ABBREV;
}
else {
String[] allowedValues = new String[STATES_ABBREV.length + PROVINCES_ABBREV.length];
System.arraycopy(STATES_ABBREV, 0, allowedValues, 0, STATES_ABBREV.length);
System.arraycopy(PROVINCES_ABBREV, 0, allowedValues, STATES_ABBREV.length,
PROVINCES_ABBREV.length);
initializationValues = allowedValues;
}
return initializationValues;
}
Providers that extend DisplayValuesProvider class must implement the two abstract
methods that are declared in the class, getInstantiationValues() and
getDisplayValues(). getInstantiationValues() returns a String array that
contains the allowed instantiation values. The provider’s content values are the same as
the instantiation values unless the provider overrides the default implementation of the
convertToContent() method, which ensures they are the same value. The
getDisplayValues() method returns a String array that contains the allowed display
values. The String arrays returned by getInstantiationValues() and
getDisplayValues() are constructed in parallel, such that for a given array index, a
valid instantiation value (again, this is also the content or SRL value) and the
corresponding valid RMA display value may be obtained.
Recall that it is the responsibility of a constrained list provider to define the valid
values. Each provider is free to obtain the values it provides in any fashion. The
example providers demonstrate different methods for obtaining value lists.The
StaticClassMethodProvider obtains values by calling static accessor methods on a
class that defines the appropriate String arrays as constants. The name of the class that
holds the values and the names of the appropriate accessor methods are specified when
setArgs() methods. Also those methods should not throw any runtime exception.
Any operation that is costly to compute or may fail should be done only as the
result of calling one of the other methods.
If some operation done by a custom provider class is very costly (for instance,
reading information from a database, or returning a list of SRL entities of a
particular type in the current project), then care must be taken to avoid doing the
same operation too many times. Caching information in a local, private, non-static
Hashtable field for instance is a common way to keep and re-use previous results if
those results do not change between invocations of the provider.
Even if results may change between invocations, you may still use caching
techniques, but you must also worry about invalidating the cache if part of it
becomes invalid. For instance, if you've read information from files that reside on
your file system and kept that information in some local cache, indexed by the file
location, you should invalidate the information associated with that file if you
detect that file has been modified (using the Last Modified attribute of the file for
instance to detect whether a file has changed).
For implementing caches, it's important to note that it is the same Custom Provider
class that is shared between all RMA sessions, so care must be taken if the
information is stored in a static field. It might be OK to use a static field for such
cached data, but only if the cached data is constant and can indeed be shared across
all sessions. Also the code that reads from or writes to that cache must be
synchronized to prevent multiple threads/sessions to access that data at the same
time in an uncoordinated fashion (thrashing).
If the cached data could grow to a large amount over time, you could add
additional techniques to partially release the memory kept by the oldest parts of
your cache, such as using weak references or weak hashmaps to keep references to
cached data.
In the particular case where the data being retrieved is stored in a database, you
should consider not only caching the data retrieved from that database but also
sharing or pooling of connections (to avoid having each session result into a new
database connection).
In the particular case where the data being retrieved comes from the current project
content, you should use the new NdPromProviderUtil.getPromProject() method
to retrieve the current NdPromProject, and from that get the list of directories, items,
and entities that are relevant to the provider (instead of using methods such as
NdTemplateManager.loadInstantiation()). The main benefits of using the new
PROM APIs are that they give a fully objectified view of what's in the current
project, as well as cache all necessary information.
The FICO™ Blaze Advisor® business rules management system RMA API is a high-
level API for developers building rule maintenance applications (RMAs). The API is
independent of the execution environment, so it is not limited to web-based
applications, but can be used to build RMAs in other environments including Java
Swing.
The RMA API is composed of the RMA Service API and the RMA Session API. The
RMA Service API includes interfaces which offer a means of connecting to a repository,
opening a project, finding relevant instances, editing instances, and saving those
instances in the repository. The purpose of the RMA Session API is to supplement the
RMA Service API by providing a state-holding interface while still not being tied to any
one client technology or execution environment.
Both methods accept a parameter which specifies the location of the project as an
absolute location from the root directory of the repository. The difference between the
two is that the parameter to the openProject(String projectFullDisplayPath)
method is a String path which is built with display names, as they appear in the
boolean isVersionControlled()
boolean isPrivateWorkspaceUsed()
boolean isConnected()
void disconnect()
Date getConnectionDate()
NdRepositoryConnection getRepositoryConnection()
NdRmaRepository also contains these utility methods for displaying dates and obtaining
the display Calendar.
The following methods are provided to support subproject navigation and multi-project
detection:
NdRmaSubProject[] getSubProjects()
boolean isMultiProject()
void refresh()
The getDirectories() method returns the directories which are imported by the
project and the project’s subprojects. getAllDirectories() returns the directories
imported by the project and the project’s subprojects, as well as all the subdirectories of
the project and its subprojects. Set the boolean includeSystemDirectories parameter of
the methods to true to include directories that are located in system directories and
their subdirectories. (Any Entry Exclusion or Entry Inclusion Filters which are defined
for the current project will restrict which directories are returned by these methods.) As
noted above, the list of directories is cached, so every time these methods are invoked
the same results are assured. To obtain accurate lists in the event the project directories
and subprojects in the repository change, call refresh() to reset the cached lists.
For convenience, specific methods are provided to obtain all the entries representing
templates, instances, query templates and query instances in the project. Set the boolean
includeSystemDirectories parameter of the methods to true to include templates that
are part of system directories and their subdirectories.
The getAllTemplates() method returns all the templates in the project, including Filter
and Query templates. getFilterTemplates() returns all the Filter templates in the
project. The output of this method is unaffected by any current inclusion filter.
getAllQueryTemplates() returns all the Query templates in the project.
getSearchQueryTemplates() returns all the Search Query templates in the project.
getComparisonQueryTemplates() returns all the Comparison Query templates in the
project. getVerificationQueryTemplates() returns all the Verification Query
templates in the project. getAllInstances() returns all the instances in the project.
getFilterInstances() returns all the Filter instances in the project. The output of this
method is unaffected by any current inclusion filter. getAllQueryInstances() returns
all the Query instances in the project. getSearchQueryInstances() returns all the
Search Query instances in the project. getComparisonQueryInstances() returns all the
Comparison Query instances in the project. getVerificationQueryInstances() returns
all the Verification Query instances in the project. The dispose() method releases the
project resources. Any subsequent attempt to use the disposed project will result in an
assert Exception
The methods described above return by default all the entries that are found when
traversing the directories imported by the project (aside from directories that are
explicitly excluded with an Exclusion Filter). However, a method of the project’s Filter
Manager, NdRmaEntryFilterManager.setEntryExclusionFilter(), allows client code
to provide an NdRmaEntryExclusionFilter to automatically filter out unwanted results
when these entry-collecting methods are used. Passing null to
setEntryExclusionFilter() will remove the filter and thus reset the behavior of those
methods to the default. See “RMA Entry Filter Manager (NdRmaEntryFilterManager)”
on page 79.
NdRmaEntryFilterManager getEntryFilterManager()
throw an exception if the absolute location belongs to a storage folder for sub-instances
stored-separately, or if it is not an absolute location, or if the project has been previously
disposed of. NdRmaEntry has a complementary method, getLocation(), which returns
the NdLocation corresponding to the entry. For a discussion on the distinction between
an absolute and relative NdLocation, see “Specifying a Location (NdLocation)” on page
15.
Errors that may occur when dealing with the project may be handled with the following
methods:
boolean hasErrors()
NdRMAException[] getErrors()
void clearErrors()
The hasErrors() method returns true if errors were found while performing any
operation on the project. getErrors() returns the errors that were found while
performing any operation on the project. clearErrors() clears the list of errors that
were kept since the last call to this method. Consider clearing the cached list of errors
prior to performing a discrete set of operations on the project, so that the successive calls
to hasErrors() and getErrors() reflect only the errors in the immediate set.
String getDisplayName()
String[] getDisplayPath()
NdLocation getLocation()
NdRmaDirectory getParentDirectory()
NdRmaProject getProject()
The getDisplayName() method returns the display name of the file as it appears in the
Builder IDE. getDisplayPath() returns the display path of the file, as an array of
String. Each element represents a node in the hierarchy. The hierarchy starts at the
project node. The last element in the array is the display name of the file. getLocation()
returns an NdLocation object that is the absolute location of the entry from the root of
the repository. getParentDirectory() returns the directory that contains the entry.
null is returned if the entry has no parent; which would be the case if, for example, the
entry were a project or one of the top-level project directories. Note that the
getDisplayPath(), getLocation(), and getParentDirectory() methods cannot be used
if the entry is a transient Query instance (one whose isTransient() method returns
true). An exception will be thrown in this case. getProject() returns the project the
entry belongs to.
The following methods are used to obtain the entry’s repository schema typing attribute
values, which are defined by the
com.blazesoft.templates.repository.NdRomSchemaConstants interface. See
“Repository Item Typing Attributes” on page 8.
int getType()
int getSubType()
int getContentType()
int getTarget()
The getType() method returns the NdRomSchemaConstants “type” value for this entry,
such as TYPE_SRL_ENUMERATION. getSubType() returns the “subType” value for this
entry, such as SUB_TYPE_NONE. getContentType() returns the “contentType” value for
this entry, such as CONTENT_TYPE_FIXED. The getTarget() method returns the “target”
value for this entry, such as TARGET_SRL.
NdRmaEntryVersioningInfo getVersioningInfo()
NdRmaEntryVersioningOperations getVersioningOperations()
boolean hasEntries()
NdRmaEntry[] getEntries()
void resetEntries()
NdRmaDirectory createDirectory(String directoryDisplayName)
void deleteEntry(NdRmaEntry entry)
rename(String name)
NdRmaGloballyDeletedFile[] getGloballyDeletedFiles()
void resetGloballyDeletedFiles()
boolean hasGloballyDeletedFiles()
The hasEntries() method returns true if the directory has any content. getEntries()
returns all the entries in the directory. The list of entries is cached. If any entry exclusion
filter was defined at the project level, then the result provided by these methods will
depend on the filter. Projects and subprojects will never be in the list of entries returned
by getEntries(). The reason is that directories are fetched in the context of some
project, and other projects that may be contained in those directories are invisible to the
root project. The resetEntries() method clears the cache of entries. This is useful so
that the next call to getEntries() returns an up-to-date list of entries. The
createDirectory() method creates a subdirectory of the specified name. The
deleteEntry() method deletes the supplied entry. rename(String name) renames the
directory. The new name must not contain any illegal characters and cannot be a
duplicate of another directory within the same parent directory.
getGloballyDeletedFiles() returns all the files in this directory that have been deleted
and then checked into the versioning system. resetGloballyDeletedFiles() clears the
cache of files that have been deleted then checked into the versioning system. The
hasGloballyDeletedFiles() method returns true if the directory has any file that has
been deleted then checked into the versioning system.
Versioning operations are not provided for a directory in the current release, even
though NdRmaDirectory extends NdRmaEntry, which supports versioning. However,
NdRmaDirectory does provide the following method for obtaining versioning
information for all the entries in a directory:
RMA Files
As described in “RMA Entry (NdRmaEntry)” on page 63, an entry in a repository is
either a project directory or a file in a project. Files are always contained by a directory,
with the exception of projects. The four types of files supported by the RMA API are
listed below. Each interface extends NdRmaFile.
project (NdRmaProject)
subproject (NdRmaSubProject)
template file (NdRmaTemplateFile)
instance file (NdRmaInstanceFile)
File (NdRmaFile)
The NdRmaFile interface provides the following methods.
Date getLastModifiedDate()
boolean isLogicallyDeleted()
boolean isNew()
void reloadContent()
NdRmaEntry getOriginalTipEntry()
NdRmaInstanceFile getRootInstanceFile()
String getSubInstancePath()
String getSubInstanceSectionName()
The getLastModifiedDate() method returns the date the file was last modified. To
obtain a display-friendly, localized String for that Date, call
NdRmaRepository.formatDateForDisplay(). The isLogicallyDeleted() method
returns true if the file has been logically deleted. A logically deleted file is one that is
either deleted locally in the workspace or deleted globally in the versioning system.
isNew() returns true if the file was just created and never saved. The reloadContent()
method reloads the content of the file and discards changes which have not been saved.
getOriginalTipEntry() returns the working copy, or “tip” entry file if the file is a
version of an entry, otherwise null is returned. getRootInstanceFile() returns the root
instance (parent) file if this entry represents the entry for a sub-instance stored-
separately. This method returns null if this entry does not represent an instance stored-
separately. The getSubInstancePath() method returns the path to the sub-instance
stored-separately within the instance contained by this file.
getSubInstanceSectionName() returns the section name of the sub-instance stored-
separately within the instance contained by this file. Both getSubInstancePath() and
getSubInstanceSectionName() are used by entries representing instances stored-
separately, so that with the root instance file, the sub-instance path, and sub-instance
section name it is possible to find the sub-instance linking to the instance stored-
separately.
Project (NdRmaProject)
Projects (NdRmaProject) and subprojects (NdRmaSubProject) are not included in the list
of entries returned by the getEntries() method of NdRmaDirectory (see “RMA
Directory (NdRmaDirectory)” on page 64). The reason is that directories are fetched in
the context of some project, and other projects that may be contained in those directories
are invisible to the root project which provides the context.
Subproject (NdRmaSubProject)
A subproject is simply a project contained by another project. NdRmaProject and
NdRmaSubProject extend NdRmaFile so that it can supply versioning information. This
extension also allows versioning operations to be performed on an NdRmaProject, like
any other entry. However, NdRmaSubProject objects are read-only; no operations are
allowed that can change its state. Versioning is not supported. To operate on a
subproject, open the subproject as a project using the NdRmaRepository.openProject()
method described in “RMA Project (NdRmaProject)” on page 60. Alternatively, obtain
To limit the ability to modify the subproject, the following methods inherited from
NdRmaFile are overridden:
NdRmaEntryVersioningOperations getVersioningOperations()
void reloadContent()
NdRmaTemplate getTemplate()
NdRmaFile saveAs(NdRmaDirectory targetDirectory, String name)
The getTemplate() method returns the template that this file contains. saveAs() saves a
copy of the file in the specified target directory. The copy that was created is returned.
The new name must not contain any illegal characters and cannot be a duplicate of
another file within the same directory.
NdRmaInstance getInstance()
The getInstance() method returns the instance that this file contains.
void save()
NdRmaFile saveAs(NdRmaDirectory targetDirectory, String name)
boolean isModified()
rename(String displayName)
boolean isStoredSeparately()
The save() method saves the file. If the file is read-only or is a transient Query instance,
this method will fail. The saveAs() method saves a copy of the file, with a new name, in
the specified target directory. The copy that is created is returned as an NdRmaFile. The
isModified() method returns true if the file has been modified. After the file is saved,
isModified() will return false. Saving a modified file with a new name using
saveAs() will result in isModified() returning true, since a copy will have been saved
and not the original file. The rename() method is used to rename the file. The file will be
marked as modified, and will not be saved.isStoredSeparately() returns the true if
this file is an instance that is currently stored separately.
NdRmaFile getFile()
The NdRmaFile getFile() method returns the file that contains the content.
The isTransient() method returns true if this template is in a transient state. When
NdRmaInstance.getTemplate() returns an NdRmaTemplate, it may need to return a
template in a “transient” state - meaning the template can only be used to test its
properties and to obtain the display name of the template. This is necessary when the
template has been excluded from the project and yet we still want to supply an
NdRmaTemplate from the instance's getTemplate() method. For example, the Standard
Business Query template has been excluded when generating the RMA, and yet we
want to still be able to group instances of that template under the template's display
name, even though a new instantiation of the template can not be made. (Excerpted
from the API Reference entry for the NdRmaTemplate interface.)
Versioning information regarding the template file may obtained through the
NdRmaFile object which is returned by calling getFile(). For the current release,
however, version operations are not supported for templates. Subprojects do not
implement versioning operations. See “Versioning” on page 75.
NdRmaInstance provides a method for obtaining the template for this instance:
NdRmaTemplate getTemplate()
The getTemplate() method returns the NdRmaTemplate entry that the instance was
generated from. If the project directory containing the template has been excluded or
filtered out, the NdRmaTemplate object returned will be in a transient state. That is, the
template’s isTransient() method will return true, and its getFile() and
generateInstance() methods will throw an exception. getTemplate() returns null if
the template could not be obtained due to a linking error.
This code shows how to obtain an instance by two methods. The first obtains the
instance specified by its absolute location from the repository root. The second obtains
the instance by iterating through all instances in the project to find its display name.
These methods help identify if the instance is one of a special type of instance:
boolean isFilterInstance()
boolean isQueryInstance()
When instances are loaded from the repository some linking errors may occur. This can
happen when the template of the instance might have changed, or might not exist
anymore. These errors are dealt with using the following NdRmaInstance methods:
boolean hasLinkingErrors()
NdRMAException[] getLinkingErrors()
void clearLinkingErrors()
boolean hasLinkingFixes()
NdInstantiationFix[] getLinkingFixes()
void fixLinkingErrors()
The hasLinkingErrors() method returns true if linking errors occurred while loading
the instance. getLinkingErrors() returns a list of the linking errors that may have
occurred while loading the instance. If no error occurred, an empty array is returned.
clearLinkingErrors() clears the list of linking errors. This is useful if
fixLinkingErrors() is not called and you wish to ignore the errors. hasLinkingFixes()
returns true if there are linking fixes available for the instance. getLinkingFixes()
returns an array of NdInstantiationFix objects which can provide information about
the linking fixes that exist on the instance and which can be fixed by calling
fixLinkingErrors(). If no fixes are needed an empty array is returned. Call the
fixLinkingErrors() method to automatically fix the linking issues if there are any. The
list of linking fixes is then cleared. Note that this method does not fix validation errors,
which are errors that may occur during the editing of the instance.
NdInstanceElementNode[] getInstanceElementNodes()
NdInstanceElementNode[] getInstanceElementNodes(NdInstanceElementNode node)
NdInstanceElementNode[] getInstanceElementNodesForTOC()
NdInstanceElementNode[] getInstanceElementNodesForTOC(NdInstanceElementNode node)
NdInstanceElementNode lookupInstanceElementNode(String instanceSectionName,
String nodePath, boolean resultForTOC)
path in the instance section of the supplied name. To lookup this node in the context of
a table of contents, set resultForTOC to true. See “Instance Element Node
(NdInstanceElementNode)” on page 74.
The addListValue() method adds the supplied display value to the supplied list node.
addListValueBefore() adds the supplied display value to the supplied list
immediately before the existing element targetNode. Editing errors may occur during
the execution of this method. addListValueAfter() adds the supplied display value to
the supplied list immediately after the existing element targetNode. Editing errors may
occur during the execution of this method.
The addListValueXXX() methods described above add only String values. In contrast,
the following addListInstanceXXX() methods are used to add instances of templates to
the supplied list.
The position of existing nodes within their containing lists may be changed using the
following methods:
The moveListNodesBefore() method moves the nodes before the targetNode in their
containing list (i.e. each of the nodes’ index in the list will be less than the targetNodes'
index with the final node from nodes having an index that is 1 less than the targetNodes'
index. The relative position of each node in nodes will be maintained. The
moveListNodesAfter() method moves the nodes after the targetNode in their
containing list (i.e. each of the nodes’ index in the list will be greater than the
targetNodes' index with the first node from nodes having an index that is 1 greater than
the targetNodes' index. The relative position of each node in nodes will be maintained.
Editing Errors
Editing errors may occur during the execution of any of the methods described in the
previous section (“Editing the Contents of an Instance” on page 71). An editing error
will occur, for example, when an incorrect template display name is supplied to the
addListInstance(NdInstanceElementNode list, String templateDisplayName)
method. The errors may be obtained with the following NdRmaInstance methods.
boolean hasEditingErrors()
boolean hasEditingError(NdInstanceElementNode node)
NdRmaException getEditingError(NdInstanceElementNode node)
NdRmaException getEditingError(String nodePath)
String[] getPathsOfNodesWithEditingErrors()
void clearEditingErrors()
The hasEditingErrors() method returns true if the editing of this instance generated
errors. hasEditingError(NdInstanceElementNode node) returns true if the editing of
this instance generated an error caused by the provided node.
getEditingError(NdInstanceElementNode node) returns the editing error that may
have occurred by calling one of the editing methods on the supplied node. If no error
occurred, null is returned. getEditingError(String nodePath) returns the editing
error that may have occurred by calling an editing method for the node located by the
supplied node path. If no error occurred, null is returned.
getPathsOfNodesWithEditingErrors() returns an array of nodePaths for the nodes that
currently have editing errors. If no nodes have an error then an empty array is returned.
clearEditingErrors() clears all the editing errors that may have occurred.
Validation Errors
When changes are made to an instance, those changes need to be validated in order to
verify that the instance conforms to the constraints put in place by the template. The
following NdRmaInstance methods are related to validation.
void validate()
void validate(NdInstanceElementNode)
boolean hasValidationErrors()
boolean hasValidationError(NdInstanceElementNode node)
NdRMAException getValidationError(NdInstanceElementNode node)
NdRMAException getValidationError(String nodePath)
NdRMAException[] getNodeValidationErrors()
String[] getPathsOfNodesWithValidationErrors()
NdRMAException[] getOtherValidationErrors()
void clearValidationErrors()
Begin validation by calling one of the validate() methods. This will generate a list of
validation errors in cache. You may want to call the clearValidationErrors() method
before calling validate() in order to clear any existing list.
The validate() method tries to validate this instance. A variant of validate() takes an
NdInstanceElementNode as a parameter to only validate that node, and its sub-nodes,
and not the whole instance. hasValidationErrors() returns true if the validation of
this instance generated validation errors. hasValidationError(NdInstanceElementNode
node) returns true if the validation of this instance generated an error caused by the
provided node. getValidationError(NdInstanceElementNode node) and
getValidationError(String nodePath) return the validation error that occurred on
the supplied node. If no error occurred on that node, either method returns null.
getNodeValidationErrors() returns the node-specific validation errors that occurred
on the instance. If no node-specific errors occurred on the instance, this method returns
an empty array. getPathsOfNodesWithValidationErrors() returns an array of
nodePaths for the nodes that currently have validation errors that occurred on the
instance. If no node-specific errors occurred on the instance, this method returns an
empty array. getOtherValidationErrors() returns the validation errors for which
there is no associated node. If no such error occurred, this method returns an empty
array. The clearValidationErrors() method clears the list of editing errors.
NdRmaInstance getInstance()
The getInstance() method returns the root instance this node belongs to.
Versioning
The RMA Service API supports versioning of repository entries through two interfaces,
NdRmaEntryVersioningOperations and NdRmaEntryVersioningInfo.
Versioning Operations
(NdRmaEntryVersioningOperations)
The NdRmaEntryVersioningOperations interface declares the following methods:
void update()
void checkOut()
void cancelCheckOut()
void checkIn(String comment)
NdRmaEntry getVersion(String versionId)
void promote()
void restore()
The update() method updates the entry by fetching the latest version from the
versioning system. checkOut() checks out the entry from the versioning system.
cancelCheckOut() cancels a previous check out from the versioning system. checkIn()
checks the entry into the versioning system with the supplied comment. getVersion()
returns a version of the entry that corresponds to the supplied version ID. promote()
promotes the entry in the versioning system so that it becomes the top version.
restore() restores the entry that was previously deleted.
NdRepositoryVersionHistory[] getVersioningHistory()
NdRepositoryEntryLockInfo getVersioningLockInfo()
NdRepositoryVersionResultSet getVersioningStatusInfo()
The versioning status and lock information for all entries in a directory can be obtained
quite efficiently using the getVersioningInfos() method of the NdRmaDirectory
interface which returns an instance of NdRmaDirectoryVersioningInfos. Versioning
operations are not available for the directory itself in the current release. A list of
directories in a project can be obtained by calling NdRmaProject.getDirectories(). See
“RMA Project (NdRmaProject)” on page 60.
NdRepositoryEntryLockInfo[] getVersioningLockInfos()
NdRepositoryVersionResultSet[] getVersioningStatusInfos()
The getVersioningLockInfos() method returns the versioning lock information for all
the entries in this directory. getVersioningStatusInfos() returns an array of
NdRepositoryVersionResultSet which defines the result set returned by the invocation
of methods in the repository version manager interface.
RMA Queries
The RMA Service API supports the execution of existing queries at the project level.
Query results are returned as an array of NdRmaQueryResultItem. Query results can be
instances as well as the contents of instances.
void executeQuery()
void executeQueryAsynchronously()
void executeQueryForTOC()
void executeQueryAsynchronouslyForTOC()
int getQueryExecutionStatus()
boolean hasQueryResults()
NdRmaQueryResultItem[] getQueryResults()
void stopQueryExecution()
The executeQuery() and executeQueryForTOC() methods execute the query. The later
method accumulates only the results that are relevant for a table of contents. Both
methods execute the query synchronously. This means that the thread in which the
method is invoked waits until execution is complete. The corresponding
executeQueryAsynchronously() and executeQueryAsynchronouslyForTOC() methods
execute the query asynchonously. This means that the thread in which this method is
invoked will not wait until its execution is completed, but the query status will be
updated as the execution progresses. An entry exclusion filter can be set on the project
to filter query results. The getQueryExecutionStatus() method returns the status of the
query execution. The status can be one of: EXEC_STATUS_NOT_STARTED,
EXEC_STATUS_COMPLETE, EXEC_STATUS_EXECUTING, EXEC_STATUS_CANCELLED, or
EXEC_STATUS_ABORTED. The hasQueryResults() method returns true if the execution of
the query delivered results. getQueryResults() returns the results of the query
execution as an array of NdRmaQueryResultItem. The stopQueryExecution() method
stops the execution of this query. This is only applicable to asynchronously executed
queries.
Errors that may occur when executing queries may be obtained with the following
methods:
boolean hasQueryExecutionErrors()
NdRMAException[] getQueryExecutionErrors()
void clearQueryExecutionErrors()
These methods identify which special subtype of Query instance this Query instance is:
boolean isComparisonQueryInstance()
boolean isSearchQueryInstance()
boolean isVerificationQueryInstance()
boolean isTransient()
This method allows the transient Query instance to be deleted. It cannot be deleted in
the way a regular instance can be because that requires knowing the parent directory:
void deleteTransientQueryInstance()
An inclusion filter will leave the item in question unfiltered if it does match the
condition for inclusion.
A second type of inclusion filter exists for RMA projects. From the Blaze Advisor IDE, a
filter can be applied to the PROM Project. That filter exists as a PROM project property.
When an RMA project object is created, the RMA Entry Filter Manager is created and
automatically applies the existing PROM project inclusion filter (if any). This filter
cannot be set or removed by using the RMA Service APIs. When filtering has been
applied, items that have been created new or have been modified will not be excluded
due to the filtering.
true even when there is only an automatically applied, IDE-set, PROM project inclusion
filter.
Only one custom exclusion filter may be set on a project at a time. Use the
setEntryExclusionFilter(RmaEntryExcludedPathsFilter filter) method of
NdRmaEntryFilterManager to set the filter. One may, of course, switch to another filter
by calling the method again. Pass null to the method to indicate that no filtering should
be performed. Obtain an instance of NdRmaEntryFilterManager with the
getEntryFilterManager() method of NdRmaProject. Use the
getEntryExclusionFilter() method of NdRmaEntryFilterManager to obtain the
current NdRmaEntryExclusionFilter. See “RMA Entry Filter Manager
(NdRmaEntryFilterManager)” on page 79.
The sample client code below passes a Vector of excluded paths to the constructor of
the filter class. It sets the project filter by passing the filter to
setEntryExclusionFilter(). The call to getAllQueryInstances() returns all query
instances available to the project, except those in the /Business Library/Asia and
/Business Library/Europe directories and their subdirectories.
// rmaProject is an NdRmaProject
Vector excludedPaths = new Vector();
excludedPaths.addElement("/Business Library/Asia");
excludedPaths.addElement("/Business Library/Europe");
RmaEntryExcludedPathsFilter myFilter = new RmaEntryExcludedPathsFilter(excludedPaths);
NdRmaEntryFilterManager filterManager = rmaProject.getEntryFilterManager();
filterManager.setEntryExclusionFilter(myFilter);
NdRmaQueryInstance[] queries = rmaProject.getAllQueryInstances(true);
During a user's application session, there are two types of information which are
needed and/or modified by both the application layer (the RMA Service API), and the
presentation medium (the application's user interface). Some of that information is
static for the duration of the session, such as the current project; and some of it changes
frequently with each change to the user interface view. The RMA Session API supports
both types of information and is an interface between the application and presentation
levels.
The RMA Session API defines the methods for keeping necessary state information in a
Java class. The Java class can then be kept in a web session variable for web clients, or
used directly by a fat client. Having all the state information gathered, organized, and
supported by this API enables all the items required to maintain state to be held in a
single NdRmaSession session object (see “RMA Session (NdRmaSession)” on page 82).
When a state-inducing action is performed on behalf of an RMA user, the RMA Session
API can enable the retention and use of that state information for the life of the user's
session. Additionally, the API provides a facility for client RMA applications to supply
a set of properties, defined by the RMA developer, which can be saved as part of the
session state information (see “RMA Session Properties (NdRmaSessionProperties)” on
page 84). Also, to enable recovery from application errors, there are commands for
capturing a backup of the state information so that, if needed, another provided
command can restore the session state to its last-cached configuration.
Often, there is a need to display only one View area, such as when a list of the project’s
files and directories is being displayed. At other times the user may choose to have
more than one View open simultaneously, such as when editing an instance in one
View and comparing it to a version of that instance in a second View.
Different Views have different requirements. Sometimes a View will be a single pane
such as when a sign-in or login page is displayed. Other times a View is more complex,
such as the View of an Instance editor. That View can even have other sub-areas that are
dependent upon the state of the main area such as a “Table of Contents,” a context-
sensitive command bar, or a navigation mechanism that reflects the item in the View’s
location. The actual design and needs of an application’s Views will vary from one
RMA design implementation to the next.
Where the state information may be specific to a custom RMA, the design may be
organized into a class where the class name is pre-defined (NdRmaSessionProperties),
but the definition of the class is decided by the developer of the RMA. See “RMA
Session Properties (NdRmaSessionProperties)” on page 84.
The NdRmaSession interface defines methods for accessing the session properties object
defined by the RMA developer. Other methods are provided to open a View or an
array of views, close a single View or close all open Views, and to retrieve a particular
open View or an array of all open Views, etc.
“Opening a View” is simply the act of handing the View object, which was
independently created in other server-side code, to the RMA Session API so that it can
keep it as state information.
To assist in error recovery, the RMA Session API provides the captureRecoveryState()
method to take a snapshot of the NdRmaSession object, and the
restoreRecoveryState() method to replace the current state with the most recently
captured state.
The setRepository() method saves the provided RMA repository entry as the
repository for the session. setProject() saves the provided RMA project entry as the
project for the session. getSessionProperties() retrieves the client-defined
NdRmaSessionProperties object. openView() saves the provided, client-obtained view
(NdRmaView) object, thus establishing an open view in this session state object. If an open
view with the same viewId value as this view exists, it is replaced with this view object.
The relative order of the open views is maintained. openViews() saves the supplied
array of client-obtained view (NdRmaView) objects thus establishing them as open views
in this session state object. If an existing open view with the same viewId value as one
of these views in the provided array already exists, it is replaced with the new view
object. Note that the relative order of open views is maintained. hasAnyView() returns
true if any view is currently open for this session. The getView() method retrieves the
view object identified by the given viewId.
getAllViews() retrieves an array of all currently opened view objects within this
session. The relative order of open views is maintained. That is, if View ʺaʺ is opened,
and then View ʺbʺ and View ʺcʺ are opened, then the array returned is: views[0] ==
View ʺaʺ, views[1] == View ʺbʺ, and views[2] == View ʺcʺ. If View ʺbʺ is closed, then
the array returned is: views[0] == View ʺaʺ and views[1] == View ʺcʺ.
The closeView() method closes the view identified by the given viewId. If the view is a
child view then the child is closed and the child's parent will, once again, be open and
own the same viewId. closeAllViews() closes all currently opened view objects
identified by the given viewId. That is, a family of views will be closed if the viewId
points to either a parent or a child. closeAllViews() closes all currently opened view
objects within this session. captureRecoveryState() saves the current state of this
session. This method is called by clients of the RMA Session API in order to preserve
the current state. A client might use this method prior to handling any new requested
action caused by an RMA user so that if the action caused an error, then the error page
could offer a recovery (“back”) link to a state that did not cause an exception.
restoreRecoveryState() replaces all current state with the state that was most-recently
saved. The cloneSession() method returns a new NdRmaSession with all session-level
objects and properties copied from this session to the new session object. No view-level
information is copied to the new session.
The RMA Service API defines the NdRmaEntry interface, which represents the main
“visual” component, if you will, of an RMA such as a project, a directory, or an instance.
An RMA View (NdRmaView) presents one of those NdRmaEntry objects as a View in the
RMA. There can be more than one representation of NdRmaEntry object in the same
RMA. For example, one View of an instance could be represented as the instance being
edited. Another View of that same object might be represented as the instance being
saved as a new instance in the “Save As" pane, or as the object whose version history is
being displayed in the “History" pane.
A View may not be representing object at all, such as when the “Sign In” dialog, which
gathers user information prior to establishing a repository connection, is being
displayed. That is still a View.
A View can represent just a single pane, or page, such as a web page; and it can
represent an NdRmaEntry object where that object is being presented in a particular
context such as in its editor or in its History viewer. The RMA Session API’s NdRmaView
interface names these parts of the View. String viewerName is the name of the viewer
for this View. It names the means by which the View is rendered. In web enviroment
that is the web page name. NdRmaEntry viewEntry is the NdRmaEntry object that is the
subject of the View (it may be null).
Note that an NdRmaEntry object can access both the project and the repository objects.
That is useful because at any time, while a View is open, those objects are available to
display information about themselves. When a View does not have a viewEntry there is
also no project or repository available such as when the View is of the “Sign In” page.
The NdRmaView interface provides set and access methods for the NdRmaEntry object in
the view, as well for the name of the viewer/renderer. A refresh method is provided to
refresh the underlying ROM/PROM object that is the represented by the viewEntry. The
refresh applies only to Views holding NdRmaEntry objects (not null). It will update that
object from the repository and additionally, it will refresh any other open View.
Because a user may wish to have multiple Views open simultaneously, the NdRmaView
constructor creates, and caches as part of the View, a string ID that is guaranteed to be
unique throughout the lifetime of the current session. An accessor method provides the
viewId. The value of the viewId is not important to the RMA, it is just a differentiator
and a means to refer to and access a particular View.
There are times when an RMA design may call for creating a View that is a copy of an
existing View, such as the RMA “Split View” command. To support this need,
NdRmaView provides the cloneView() method which returns a new NdRmaEntry object
with identical data except it has its own, unique viewId.
There are times when one may wish to create a View that spawns from, and replaces,
the current View without losing the original View; such as when an instance is being
edited and the user wants to navigate to a sub-instance (rule) where that rule is stored
(versioned) separately from the parent instance. One may wish to close the child View
and be able to view the parent at a later time, in the same state it had been when the
child was first open. To support this, the cloneChildView() method which creates a
clone of the current View, as does the cloneView method with a few exceptions. The
cloned child View uses the same viewId as its parent, it caches the parent view, and the
child does not inherit the parent’s errors. Its Exceptions array is always initially empty.
When a View is created in this manner, the boolean method isChildView() returns
true, otherwise it returns false. The getParentView() method returns the parent View,
or null if isChildView() returns false.
NdRmaSession getSession()
NdRmaViewProperties getViewProperties()
String getViewId()
void setViewEntry(NdRmaEntry viewEntry)
NdRmaEntry getViewEntry()
void setViewNodePath(String viewNodePath)
String getViewNodePath()
void setViewInstanceSectionName(String viewInstanceSectionName)
String getViewInstanceSectionName()
void setViewerName(String viewerName)
String getViewerName()
NdRmaView cloneView()
NdRmaView cloneChildView()
NdRmaView getParentView()
boolean isChildView()
void resetProperties()
void refresh()
void addException(NdRMAException exception)
void addExceptions(NdRMAException[] exception)
boolean hasException()
NdRMAException[] getExceptions()
void clearExceptions()
The getSession() method returns the session object that this View belongs to.
getViewProperties() retrieves the client-defined NdRmaViewProperties object.
getViewId() returns the auto-generated, session-unique identifier assigned to this
NdRmaView object when it was created. setViewEntry() sets the NdRmaEntry object which
this View will be representing (may be null). getViewEntry() returns the NdRmaEntry
object which this View is currently representing. The method returns null if no
viewEntry has been set.
setViewNodePath() sets the path to the current sub-instance node belonging to the
current viewEntry where the sub-instance is not one that is stored-separately. This
value should be set to null when the View is not for a sub-instance. getViewNodePath()
returns the nodePath to the current sub-instance which is not stored-separately. The
nodePath value should be null when the View is not currently of a sub-instance.
setViewNodePath() sets the path to the current sub-instance node belonging to the
current viewEntry where the sub-instance is not one that is stored-separately. This
value should be set to null when the View is not for a sub-instance. getViewNodePath()
returns the nodePath to the current sub-instance which is not stored-separately. The
nodePath value should be null when the View is not currently of a sub-instance.
setViewInstanceSectionName() sets the instance section name for the current sub-
instance node belonging to the current viewEntry where the sub-instance is not one that
is stored-separately. This value must be one of the
NdAbstractInstanceNode.INSTANCE_SECTION_XXX values; or null when the View is not
for a sub-instance. getViewInstanceSectionName() returns the instanceSectionName
These methods simply allow the properties to be saved along with the other current
stateful information and will never be accessed by the RMA View API.
The FICO™ Blaze Advisor® business rules management system base repository and
version management interfaces and APIs support:
Implementing a custom repository storage layer that Blaze Advisor can make use.
These interfaces are referred to as the base repository interfaces.
Implementing an interface to a third party content management system that
Blaze Advisor can make use of. These interfaces are referred to as the version
management interfaces.
These APIs are used to implement the repository, and are separate from the APIs used
by clients of the repository. They clearly define the semantics of repository and version
management operations so that all implementations behave in the same way.
You should not need to implement the workspace interfaces for a custom repository.
Blaze Advisor includes complete implementations that it uses for these operations.
The workspace interfaces are extensions of the storage layer interfaces that include
versioning operations. They delegate to whatever version manager has been configured
on the repository.
It should be noted that the workspace version manager is responsible for the versioning
of repository entries and their associated repository entry attributes, which implies that
the versioning system needs to know how repository entry attributes are represented in
the storage layer. For example, in the file repository that is supplied with Advisor an
entry's attributes are stored in a file that is in the same directory and that has the file
extension .innovator_attbs.
NdWorkspaceVersionManager
NdWorkspaceVersionManagerListener
Whenever a workspace version manager causes a modification to be made to the
workspace, it is responsible for sending an event to any listeners that have
registered interest in such changes. Typically, the only such listener would be the
workspace itself. This allows implementations of the workspace version manager to
inform the workspace that it needs to synchronize itself with the current state of the
repository as reflected in the storage layer.
NdWorkspaceVersionManagerEvent
This event is sent whenever the workspace version manager causes a change to be
made to the representation of a repository entry in the storage layer. The event
object contains two items of information:
The location of the repository entry that was affected.
An integer code indicating if the repository entry was modified, added to or
removed from the storage layer.
Administration Interfaces
There are two administration interfaces, one associated with the storage layer and the
other associated with the versioning system. They are separated out from the other
interfaces so as not to confuse the roles of software that accesses the storage layer or
versioning system from the workspace layer versus software that needs to perform
administrative functions on a workspace.
NdRepositoryAdmin
NdRepositoryVersionSystemAdmin
Repository Connections
Connections are made to a repository via an NdRepositoryConnection instance. During
the process of establishing a connection to a repository, the repository configuration
will be loaded from persistent storage in the repository, and will be used to configure
the repository and any versioning system.
Repository Configurations
Repository configurations are serialized into an XML document that is stored at a well-
known location within the repository. Instances of the repository configuration class are
created from the contents of this XML document via the Blaze dynamic object model.
For example, the portion of the repository configuration that specifies the repository
connection will appear as follows:
<RepositoryConfig>
…
<RepositoryConnection>
<Factory>com.blazesoft.repository.file.NdFileRepositoryConnection</Factory>
<RepositoryName>MyRep</RepositoryName>
<RepositoryFolder>c:\xyz\MyRep</RepositoryFolder>
…
</RepositoryConnection>
…
</RepositoryConfig>
B score model 37
Entity Object Model 12
BOM 27 entry exclusion filter 80
BOM Admin APIs
manipulating imported external
classes 27 I
BOM manipulation APIs 27 imported external classes
manipulating
C programmatically 27
connecting to repository 7
ConstantDisplayValuesProvider 51,
L
56 loading a PROM project 18
content-based API 12
create M
custom provider 47
decision table 32 Metaphor APIs
creating a model 31
decision tree 34
enumeration 24 loading an instance 31
Metaphor Model 31
NdLocation 8 N
NdPromItem 9 NdConstrainedListProvider 45
NdRomDirectory 16 NdContrainedListProvider 49
PROM project 17 NdDecTableModelFactory 32
question set 22 NdDecTreeModelFactory 32
ruleflow 22 NdDecTreeNodeRenderingInfo 36
score model 37 NdDecTreePath 34
SRL class 23 NdDefaultConstrainedListProvider
SRL function 21 46
SRL ruleset 18 NdDefaultTemplateValueProvider
custom provider 45
caching 57 NdDesignProvider 46
creating 47 NdDesignProviderMultiArg 53
implementation guidelines 56 NdDesignProviderSelectableArg 52
NdDesignProviderTypedArg 53
D NdLocation 8
NdMetaphorModelException 32
decision tables NdPromEntity 11
editing 32 NdPromInstance 12
decision trees NdPromItemContent 11
editing 36 NdPromProject 9, 57
DisplayValuesProvider 49, 55 NdPromProvider 12
NdPromSrlRuleContent 13
E NdPromSrlRuleset 13
edit NdPromTemplate 12
decision table 32 NdPromTextContent 12
decision tree 34 NdProviderStaticArg 54
NdProvidesDefaultValue 47
NdRmaEntryExclusionFilter 80
NdRmaQueryInstance 77
NdRmaQueryResultItem 78
NdRomConnectionContext 8
NdRomConnectionManager 7
NdRomSchemaManager 9
NdScoreModelModelFactory 32
NdTemplateValueProvider 44
P
performance
custom providers 56
Project Repository Object Model
(PROM) 9
PROM item content 11
PROM task
create enumeration 24
create question set 22
create ruleflow 22
create SRL class 23
create SRL function 21
create SRL ruleset 18
creating a PROM Project 17
loading a PROM project 18
release project resources 18
Q
Question Set Object Model 15
R
release PROM project resources 18
repository item
find location 8
typing attributes 8
Repository Object Model (ROM) 7
RMA query 77
Ruleflow Object Model 15
S
score models
editing with API 37
SRL Entity Object Model 14
string-based API 12
T
typing attributes of repository item 8
U
UserDefinedDisplayValuesProvider 53