The following sections describe how the connector processes business object requests and event notifications.
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.
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.
Figure 2. Business object request architecture
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.
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.
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.
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.
Figure 3. Event notification architecture
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 error, or skipped it because there is no subscription for it.
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.
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 for information on the database triggers provided with the connector.