Clarify why `/confirm` reconstructs TCC participant URIs from `TransactionHistory` when the `Link` header is already provided

Hi Oracle MicroTx team,

I was going through the TCC Spring Boot sample and had a question about the two-step reservation flow, specifically the /confirm/{tripBookingId} endpoint in the travel-agent service.

From what I understand, the /reserve endpoint creates the reservations and returns a Link header containing the MicroTx TCC transaction URI. Later, the client passes that Link header back when calling /confirm/{tripBookingId}.

However, in the /confirm implementation, the code also fetches the saved TransactionHistory by tripBookingId and reconstructs the participant list from the stored reservation URIs:

BookingHistory.TransactionHistory transactionHistory = service.get(tripBookingId);
List<TccParticipant> participants = getTravelParticipants(transactionHistory);

ConfirmResponse confirmResponse = tccClientService.confirm(participants);

And getTravelParticipants(...) manually builds the participant list using the hotel and flight booking URIs stored in TransactionHistory.

My question is:

If the client is already passing the MicroTx Link header back to /confirm, why does the initiator still need to reconstruct the participant URIs from TransactionHistory?

I originally expected the Link header to be enough for MicroTx to identify the existing TCC transaction and its already-registered participants, especially since the participant services call addTccParticipant(...) during the Try/reservation phase.

So I am trying to understand whether the intended model is:

1. The Link header only identifies or resumes the TCC transaction, but does not by itself provide the participant reservation URIs to the initiator.
2. The initiator must persist the reservation URIs itself if confirm/cancel happens in a later HTTP request.
3. confirm(participants) is used in the two-step flow because the original Try-phase call stack and collected participant headers are no longer available.
4. addTccParticipant(...) is still needed during the Try phase for protocol-level enlistment, but the two-step sample also stores URIs in application state so they can be supplied again later.

Is that the correct interpretation?

If so, it might be helpful to add a short comment or note in the sample explaining the difference between:

• the MicroTx transaction URI in the Link header, and
• the participant reservation URIs stored in TransactionHistory.

Right now, it is a little hard to tell whether the stored participant URI reconstruction is required by the TCC protocol, required only by this sample’s two-step design, or just an implementation choice.

Thanks a lot for the sample. It has been helpful given lack of api documentation.

Start with the travel-agent service's /reserve and /confirm/{tripBookingId} implementations, especially getTravelParticipants(...) and the Link header handling. Trace how TransactionHistory stores the hotel and flight reservation URIs, then add a short sample note distinguishing the transaction URI from participant URIs and explaining why the two-step flow reconstructs them.