ArchiveLink Archiving Issue – Deleted Workspace in Recycle Bin?

Question

A potential issue can occur in SAP–OpenText xECM ArchiveLink integration when the target Business Customer Workspace has been deleted and moved to the xECM Recycle Bin.

The scenario involves manual archiving of BKPF business documents to customer business workspaceb, where the customer workspace is identified using:

* BOR Object: KNA1
* BOR Key: Customer Number
* xECM Node/Data ID: Unique workspace node ID

Observed Behavior

When the customer workspace is active, manual ArchiveLink archiving works as expected.

However, when the workspace is deleted, it is moved to the Recycle Bin, while its original Node ID still exists.

When another BKPF document is subsequently archived, the ArchiveLink process calls:

CALL METHOD get_workspace_nodes

which internally calls:

CALL METHOD me->chk_existing_wsp_nodes

The existing workspace check identifies the deleted Node ID as an existing workspace based on the BOR Object and BOR Key.

As a result, the process attempts to reuse/update the old Node ID instead of creating a new workspace through:

CALL METHOD me->crt_wsp_nodes

The subsequent GetNode operation then fails because the node is no longer an active workspace.

Interestingly, if the workspace is restored from the Recycle Bin, the same ArchiveLink process works successfully.

Technical Question

The main point requiring investigation is how chk_existing_wsp_nodes determines whether a workspace exists.

Specifically:

* Is the lookup performed against Dtree( i dont think so because Dtree doesnt store deleted items), Dtreecore another xECM/Content Server API?
* Can deleted or Recycle Bin nodes be returned by this lookup?
* Is the node's active/deleted status validated before it is treated as an existing workspace?

Expected Behavior

A workspace located in the Recycle Bin should ideally not be considered an active existing workspace for a new ArchiveLink transaction.

The expected logic would be:

Serch workspace — workspace found — yes — check node status — Active ( note deleted) —reuse that nodeid.

Conclusion

The behavior suggests a possible mismatch between the workspace existence check and the actual availability of the xECM node.

The key investigation should therefore focus on whether chk_existing_wsp_nodes is returning a deleted/Recycle Bin node as an existing workspace and whether an additional node-status validation is required before reusing the workspace.

This would allow the system to distinguish between:

Existing active workspace → reuse the workspace

Deleted/Recycle Bin workspace → treat as unavailable and create a new workspace.

appuq · Answer

I would ask OT to look at the underlying code from SAP/AL and see if you have a valid point. The SAPXECM module maintains its own tables for its operations. You can see a lot of tables that have SAP or XECM in their names; they are joins to workspace node IDs and objects . When OT introduced the new Recycle Bin a few years back, what I remember @David Templeton saying at the time was that it was a logical delete. So if one deletes a folder that folder is renamed with a flag that Dtree would exclude. However, there are no node-crawling operations to mark descendants, as it is very expensive. So if you add a new Document Add to that folder, Oscript will say node not found, as it should . However, if you add a node version based on the nodeid I bet OT does a check whether the node is in a deleted volume and will probably return cannot do it. If the code written by OT or SAP does not know the rules of engagement, then they can obviously find it based on DTreeCore; ideally, they should be using API's to find that. So, in many organizations I have worked with, they don't mark Workspace Objects as recyclable, so if that is deleted, it is gone for good unless some RM operation prevents it from a final purge or a legal hold. That is all I can say because I dont work on the ABAP side, so I can't fully comment on it. The design contract that OT makes is that if an object is logically deleted, neither it , nor its descendants are mutable, so we kind of say immutable. Hope that made sense

Nitesh harjai · Answer

@appuq any idea about above issue ?