Hi,
I used to think that Wont-Use parameter is sufficient for a
callout server to get out of the loop safely. I now believe that it is
not true because Wont-Use can be used to tell the processor that
original data is no longer needed, but it does not tell the processor
that the service is not going to _generate_ more adapted data. I tried
to fix this logic in the new OCP Core section, quoted below.
Please see it I am still missing something important or if the
interface can be simplified again:
I agree that a Want-Out message is very needed and it's a good idea to have
a special status code as result for transaction termination.
Question here: Should it be the result of TE or better AME? I think AME fits
better.
Should the callout server confirm by sending also a special (the same 206)
result code?
There are three normal cases for transaction termination. We may want to
discuss this together in one section of OCP core and define result codes for
all three. What do you think?
1. Complete application message is sent to callout server and terminated
with AME 200, callout server returns a complete message and also ends with
AME 200.
2. At some time callout server decides to only echo the rest of the message.
It sends a Want-Out message, echos all data until it receives an AME 206 and
then responds also with an AME 206.
3. The callout server sends a response (e.g. an error message for the
client). Sending is done before complete application message has been
received. The callout server will send its AME message and by design does
not longer care about DUM/DUY messages being transferred for this
transaction. OPES processor can stop sending the application data when it
sees the AME message. It will terminate the transaction.
We should also have a special 2xx result for this case, I think.
Note, that in cases 1 and 2 the OPES processor sends the AME message first
and in case 3 it's the callout server sending AME first.
Of course beside these three cases there are other scenarios, but I think
they all deal with transaction terminations due to error conditions.
Regards
Martin