IBM WebSphere Business Integration Adapters
Adapter for Clarify CRM User Guide
Adapter Version 4.5.x
IBM WebSphere Business Integration Adapters
Adapter for Clarify CRM User Guide
Adapter Version 4.5.x
Note!
Before using this information and the product it supports, read the information in “Notices” on page 95.
14March2003
This edition of this document applies to connector version 4.5.x and to all subsequent releases and modifications until otherwise indicated in new editions.
To send us your comments about this document, email [email protected]. We look forward to hearing from you.
Integration broker compatibility
Supported on IBM WebSphere Business Integration Adapter Framework version 2.2.0, IBM WebSphere InterChange Server versions 4.1.1 and 4.2 (if the
environment uses ISO Latin-1 data only), WebSphere MQ Integrator version 2.1.0, and WebSphere MQ Integrator Broker, version 2.1.0. See Release Notes for any exceptions.
Contents
Integration broker compatibility . . . iii
About this document
. . . vii
Audience . . . vii
Related documents . . . vii
Typographic conventions . . . vii
New in this release. . . ix
New in release 4.5.x. . . ix
New in release 4.4.x. . . ix
New in release 4.3.x. . . ix
Chapter 1. Overview of the connector . . . 1
The connector for Clarify CRM . . . 1
How the connector works . . . 2
Chapter 2. Installing and configuring the connector . . . 7
Prerequisites . . . 7
Installing the connector . . . 8
Enabling the Clarify CRM application for the connector . . . 10
Configuring the connector . . . 15
Starting and stopping the connector . . . 18
Chapter 3. Developing business objects for the connector . . . 19
Meta-data-driven connector design . . . 19
Business object structure . . . 20
Business object attribute properties . . . 22
Attribute and database types . . . 26
Business object application-specific text . . . 27
Chapter 4. Troubleshooting . . . 47
Start-up problems . . . 47
Event processing . . . 47
Verifying DB_NAME during startup . . . 47
Mapping (ICS Integration Broker only) . . . 47
Problems with date in business objects (ICS Integration Broker only) . . . 47
Problems with business objects named Clarify_Site . . . 47
Combining preprocessing and use of relationship. . . 48
Loss of connection to the application . . . 48
Appendix A. Standard configuration properties for connectors
. . . 49
New and deleted properties . . . 49
Configuring Standard Connector Properties for WebSphere InterChange Server. . . 50
Configuring Standard Connector Properties for WebSphere MQ Integrator . . . 62
Appendix B. Connector Configurator . . . 71
Using Connector Configurator in an internationalized environment. . . 71
Starting Connector Configurator . . . 72
Choosing your broker . . . 73
Using a connector-specific property template . . . 74
Using Connector Configurator with ICS as the broker . . . 77
Setting the configuration file properties (ICS) . . . 79
Setting the configuration file properties (WebSphere MQ Integrator Broker) . . . 84
Using standard and connector-specific properties with Connector Configurator. . . 87
Completing the configuration . . . 88
Appendix C. Connector feature list
. . . 89
Business object request handling features . . . 89
Event notification features . . . 90
General features . . . 92
Notices
. . . 95
Programming interface information . . . 96
About this document
IBM(R) WebSphere(R) Business Integration Adapters supply integration connectivity for leading e-business technologies and enterprise applications. This document describes the installation, configuration, and business object development for the adapter for Clarify CRM.
Audience
This document is for WebSphere Business Integration Adapter consultants and customers. Users of this document should be familiar with the WebSphere Business Integration Adapter system, with business object and collaboration development, and with the Clarify CRM application.
Related documents
The WebSphere business integration system documentation describes the features and components common to all installations, and includes reference material on specific collaborations and connectors.
This document contains many references to two other documents: the System
Installation Guide for Windows or for UNIX and the System Implementation Guide for WebSphere InterChange Server. If you choose to print this document, you may want
to print these documents as well.
To access the documentation, go to the directory where you installed the product and open the documentation subdirectory. If a welcome.html file is present, open it for hyperlinked access to all documentation. If no documentation is present, you can install it or read it directly online at one of the following sites:
v If you are using WebSphere MQ Integrator Broker as your integration broker: http://www.ibm.com/websphere/integration/wbiadapters/infocenter v If you are using InterChange Server as your integration broker:
http://www.ibm.com/websphere/integration/wicserver/infocenter
The documentation set consists primarily of Portable Document Format (PDF) files, with some additional files in HTML format. To read it, you need an HTML
browser such as Netscape Navigator or Internet Explorer, and Adobe Acrobat Reader 4.0.5 or higher. For the latest version of Adobe Acrobat Reader for your platform, go to the Adobe website (www.adobe.com).
Typographic conventions
This document uses the following conventions:
courier font Indicates a literal value, such as a command name, file name, information that you type, or information that the system prints on the screen.
bold Indicates a new term the first time that it appears.
italic, italic Indicates a variable name or a cross-reference.
blue text Blue text, which is visible only when you view the manual online, indicates a cross-reference hyperlink. Click any blue text to jump to the object of the reference.
ProductDir Product family is WBIA: Represents the directory where the IBM WebSphere Business Integration Adapters product is installed. The CROSSWORLDS environment variable contains the ProductDir directory path, which is IBM\WebSphereAdapters by default.
New in this release
New in release 4.5.x
Updated in March, 2003. The “CrossWorlds” name is no longer used to describe an entire system or to modify the names of components or tools, which are otherwise mostly the same as before. For example “CrossWorlds System Manager” is now “System Manager,” and “CrossWorlds InterChange Server” is now “WebSphere InterChange Server.”
The IBM WebSphere Business Integration Adapter for Clarify CRM is being released with the same functionality as in previous releases.
New in release 4.4.x
The IBM WebSphere Business Integration Adapter for Clarify CRM is being released with the same functionality as in previous releases.
New in release 4.3.x
The IBM WebSphere Business Integration Adapter for Clarify CRM includes the connector for Clarify CRM. This adapter supports two integration brokers: InterChange Server (ICS) and WebSphere MQIntegrator. An integration broker is an application that performs integration of heterogeneous sets of applications; it provides services such as data routing.
The IBM WebSphere Business Integration Adapter for Clarify CRM includes the following:
v An application component specific to Clarify CRM
v A sample business object (located in the \connectors\Clarify\Samples directory) v IBM WebSphere Adapter Framework, which consists of the following:
– Connector Framework
– Development tools (including Business Object Designer and Connector Configurator)
– APIs (including ODK, JCDK, and CDK)
This manual provides information about using the adapter with both the ICS and WebSphere MQIntegrator integration brokers.
Important: Because the connector has not been internationalized, do not run it against InterChange Server version 4.1.1 if you cannot guarantee that only ISO Latin-1 data will be processed.
Chapter 1. Overview of the connector
Connectors consist of two parts: the connector framework and the
application-specific component. The connector framework, whose code is common to all connectors, acts as an intermediary between the integration broker and the application-specific component. The application-specific component contains code tailored to a particular application or technology (in this case, Clarify CRM). The connector framework provides the following services between the integration broker and the application-specific component:
v Receives and sends business objects
v Manages the exchange of startup and administrative messages
For more information about the relationship of the integration broker to the connector, see the IBM WebSphere InterChange Server System Administration Guide or the IBM WebSphere Business Integration Implementation Guide for WebSphere MQ
Integrator Broker.
This chapter describes the connector component of the IBM WebSphere Business Integration Adapter for Clarify CRM. Note that this document contains information about both the connector framework and the application-specific component. It refers to both of these as the connector. It contains the following sections: v “The connector for Clarify CRM”
v “How the connector works” on page 2
The connector for Clarify CRM
The adapter for Clarify CRM allows the integration broker to exchange business objects with Clarify 8.0, 8.5, 9.0, 10.0 (version 10 is only available on UNIX), 10.1, 10.2, 11.1, and 11.2 applications. The connector supports Clarify eFrontOffice 8.0 (CeFO8) and Clarify eFrontOffice 9.0 (CeFO9) on Microsoft SQL Server or Oracle. The connector implements business object handling, event polling, and event notification. The application-specific component of the connector generates
business objects that it sends to the integration broker; it also responds to business object requests from the integration broker. It generates logging and tracing messages that it writes to a file or the connector console, or sends to the integration broker.
Along with event notification and business object request processing, the connector allows you to specify the following functionality:
v Specify the type of transactionality for a business object. The connector can wrap an entire business object request in a single transaction, and if a failure is
detected during the transaction, the entire transaction is rolled back. Alternately, for hierarchical business objects, the connector can commit changes to each child object as a set of incremental transactions. This ensures that child business objects are processed in the intended order.
v Specify that the connector preprocess an attribute to obtain its value before executing a business object request.
v Specify whether a connector responds to a Retrieve request by retrieving the business object’s entire hierarchy (a deep retrieve) or by retrieving only the top-level business object (a shallow retrieve).
v Specify whether a Retrieve operation succeeds for a hierarchical business object if one or more child objects are missing.
v Perform a Retrieve operation based on the keys of a record or based on non-key values. A retrieve using non-key values is also called RetrieveByContent. A RetrieveBy Content operation can use one or more designated attributes to query for a record.
v Specify how a Clarify CRM ID is created on a Create operation. A connector property can be set to specify that either Clarify CRM create the ID or that the connector pass in the ID to Clarify CRM in the business object.
v Specify on a Update operation that the connector keep existing relations between tables as well as create relations for new child business objects.
Figure 1 shows the connector components and their relationships within the WebSphere Business Integration Adapter system. In this figure, InterChange Server is used as the integration broker.
How the connector works
The following sections describe how the connector processes business object requests and event notifications.
Business object processing
When the connector receives a request to perform an application operation, it communicates with the application using the API Toolkit. The connector uses the meta-data in the business object definition and the values in the business object instance to generate functions calls that access the Clarify CRM application
database tables. These function calls perform the required operations in the Clarify CRM database for the business object and verb that the connector is processing.
Generic services (C++)
Event notification Internal Java component
Connector agent Connector Controller Clarify CRM application Database Application tables Event table Archive table Business object requests Clarify API toolkit functions Global functions Database triggers
Figure 2 illustrates business object request processing. (In this figure, InterChange Server is used as the integration broker.) When a business object is sent to the connector’s business object handler, the handler generates an API call that modifies the data in the appropriate database table.
Delete processing
For Delete operations, the Clarify CRM application performs logical deletes rather than physical deletes. In logical deletes, rows in the database are marked as inactive rather than being physically deleted.
Because logical deletes are handled as Update operations, the connector responds to business objects with a Delete verb by converting the verb to Update. Note, however, that verb conversion in the connector may be deprecated. If ICS is used as the integration broker, use native mapping to convert Delete verbs to Update verbs for the connector.
Logical delete operations: The connector deletes a non-hierarchical business object by marking it as inactive. When the connector receives a request to delete a hierarchical business object, it logically deletes only the top-level business object but not the children.
The recommended way to logically delete a record in Clarify CRM is to change a value in a status field to an inactive value. In some tables, Clarify CRM provides a status field, and a business object can use that field to specify logical deletes. However, when a Clarify CRM table does not provide a status field but the field is needed for delete operations, you must customize the table to add a status field. If you add delete functionality to an existing business object, you will also need to edit the business object to provide a status attribute and the correct inactive value. See the Clarify CRM documentation for information on customizing Clarify CRM tables.
Event notification Internal Java component
Connector agent Clarify CRM application Application database Application tables Database triggers Event table Archive table Business object handler Clarify API toolkit functions Global functions Connector controller InterChange Server
Figure 2. Business object request architecture
Physical delete operations: Neither the Clarify CRM application nor the
connector performs physical deletes. If your site needs to physically delete records from a table in response to business object requests, you can add update triggers to Clarify CRM tables. As an example, the update trigger might perform a physical delete when it detects an update of a specific field to a specific value by the connector. However, keep referential integrity in mind when doing physical deletes on existing Clarify CRM tables.
Event notification
For event notification, WebSphere Business Integration Adapter provides database triggers that you add to the Clarify CRM database during the installation
procedure. These triggers populate an event table whenever an event of interest occurs in Clarify CRM. The connector polls this table at a regular interval, retrieves the events, and processes the events first by priority and then sequentially. When the connector has retrieved an event, the event record is removed from the event table and stored in the archive table.
Figure 3 shows the components in the event notification architecture. (In this figure, InterChange Server is used as the integration broker.) When a relevant database table column changes, a trigger populates the event table with a record about the event. The connector polls the event table using an API call, retrieves the event, and generates a business object if the business object has subscribing
collaborations. The event record is moved to the archive table after the connector retrieves the record from the event table.
Archiving events
The archive table contains a copy of all events that are picked up by the connector. After the connector reads an event, the event is deleted from the event table whether the connector has successfully processed it, not processed it because of an
Event notification Internal Java component
Connector agent Clarify CRM application Application database Application tables Database triggers Event table Archive table Business object handler Clarify API toolkit functions Global functions Connector controller InterChange Server
When an event is deleted from the event table, the connector automatically inserts a copy of the event into the archive table with a status of Error. When the
connector processes the event successfully, the status field is updated to Success. If the connector determines that there is no subscription for the event, the status field is updated to Skipped.
Delete processing in the event notification mechanism
The connector has been designed to respond to Delete and Physical Delete verbs in the event table. If your Clarify CRM application has been customized to perform physical delete operations, you can modify the Delete trigger script so that it creates business objects with separate Delete and Physical Delete verbs.
The Delete verb indicates a soft delete, which means that a record was marked for delete (inactive) but still remains in the database. If a Delete event occurs, the connector attempts to retrieve and return the entire record for the deleted entity. The Physical Delete verb indicates a hard delete; in other words, the record was actually removed from the database. If the connector detects a Physical Delete event, it populates a business object with the values contained in the event table but does not attempt to retrieve the deleted entity’s entire record.
To take advantage of this feature, you must set up Delete triggers so that they generate the appropriate verbs. Soft delete events should generate a Delete verb in the event table, while hard delete events should generate a Physical Delete verb in the event table. See “Installing database triggers for event notifications” on page 13 for information on the database triggers provided with the connector.
Chapter 2. Installing and configuring the connector
This chapter describes how to install and configure the connector and how to configure the Clarify CRM application to work with the connector. It contains the following sections:
v “Prerequisites”
v “Installing the connector” on page 8
v “Enabling the Clarify CRM application for the connector” on page 10 v “Configuring the connector” on page 15
v “Starting and stopping the connector” on page 18
Note: Before beginning the installation, determine whether the application has been customized. Existing application customization may affect how you enable the application for the connector. In addition, since the connector setup requires the installation of triggers on database tables, determine whether the relevant tables have existing triggers, and make sure that WebSphere Business Integration Adapter-specific triggers do not overwrite the existing triggers.
Prerequisites
Prerequisite software for the Microsoft SQL Server
If you are running the Clarify CRM application on the MicroSoft SQL Server database, you need to install the MS SQL Server tools and utilities before running the connector.
Setting up a user account in Clarify CRM
You must create a user account in the Clarify CRM application for the connector. The account can have any valid Clarify CRM username and password. It must have the privileges to retrieve, insert, update, and delete data from the Clarify CRM database.
To set up a user account, follow these steps:
1. Bring up the Clarify CRM application and log in with system administrator privileges. A typical example of a system administrator login name is″sa″.
2. Click on the Policies and Customers icon.
3. Click New—>Employee.
4. Fill in the login name, password, first name, and last name fields on the Employee form with the name of the connector user account. Because the database triggers for the event mechanism are coded with the user name “cw”, the name″cw″ is recommended for all four fields.
If you use a different user name, you will need to edit the database triggers to reflect the user name. For information, see “Installing database triggers for event notifications” on page 13.
Note that the name for the Clarify CRM user account is the same name that you should enter for the ApplicationUserName connector configuration parameter. For information on setting the configuration properties for the connector, see “Configuring the connector” on page 15.
5. Fill in the following required fields in the Employee form: v Privileges - Set to system administrator.
v Workgroup - Set to administration. v Site Name - Select any name from the list.
v Email Address - Enter an email address for the user account.
6. Click Add—>Done.
Checking Windows date and time format
The Clarify CRM application uses the date format specified in the Windows short date style that appears under Regional Settings, Date in the Control Panel. If InterChange Server is used as the integration broker, the date format must
correspond to the date format used in the maps for the business objects for Clarify CRM. WebSphere Business Integration Adapter native maps assume that the Windows short date style is MM/dd/yyyy. If the short date style is MM/dd/yy or any other format, you must change the map rules for the Clarify CRM maps to reflect the new date format and recompile the maps.
Installing the connector
The following subsections describe how to install the connector on a Windows or UNIX system.
After your WebSphere Business Integration Adapter system is installed, you can install additional connectors from the WebSphere Business Integration Adapter CD at any time. To do this, insert the product CD, run the installation program, and choose the connectors that you want to install.
Note: Unless otherwise indicated, the remaining sections in this chapter apply to both Windows and UNIX installations of the connector.
Installing on a Windows system
To install the connector on a Windows system, run the Installer for IBM WebSphere Business Integration Adapter and select the IBM WebSphere Business Integration Adapter for Clarify CRM. All standard files associated with the connector are installed. Table 1 describes the file structure used by the connector.
Table 1. Installed Windows file structure for the connector
Subdirectory of %ProductDir% Description
connectors\Clarify Subdirectories containing various versions of the Clarify CRM DLL.
Note: For the connector to start, all Clarify dependent dlls (Ex: mny*.dll, tls *.dll and libdb_d.dll) must be copied into this directory.
connectors\Clarify\dependencies Files containing the triggers for event notification and the scripts for event and archive tables.
connectors\messages Contains the ClarifyConnector.txt file.
Installer adds an icon for the connector file to the IBM WebSphere Business Integration Adapter menu. For a fast way to start the connector, create a shortcut
For more information on installing the connector component, refer to one of the following guides, depending on the integration broker you are using:
v System Installation Guide for Windows (when ICS is used as the integration broker) v WebSphere Business Integration Adapters Implementation Guide for MQ Integrator
Broker (when WebSphere MQ Integrator Broker is used as the integration broker)
Installing on a UNIX system
To install the connector on a UNIX system, run the Installer for IBM WebSphere Business Integration Adapter and select the IBM WebSphere Business Integration Adapter for Clarify CRM.
Note: Only versions 8 and 10 of the connector for Clarify CRM are supported on the UNIX system.
For more information on installing the connector component, refer to one of the following guides, depending on the integration broker you are using:
v System Installation Guide for UNIX (when ICS is used as the integration broker) v WebSphere Business Integration Adapters Implementation Guide for MQ Integrator
Broker (when WebSphere MQ Integrator Broker is used as the integration broker)
For the connector, the Installer installs the file structure shown in Table 2. Table 2. Installed UNIX file structure for the connector
Subdirectory of $ProductDir Description
connectors/Clarify Subdirectories containing various versions of the Clarify CRM shared library
connectors/Clarify/dependencies Files containing the triggers for event notification and the scripts for event and archive tables
connectors/messages Contains the ClarifyConnector.txt file. connectors/Clarify/start_Clarify.sh The start_Clarify.sh file is a system
startup script for the connector. It is called from the generic connector manager script. When you click Install from Connector Configurator (WebSphere MQ Integrator Broker as the integration broker) or the Connector Configuration screen of System Manager (ICS as the integration broker), the installer creates a customized wrapper for this connector manager script. When the connector works with ICS, use this customized wrapper to start and stop the connector. When the connector works with WebSphere MQ Integrator Broker, use this customized wrapper only to start the connector. Use the
mqsiremotestopadaptercommand to stop the connector.
Before you can use the connector, you must:
1. Use the Connector Configuration Tool to generate the customized Clarify CRM wrapper (connector_manager_Clarify) required to start the connector. Refer to
the System Installation Guide for UNIX or the WebSphere Business Integration
Adapters Implementation Guide for MQ Integrator Broker for more information.
2. In the start_Clarify.sh file, modify the ORACLE_HOME environment variable.
For the connector to run, the ORACLE_HOME environment variable must be set to the location of the Oracle Server software on your system.
3. Copy one Clarify CRM shared library from the version-specific subdirectory into the $ProductDir/connectors/Clarify directory.
For example, if you are using the Clarify 8.5 connector with Oracle Server, copy the libclarify.so from the Clarify8.5-oracle subdirectory into the
$ProductDir/connectors/Clarifydirectory.
Enabling the Clarify CRM application for the connector
Before you can use the connector to process application events and send event notification business objects to the integration broker, you must set up the event notification mechanism in the Clarify CRM application. To do this, complete the following tasks:
1. Create the event and archive tables in Clarify CRM.
2. Install database triggers on Clarify CRM tables to support the business objects needed by the collaborations running at your site.
The event table is used to queue events for pickup by the connector. The event table contains enough information so that the connector can determine the name and verb of the business object instance that it will create to represent an event. The sections that follow provide information on these tasks.
Creating the event and archive tables
To set up event processing, you create an event table in Clarify CRM. An event table is required; you must create this table even if the connector will not poll for events. An archive table is optional; however, if the connector is polling for events and there is no archive table, all events are lost once the connector retrieves them, whether or not they were successfully processed.
Table 3 shows the Clarify CRM information for the event and archive tables. Table 3. Connector schema information
Table type Schema file Default table name
Event Table xrdsevts.txt
xrdsevts10.txt (Clarify version 10)
table_xrds_events
Archive Table xrdsarch.txt
xrdsarch10.txt (Clarify version 10)
table_xrds_archive
Table 4 on page 11 shows the location of the schema files (xrdsevts.txt, xrdsevts10.txt, xrdsarch.txt, and xrdsarch10.txt) based on the operating system.
Table 4. Schema file locations
Operating system Schem file location
Windows %ProductDir%\connectors\Clarify\dependencies\ddcomp
UNIX $ProductDir/connectors/Clarify/dependencies/ddcomp
To install the event and archive tables, follow these steps:
1. Make sure that type IDs for the event and archive tables are available.
2. Execute the ddcomp command to create the tables.
3. Confirm that the event and archive tables were created.
These tasks are described in greater detail in the following sections.
Note: If your site will not archive events into an archive table, be sure to remove the value for the connector’s ArchiveTableName configuration parameter using System Manager.
Type IDs for the event and archive tables
By default, the type IDs of the event and archive tables are 501 and 502. Follow these steps to determine the type IDs for your site.
1. Log into the Data Dictionary Editor and determine whether the type IDs 501 and 502 are available. If these IDs are available, you can skip to the next section. If the IDs are already in use, continue with the next step in this procedure.
2. If type IDs 501 and 502 are not available, choose new type IDs. The range of numbers reserved for customer use is from 480 to 512 and from 2000 to 4999. Select type IDs within these ranges.
3. Once you have chosen new type IDs, change the type IDs in the xrdsevts.txt and xrdsarch.txt scripts. To do this, open the xrdsevts.txt (xrdsevts10.txt for Clarify version 10)and xrdsarch.txt (xrdsarch10.txt for Clarify version 10)files in the directory appropriate for your operating system (see Table 4 on page 11).
OBJECT xrds_events 501 to
OBJECT xrds_events new_id
When you have type IDs, continue with the next section.
Creating the event and archive tables
To create the event table and archive table, run the ddcomp command to execute the xrdsevts.txt (xrdsevts10.txt for Clarify version 10)and xrdsarch.txt
(xrdsarch10.txt for Clarify version 10)scripts. The ddcomp utility creates the database schema and populates the Clarify CRM data dictionary with the information contained in the scripts. Typically, WebSphere Business Integration Adapter uses the ddcomp utility to create tables, such as the event table, or views as required by some Clarify CRM application-specific business objects.
Note that if you want to change the name of the event table, you can do this by changing the name in the xrdsevts.txt (xrdsevts10.txt for Clarify version 10)script before you run the ddcomp command. In this case, you will also need to set the EventTableName connector configuration parameter to the new name. To change the name of the archive table, change the name in the xrdsarch.txt
(xrdsarch10.txt for Clarify version 10)script before running the ddcomp command, and set the ArchiveTableName configuration parameter to the new name.
Running the ddcomp command: You can execute the ddcomp command from the dbadmin directory and point to the schema-file directory (see Table 4 on page 11). Alternatively, you can put the path for the directory containing the ddcomp executable in your PATH and run the ddcomp command from the schema-file directory.
Running ddcomp on SQL Server on Windows:: For Microsoft SQL Server on
Windows, the syntax for the ddcomp command is: ddcomp db_name db_server user_name password filename where:
db_name is the name of the Clarify CRM database.
db_server is the name of the Clarify CRM database server.
user_name is the Clarify CRM system administrator login name.
password is the Clarify CRM system administrator password. filename is the name of the event table or archive table script.
Running ddcomp on Oracle on Windows or Unix:: For Oracle, the syntax for the
ddcompcommand is:
ddcomp oracle_database oracle_alias user_name password filename where:
oracle_database is the name of the Clarify CRM database.
oracle_alias is a relation that ties a physical machine name to an Oracle SID.
An Oracle SID is a system identifier that points to the database. It can be thought of as the name of a database instance. Clarify CRM treats the oracle_alias as a server name. Whenever the Clarify CRM application asks for a server name, the oracle_alias can usually be substituted.
user_name is the Clarify CRM system administrator login name.
password is the Clarify CRM system administrator password. filename is the name of the event table or archive table script.
On Oracle, the ddcomp and ddedit utilities also require you to build a public synonym for an object table before you can access that table using the Clarify CRM client or API. For the WebSphere Business Integration Adapter event and archive tables, execute the following SQL statements to create the public synonyms. Use SQL Plus to execute the statements.
create public synonym TABLE_XRDS_EVENTS for sa.TABLE_XRDS_EVENTS; create public synonym TABLE_XRDS_ARCHIVE for sa.TABLE_XRDS_ARCHIVE;
Confirming the event and archive tables
To confirm that the tables were created, use the Clarify CRM Data Dictionary Editor. Log into the Data Dictionary Editor and check for the existence of objects with type ID of 501 and 502, or for objects with the type IDs that you have
Descriptions of table schema
The event table contains the following columns:
objid Internal identifier
object_name Description of the object object_verb Verb associated with the event object_key Primary key for the object
event_priority Event priority. Defined as 0-1, where 0 is the highest priority. event_time Time of the event
event_status Status of the transaction associated with the event; 0 = OK, 1 = ERROR
event_description Description of the event or error string
The archive table contains the following columns:
objid Internal identifier
event_id Value of objid for the event when the event was in the event table
object_name Description of the object object_verb Verb associated with the event object_key Primary key for the object event_priority Event priority
event_time Time of the event
event_status Status of the transaction associated with the event. Status can be Success, Error, or Skipped.
event_description Description of the event or error string
Installing database triggers for event notifications
You install database triggers in Clarify CRM to support the business objects used by the collaborations running at your site. The database triggers are implemented so that a row is generated to the event table whenever an application object is created, updated, or deleted.
You also install a database trigger that deletes events from the event table. If an archive table is available, the event record is moved to the archive table; otherwise, it is lost. Table 5 shows the name of the event table deletion trigger based on the database server for the Clarify CRM database.
Table 5. SQL script names for event table deletion triggers
Database server Event table deletion trigger
MSSQL MSSQL_event_delete_trigger.sql Oracle Oracle_event_delete_trigger.sql
Oracle_event_delete_trigger10.sql (Clarify version 10)
The files in Table 5 are located in the directory: v On a Windows system:
%ProductDir%\connectors\Clarify\dependencies
v On a UNIX system:
$ProductDir/connectors/Clarify/dependencies
Note: Before you can execute the trigger scripts, you must have a user account in Clarify CRM. For information on creating a user account, see “Prerequisites”
on page 7.
To execute the event table deletion SQL script and install the database trigger, follow these steps:
1. Open a query window.
2. Connect to the server that hosts the Clarify CRM database.
3. Open the Clarify CRM database.
4. Execute the script for the event table delete trigger. See Table 5 on page 13 for the name of the script.
5. Execute the following commands in your SQL processor: grant all on table_xrds_events to username
grant all on table_xrds_archive to username For SQL Server, use isql_w or a similar tool.
If the script executes with no errors, a message indicates that no data was returned.
You might also need to execute scripts for triggers for the business objects required by your business processes. WebSphere Business Integration Adapter provides sample business objects. You can use these business objects or create your own customized business objects. To execute triggers for your business objects, perform the following steps:
1. Identify the WebSphere Business Integration Adapter triggers for the business objects required by your business processes.
2. Connect to the database server and open the Clarify CRM database. Follow Steps 1 through 3 on page 14 in the previous list of steps.
3. If the connector user name is the default″cw″, skip to the next step. If the user name is not″cw″, update the scripts with the correct connector user name before executing them. Setting the user name correctly prevents the trigger from generating an event for an application change that resulted from a business object request.
To update the scripts, follow these steps:
a. Edit each script to replace″cw″ with the correct user name. Change the line: if (@user <> "cw")
to read:
if (@user <> "<username>")
b. Recompile the scripts.
Note that the ApplicationUserName connector configuration property should be set to the name for the Clarify CRM user account.
4. Execute the scripts for the business object triggers. You must be the database owner to execute the scripts.
Configuring the connector
You must set the connector’s standard and connector-specific configuration
properties before you can run it. Use one of the following tools to set a connector’s configuration properties:
v Connector Configurator (if ICS is the integration broker)--Access this tool from the System Manager.
v Connector Configurator (if WebSphere MQ Integrator Broker is the integration broker)--Access this tool from the IBM WebSphere Business Integration Adapter program folder. For more information about Connector Configurator, see Appendix B, “Connector Configurator”, on page 71
Standard connector properties
Standard configuration properties provide information that all connectors use. See Appendix A, “Standard configuration properties for connectors”, on page 49for detailed information about these properties.
Note: This connector is single threaded. It cannot use the AgentConnections property.
Important
Because the connector for Clarify CRM supports both the ICS and WebSphere MQ Integrator Broker, configuration properties for both brokers are relevant to the connector.
Connector-specific properties
Connector-specific configuration properties provide information needed by the connector at runtime. Connector-specific properties also provide a way of changing static information or logic within the connector without having to recode and rebuild it.
Table 6 on page 16 lists the connector-specific configuration properties for the connector. See the sections that follow for explanations of the properties.
Table 6. Connector-specific configuration properties
Name Possible values Default value Required
ApplicationPassword Password of user account cw Yes
ApplicationUserName Name of user account cw Yes
ArchiveTableName Name of archive table xrds_archive No
DatabaseName Name of Clarify CRM database clarify Yes
EventTableName Name of event table xrds_events Yes
FloatPrecision Precision of a float value 6 No
ServerName Name of Clarify CRM server clarify Yes
IgnoreMissingChildObject trueor false true No
PollQuantity Number of events per poll 25 No
DoublePrecision Precision of a double value 15 No
PollAttributeDelimiter Delimiter for attributes in event table
:(colon) No
RequestRetrieve deepor shallow shallow No
SQLDumpFileName Name of file containing SQL statements
C:\\temp\ XrclarifySQL.log
No StateDumpFileName Name of file for state report C:\\temp\ Xrclarify.log No
UseClarifyID trueor false false No
UseDefaults trueor false false No
ApplicationPassword
Password for the connector user account. The default value is cw.
ApplicationUserName
Name of the connector user account. The default value is cw.
ArchiveTableName
Name of archive table. The default name is xrds_archive.
DatabaseName
Name of the Clarify CRM database. The default name is clarify.
EventTableName
Name of event table. The default name is xrds_events.
FloatPrecision
Specifies the precision of a float value. The default value (six) is the default precision for floats in the Oracle and MSSQL databases. The value for the
parameter should match the precision that the database uses for that data type. If the database has been customized, change the value for the connector to match.
ServerName
Name of the server running Clarify CRM. The default name is clarify.
IgnoreMissingChildObject
On a Retrieve operation, determines whether the operation succeeds for a
hierarchical object if one or more child objects are missing. If the parameter is set to true, the retrieve operation is successful even without all child objects. If the parameter is set to false, the retrieve operation fails if all child objects are not retrieved.
PollQuantity
Number of events to process per poll. The connector poll method retrieves the specified number of event records and processes them in a single poll. Processing multiple events per poll can improve performance when the application generates large numbers of events. However, since integration broker requests are blocked while the poll method is processing events, be sure not to set the number of events too high.
As a general guide, set PollQuantity to be ten percent of the average number of events you expect to have in the event table at one time.
There is a relationship between PollQuantity and PollFrequency values. The larger the PollQuantity value, the larger the PollFrequency value should be. As a general guide, set the PollFrequency to 60 Milliseconds * the PollQuantity value.
The default value is 25.
DoublePrecision
Specifies the precision of a double value. The default value, 15, is the default precision for doubles in the Oracle and MSSQL databases. The value for the parameter should match the precision that the database uses for that data type. If the database has been customized, change the value for the connector to match. The default value is 15.
PollAttributeDelimiter
Specifies the delimiter for multiple attributes in the object name column of the event table. If the Clarify CRM objid is not used as the key field and the key field may contain a colon (:), set this configuration property to a single character that will not be part of the key field.
The default value is a colon (:).
RequestRetrieve
Specifies whether a connector responds to a Retrieve request by retrieving the business object’s entire hierarchy (a deep retrieve) or by retrieving only the top-level business object (a shallow retrieve). The possible values are Deep and Shallow.
Note that the connector also supports the RetrieveAll verb. If the value of RequestRetrieve is set to Deep, the business object must have support for the RetrieveAll verb.
The default is shallow.
SQLDumpFileName
Name of the file containing the SQL statements executed by the Clarify API. Information is appended, so the file may need to be truncated periodically.
In Windows, the default file is C:\\temp\XrclarifySQL.logIn UNIX, the default file is $/ProductDir/XrclarifySQL.log
StateDumpFileName
Name of the file in which the Clarify API reports its state when accessing different objects. Information is appended, so the file may need to be truncated periodically.
In Windows, the default file is C:\\temp\Xrclarify.log. In UNIX, the default file is $/ProductDir/Xrclarify.log
UseClarifyID
On a Create operation, determines how the Clarify ID is created. If the parameter is set to true, Clarify CRM creates the ID. If the parameter is set to false, the connector passes in an ID to Clarify CRM.
The default value is false.
UseDefaults
If UseDefaults is set to true or not set, the connector checks whether a valid value or a default value is provided for each Required business object attribute. If a value is provided, the Create succeeds; otherwise, it fails.
If the parameter is set to false, the connector checks only for valid values; the Create operation fails if valid values are not provided.
The default value is false.
Starting and stopping the connector
For information on starting and stopping a connector, see one of the following documents, depending on the integration broker you are using:
v IBM WebSphere Business Integration Implementation Guide for WebSphere MQ
Integrator Broker (IBM WebSphere MQ Integrator Broker as the integration
broker)
v IBM WebSphere InterChange Server System Administration Guide (ICS as the integration broker)
Chapter 3. Developing business objects for the connector
This chapter describes how the connector processes business objects and describes the assumptions the connector makes. You can use this information as a guide to modifying existing business objects for Clarify CRM or as suggestions for implementing new business objects. It contains the following sections: v “Meta-data-driven connector design”v “Business object structure” on page 20
v “Business object attribute properties” on page 22 v “Attribute and database types” on page 26
v “Business object application-specific text” on page 27
Note: In this chapter, the term hierarchical business object is used to refer to a complete business object, including all the contained child business objects at any level. The term individual business object is used to refer to a single business object without reference to any contained child business objects.
Meta-data-driven connector design
The connector is a meta-data-driven connector. In WebSphere Business Integration Adapter business objects, meta-data is data about the application that is stored in a business object and that assists the connector to interact with an application. A meta-data-driven connector handles each business object that it supports based on meta-data encoded in the business object definition rather than on instructions hardcoded in the connector.
Business object meta-data includes the structure of a business object, the settings of its attribute properties, and the content of its application-specific text. Because the connector is meta-data driven, it can handle new or modified business objects without requiring modifications to the connector code.
When processing business objects, the connector makes assumptions about the: v Structure of business objects
v Relationship between parent and child business objects v Format of the application-specific text
v Database representation of a business object
Therefore, when you create or modify a business object for Clarify CRM, your modifications must conform to the rules the connector is designed to follow, or the connector will not be able to process new or modified business objects correctly. The following sections provide information on implementing business objects for Clarify CRM.
Business object structure
WebSphere Business Integration Adapter business objects can be hierarchical: parent business objects can contain child business objects, which can in turn contain child business objects, and so on. A cardinality 1 container occurs when an attribute in a parent business object contains a single child object. A cardinality n container object occurs when an attribute in the parent business object contains an array of child business objects.
The connector supports both cardinality 1 and cardinality n relationships between business objects. In each type of cardinality, the relationship between the parent and child business objects is described by the application-specific text of the key attribute of the child object.
An illustration of this relationship for a cardinality 1 container is shown in Figure 4. An illustration of a cardinality n relationship for business objects for Clarify CRM would look the same as Figure 4 except that the container attribute would contain an array of child business objects.
Business objects and Clarify CRM database tables
In each individual business object, the first attribute is the object key. Each subsequent attribute is either a container attribute or a simple attribute that does not contain a child business object.
Note: The connector does not support specifying an attribute that represents a child business object or an array of child business objects as a key attribute. An individual business object for Clarify CRM can represent one or more Clarify CRM database tables. For a business object that represents only one database table, the key attribute refers to the object ID of the Clarify CRM table or to another field in the Clarify CRM table that is used as the key. Each additional simple attribute within the business object represents a field in the table.
For an individual business object that represents multiple database tables, the business object key refers to the main table that the object represents. Each additional simple attribute within the business object represents a field in either the primary table or another table. The relationship between tables is contained in the attribute application-specific text in the business object definition.
Name Attribute 1 Verb Attribute N Name Attribute 1 relationship Verb Attribute N Cardinality 1 container Parent Child
Business object implementation of relationships between
Clarify CRM tables
In Clarify CRM, relationships between database tables are contained in named relations. Named relations are defined by Clarify CRM and are implemented as columns in the database tables. Clarify CRM application-specific business objects use named relations to provide the connector with information about how the business object relationships correspond to Clarify CRM tables.
WebSphere Business Integration Adapter business objects for Clarify CRM can use named relations in two ways:
v An individual business object definition can include attributes that reference one or more related database tables using named relations specified in attribute application-specific text. Once an attribute has established a relationship between two tables, additional attributes can reference the new table without redefining the relationship. Figure 5 illustrates a business object with attributes that represent related tables and use named relations.
v A parent business object definition that represents one table can have one or more child business object definitions that represent other tables. The parent and each child business object can also reference other tables by means of named relations specified in attribute application-specific text.
When one or more relations are specified, the connector creates the relations between objects as part of Create or Update operations. For specific information on combining preprocessing and use of a relationship, see Chapter 4,
“Troubleshooting”, on page 47.
Application-specific text can use either named relations or inverse relations to join tables. An inverse relation is typically used in a child business object to point back to the parent business object.
Note: Each individual business object can contain only one join to a table. For example, if a top-level business object represents the site table, an error will occur if an attribute in the business object attempts links to the site table a second time using a named relation such as child_site2site. To prevent this, you can create a child business object that contains an attribute linking back to the parent business object. Or you can add a column to the site table, make the column a field rather than a relationship, and copy the attribute value into the field with a trigger.
Tips on designing business objects for Clarify CRM
When designing a business object definition that references multiple Clarify CRM tables, you should make a design decision about the structure and purpose of the business object. For example, if a business object definition for a table includes a few attributes for another table, defining a single business object for the two tables may be sufficient. However, if a business object definition includes many important attributes from another table, you may want to create a child business object definition for the second table rather than locating attributes for both tables in the same business object definition. In addition, if the business object already
references other child business objects, creating another child business object to represent a new table makes the business object structure consistent.
If you are creating a business object that will be used primarily for Create
operations, organizing attributes for different tables into child business objects may be a logical approach. However, if the business object will be used primarily for
Retrieve operations or event notification, it may be simpler to pass along information about multiple tables in one business object.
Figure 5 shows an example individual business object with attributes that reference a primary database table and attributes that reference additional tables by means of named relations.
For information on modifying a business object to add attributes that reference other tables, see “Specifying relations between objects” on page 31.
Business object attribute properties
Business object architecture defines various properties that apply to attributes. This section describes how the connector interprets several of these properties and describes how you should set them when modifying a business object.
Name property
Each business object attribute must have a unique name.
Type property
Each business object attribute must have a type, such as Integer, String or the type of a contained child business object.
Key property
At least one simple attribute of every business object for Clarify CRM must be specified as the key. To do so, set this property to true. The key attribute is always the first attribute. Therefore, when creating a business object for Clarify CRM, be
Verb AddressObjId Address City State CountryName TimeZone address objid address city state country objid name code time_zone objid name full_name zipcode address2country address2time_zone
Clarify CRM database tables
Clarify_Address
Relations
value for the new key and Retrieve operations will return the correct record from the table that the business object represents.
Note: The connector does not support specifying an attribute that represents a child business object or an array of child business objects as a key attribute. Note that the connector ignores multiple keys and only uses the first key, except in Retrieve operations when the application-specific text in the business object
definition specifies multiple key retrieve; for information on multiple key retrieve, see “Specifying multiple key attributes for retrieve operations” on page 29. The key property is processed slightly differently in top-level business objects and child business objects.
Key property in top-level business objects
For Create operations, the connector processes key attributes as follows:
v If the key represents the value stored in the objid field in a Clarify CRM table, and the value for the key is null, Clarify CRM generates a value for the key, and the connector returns the value in the business object.
If the key represents the objid field in a Clarify CRM table, but the value for the key is not null, the connector attempts to create a record with a new key value. Depending on the Clarify CRM schema and indexes, one of the following behaviors will occur:
– A unique index violation will occur.
– A record will be created successfully with a new objid. However, in this case you may have duplicate information in the database.
On Create and Update operations, the Clarify CRM application is designed to generate its own objid values. For this reason, it is strongly recommended that you not design business objects to pass in values for objid fields unless you know how the Clarify CRM application will behave.
v On a Create operation, if the key does not represent the value in the objid field but represents another field in the table, such as the part number in the part_num table, and the value of the attribute is not null, the connector stores the attribute value in the database. Note that if the record already exists, one of the following behaviors will occur:
– A unique index violation will occur.
– A record will be created successfully. However, in this case you may have duplicate information in the database.
v On a Create operation, if the key is not the objid field, and the attribute
application-specific text specifies SchemeName=Value for automatic generation of a value for the key, and the value of the key attribute is null, the connector
generates the next sequential number in Clarify CRM and uses that value to create the record. The connector returns the generated value in the business object.
For information on automatically generated values for attributes, see “Generating attribute values automatically” on page 41.
In all cases, on a successful completion of a Create operation, the connector will return a populated key in the business object, whether the value was the objid value, a value for a non-objid field, or an automatically generated value. For a Retrieve operation, if the attribute is a key, its value is used to retrieve the other values for the business object, but the key value itself is not retrieved from
the database. If the verb is Retrieve and the key value is CxMissingId, the connector will return a failure because it cannot retrieve the object.
Key property in child business objects
If the verb is Create or Update and the value of the key is unknown for a child business object, use the string CxMissingId for the key attribute value. When the key value of a child business object is set to CxMissingId, the connector will perform a Create for a child object without first checking whether the record already exists.
However, because the query parameters are not constrained when there is more than one child object, there is a possibility of orphan data in the Clarify CRM database. To eliminate this possibility, cross reference child keys.
Foreign key property
Relationships between tables in the Clarify CRM application are defined by named relations rather than by foreign keys. As an example, information on a business organization is stored in Clarify CRM in the bus_org table. This table includes relations to the site and address tables, which store information on the
organization’s site and primary address. The relations are implemented as columns in the bus_org table.
WebSphere Business Integration Adapter business objects for Clarify CRM use Clarify CRM named relations to represent relationships between tables. Each individual business object can reference multiple tables by including attributes whose application-specific text specify the relations. When several attributes reference the same foreign table, the relation is specified in the first attribute that references the table.
Because relationships are contained in named relations, the Foreign Key property is not used in business objects for Clarify CRM to explicitly specify that an attribute represents a foreign key. Instead, this property is used to define how the connector processes attributes with relations.
The rules for connector processing of Foreign Key attributes for Create and Update operations are shown in Table 7. Note that the Foreign Key property is only checked for attributes that have named relations in their application-specific text. Table 7. Connector processing of foreign key property
Foreign key property setting
Attribute value Description of connector processing
true Not null If the attribute application-specific text includes a named relation, the connector checks for the existence of the record in the
application database using the value of the Foreign Key attribute. If the record exists, the connector creates the relation between the entities. If the record does not exist, the connector returns BON_FAIL. true or false Null The connector evaluates whether the foreign key attribute is
required (the Required property is set to true). If the attribute is required, the connector returns BON_FAIL. If the attribute is not required, the connector skips the attribute.
false Not null If the attribute application-specific text includes a named relation, the connector checks for the existence of the record in the
application database using the value of the Foreign Key attribute. If the record exists, the connector creates the relation between the
As shown in Table 7 on page 24, the Foreign Key property is overloaded in business objects for Clarify CRM to specify what kind of foreign key lookup the connector will perform. If Foreign Key is set to false, the connector performs a dynamic lookup of the related record, creating the relation if the record exists and creating both the record and relation if the record does not exist. If Foreign Key is set to true, the connector simply creates the relation if the record exists and fails the operation if it does not exist.
As an example, suppose that the AddressState_prov attribute in the
Clarify_SiteAddress business object specifies a state in the Clarify state_prov table. If the state_prov table already contains all state names, you can set Foreign Key to trueso that the connector will find an existing state name or fail. This limits the spellings of state names to those in the table. If the spelling of state names is not important, you can set Foreign Key to false so that the connector will insert any spelling of state names.
In summary, when modifying business objects for Clarify CRM, use the Foreign Key property to specify what kind of lookup the connector should perform.
Required property
The Required property specifies whether an attribute must contain a value. If a particular attribute in a business object that you are modifying must contain a value, set the Required property to true.
If the verb is Create and Required is true, the connector will cause the Create operation to fail if the business object does not have a valid value or a default value for a Required attribute.
The connector does not check the Required property for verbs other than Create.
Max length property
The connector does not currently use the Max Length property. It is good practice, however, to set the value of this property to the number of bytes the attribute can contain. At a minimum, set the value of Max Length to 8 so that the attribute value can be CxIgnore.
UseDefaults property
This property specifies a default value for the attribute that will be used if there is no runtime value for the attribute in the business object. If the following criteria are met, the UseDefaults configuration property is enabled:
v UseDefaults = true
v Business object verb = Create v Business object attribute = Required
v Default value is populated for the attribute that is marked Required If the UseDefaults property is enabled the following will occur:
v If the business object verb is Create and the value of an attribute is null, the connector will populate the field with the value in the attribute Default Value property.
v If the attribute is Required and there is no default value in the business object definition and the value of the attribute is null, the connector will fail.
Attribute and database types
The connector supports the data types shown in Table 8. When you add a business object attribute, set the attribute data type according to the data type of the field in the Clarify CRM table.
Table 8. Business object attribute and database types
Clarify CRM data types WebSphere Business Integration Adapter attribute data types
int, tinyint, smallint integer
real float
varchar, text string
decimal string
datetime string
Important notes on attributes that reference Clarify fields of
type text
The connector supports Clarify CRM text fields of types varchar and text. WebSphere Business Integration Adapter business objects for Clarify CRM can include attributes with a data type of string that reference fields in Clarify CRM with the data type of text.
Note, however, that an attribute that references a field of type text cannot have a relation in its business object application-specific text. To work around this, you can add a preceding attribute that represents the object ID of the table, put the relation between the tables in the application-specific text of that attribute, and then reference the table in the application-specific text of the attribute representing the text field.
For example, suppose that you have a business object named Clarify_Case that represents the Clarify CRM case table. You want to add a relation to the notes_log table so that you can include an attribute for the text of a note related to a case. To do this, you add an attribute in the Clarify_Case business object for the object ID of the notes_log table, and, in the application-specific text for this attribute, include the relation between the tables. Then add an attribute for the text of the note. In this example, the attribute you want to reference is
notes_log:description, which is a field of type text. Figure 6 illustrates these attributes in the example Clarify_Case business object.
If the connector attempts to select or update a text field in Clarify CRM, and the business object attribute with the text data type does not refer to the attribute representing the table object ID, the following errors may result:
v Execution of the SQL command failed due to unexpected problems.
v TEXTand IMAGE data types may not be used in the WHERE or HAVING clause, except with the LIKE predicate and the IS NULL predicate.
Note that although ObjId is necessary for text fields, it is not necessary for varchar fields.
Business object application-specific text
Application-specific text in business object definitions provides the connector with application-dependent instructions on how to process business objects. This meta-data is used in conjunction with a business object’s attribute properties and structure. If you extend or modify Clarify CRM application-specific business objects, you must make sure that the application-specific information in the business object definition matches the syntax that the connector expects. This section provides information on the object, attribute, and verb
application-specific text format for business objects for Clarify CRM. Table 9 provides an overview of the functionality available in business object application-specific text for Clarify CRM.
Table 9. Overview of application-specific text in business objects for Clarify CRM
Scope of application-specific text
Types of functionality
Entire business object Define the scope of transactions in the connector Specify that the connector perform retrieves using multiple keys
Simple attributes [Required] Specify table name, field name, and data type for an attribute Specify one or more relations between attributes in the primary table and one or more foreign tables Specify how retrieve queries are constructed Specify automatic generation of attribute values Specify preprocessing for attributes Specify that Retrieve operations use non-key values Name = CaseObjid AppSpecificInfo = case:objid::1: Type = Integer Clarify_Case ... Name = CaseNotes AppSpecificInfo = notes_log:objid:case_notes2notes_log::1: Type = Integer Name = NoteDescription AppSpecificInfo = notes_log:description::3: Type = String Create relation between tables Refer to text attribute in related table ...
Figure 6. Referencing attributes of type text
