Transactional Integration of Drafts and existing Applications

Technical vs. Semantic Transaction

Stateful Application Stateless Consumption (using Drafts)
Stateful Stateful
Fiori
Frontend Backend Draft Backend
Frontend
Application Application

Update A Edit Copy

Update B Commit Technical Transaction

Technical Tansaction Update A
Save (Commit) = Semantical Transaction Commit Technical Transaction
Update B Semantical
Commit Technical Transaction Transaction

Activate
Insert Technical
Commit Transaction

Transaction: Sequence of operations that must succeed or fail as a complete unit

a) Technical Transaction
Sequence of operations that are written as a unit to database via commit or are rolled back together.
b) Semantical Transaction
Draft documents are copies of active documents for the sake of modifying them in a stateless fashion. They are modified along multiple backend
roundtrips that consists of OData changesets. Each changeset corresponds to a technical transaction finished either by commit or rollback. A
semantical transaction is finished either by the ACTIVATE function or the deletion of the draft.
Activating a draft means inserting its data into the active persistency and making it visible for all consumers.
 Transactional Integration of Drafts and existing Applications
Scenario: Draft Modifies existing non-Draft Application
using the ACTIVATE for Integration
First Stateful Application (using Draft)
Stateless Draft
First Stateful
Fiori (for first stateful
Application
Frontend Application)

Edit Copy
Commit
Update A
Commit Second Stateful Application
Update B
Second
Commit
Stateful
Application Semantic
Activate Modify Legacy Application Tansaction
Update A
Technical
Insert Draft Data Update B Tansaction

Commit
by Gateway

This scenario shows how an existing stateful application can be consumed by a draft-based application. It is important that two actions are executed as a unit (technical transaction):
(1) The modifications done on the second stateful application are committed
(2) The draft is activated and committed (and thus copied into the first stateful application)
As in case of OData accesses the gateway takes over the commit it is the so called the master transaction manager – the draft infrastructure should behave like a slave transaction
manager managing the draft instances. Also the second stateful application must not execute commits or rollbacks.
 Transactional Integration of Drafts and existing Applications
Scenario: Draft Modifies existing non-Draft Application
using a phase before ACTIVATE
First Stateful Application (using Draft)
Stateless Draft (for first
First Stateful
Fiori stateful
Application
Frontend application)
Second Stateful Application
Edit Copy Second
Stateful
Commit
Application
Update A
Commit
1 Update A
Update B Technical
Commit
Update B Tansaction
Semantic
Delete Draft
2 Tansaction

Commit

Problem
In this example the second stateful application is modified by a draft not during the activate phase, but in a changeset before. In that case, the modification on the draft and the
modification of the second application are committed both together (see 1). Afterwards the draft is removed (see 2) – however, the changes done on the second stateful
application before are already committed (while 1). In addition, the draft data wasn‘t public to anyone with exception of the draft creator, however the modifications done on the
second stateful application have been immediately visible for all consumers (since 1).

Solution
The second application also needs some kind of „draft“ concept. This might be an indicator flag to keep the changes privat until the corresponding draft is really activated. In case
of draft deletion, the flagged modifications must also be removed. As the draft is implemented with BOPF, it is possible to invoke the second stateful application to delete the
flagged changes in case of deleting the draft via DELETE determination. In the ACTIVE action, the flagged changes can be finally committed.