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:
- For a flat
business object, the Delete verb indicates that the specified entity
must be deleted.
- For a hierarchical
business object, the Delete verb indicates that the top-level business
object must be deleted. Depending on the application policies, the it
might delete associated entities representing child business objects.
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:
- 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.
- 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.
