Handling the Delete verb

For a delete, an application might support either of the implementations shown in Table 40.

Table 40. Delete Implementations

Delete implementation Description Verb-processing support
Physical delete Physically removes the specified application entity. Delete operation
Logical delete Does not actually remove the entity; instead, it marks it with a special "deleted" status. Update operation

Note:
If the application does not allow any type of delete operation, the connector can return a "Fail" outcome status.

The Delete operation, discussed in this section, performs a true physical deletion of data in the application. Connectors for applications that perform logical delete operations should handle logical deletes in the Update operation. For more information, see "Implications of business objects representing logical Delete events".

When the business object handler obtains a Delete verb from the request business object, it must ensure that a physical delete is performed; that is, the application deletes the application entity whose type is indicated by the business object definition, as follows:

Note:
For a table-based application, the entire application entity must be deleted from the application database, usually deleting a row in one or more database tables.

This section provides the following information to help process a Delete verb:

Note:
You can modularize your business object handler so that each supported verb is handled in a separate Java method. If you follow this structure, a Delete method handles processing for the Delete verb.

Standard processing for a Delete verb

The following steps outline the standard processing for a Delete verb:

  1. Perform a recursive retrieve on the request business object to get all data in the application that is associated with the top-level business object.
  2. Perform a recursive delete on the entities represented by the request business object, starting from the lowest level entities and ascending to the top-level entity.

Note:
Delete operations might be limited by application functionality. For example, cascading deletes might not always be the desired operation. If you are using an application API, it might automatically complete the delete operation appropriately. If you are not using an application API, you might need to determine whether the connector should delete child entities in the application. If a child entity is referenced by other entities, it might not be appropriate to delete it.

Outcome status for Delete verb processing

The Delete operation should return one of the outcome-status values shown in Table 41..

Table 41. Possible outcome status for Java Delete verb processing

Delete condition Java outcome status
InterChange Server only: In most cases, the connector returns a "Value Changed" outcome status to enable the system to clean up the relationship tables after a delete operation. VALCHANGE
All integration brokers: If the Delete operation is unsuccessful, it:
  • fills a return-status descriptor with additional information about the cause of the delete error
  • returns a "Fail" outcome status
FAIL
Note:
When the connector framework receives the VALCHANGE outcome status, it includes a business object in its response to InterChange Server. For more information, see Sending the verb-processing response.

Copyright IBM Corp. 1997, 2004