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.
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.
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."Sending the verb-processing response" on page
179.
