In a previous blog, I showed the detailed construction of a coordination act, the lowest level communicative activity in an enterprise. As outlined before, such coordination acts are part of a business transaction in which some consumer wants something from a supplier. As exceptions are common in business transactions, in this article I will show the alternative paths that exist. In the alternative paths we discern discourse that deals with ‘normal’ disagreements and revocation to deal with cancellations.
Discourse: Dealing With Disagreements
During both the order and the result phase, the initiator (customer) and executor (supplier) may disagree. Let’s take the example where I request a cup of coffee to my business partner Wiemer. As he may be busy with some Mendix project, he will not be able to produce and deliver the coffee within the next hour. Instead of promising the request, he shall now decline it. A decline leads to a so called discussion state, where the initiator and executor may discuss the reason for the decline, as well as the conditions in which the executor can make a promise. Every property of the product is open for discussion, like the amount of coffee, the kind of coffee (black, cappuccino, …), the delivery time, etc. This discussion may result in the initiator performing a changed request – after which, hopefully a promise will follow. If the involved actors do not come to an agreement on a product that can be delivered, the business transaction may be left in this discourse or discussion state.
A similar patter arises in the result phase: when the executor has declared the production, the initiator cannot only accept the result but also reject it. For example, when Marien has been given his coffee – after a long, long wait – he notices that the amount of milk is not right. He complains to Wiemer, expressing his rejection of the product. The initiator and executor can then discuss the reason for rejection as well as possible solutions. In some cases, the involved actors can agree on compensation in some form, for example, a lower price. In other cases, the product has to be remade, for which the revocation pattern is needed that will be explained below. In the unfortunate case that the actors do not come to an agreement, the transaction is suspended in this discourse state. This is undesirable as the initiator probably still wants the product, and the executor most likely wants to have the costs covered for the work done.
Ideally, every business transaction ends with an accept from the initiator.
In practice, it is impossible to only have successful business transactions.
Revocation: Dealing With Cancellations
Other exceptions that may occur in a business transaction are cancellations, or revocations. This can happen in the case where Wiemer notices the amount milk is not right, after the declare was already done. In such a case, the executor can revoke the declaration, after which the transaction is reverted back to the promised state, so that the product (coffee) can be remade. All other coordination acts can be revoked as well. For example, after having made the request for coffee, Marien thinks he would actually like some tea, as he already had too much coffee that day. He can then revoke the request, as if it were never performed. However, as the executor may have already promised the coffee and started producing it, it is not always as easy as revoking an act. The other party has a say whether to allow or to refuse the revocation, depending on the situation.
Deciding whether or not the revocation is possible, holds for every coordination act. The party that acted as performer of the coordination act can revoke the act, and the addressee can then decide on the response. When the addressee allows the revoke, the transaction is set back to the state before that coordination act was performed. If the addressee refuses the revoke, the transaction continues as normal. An allow revoke is more likely before the executor has started working on the product, as opposed to later in the process, and may come with some other agreements such as (partial) payment. A refuse revoke is more likely later in the process, but may result in an unhappy customer that does not want to pay. Therefore, it is necessary to consider well both before performing a revoke as well as before responding to a revoke. As exceptions happen a lot in practice, they should be treated with exceptional care.
Benefits of Exception Handling as Part of the Transaction Pattern
The main benefit of including exceptions in the transation pattern is that immediately all possible exceptions are covered. Instead of having to think of and design exceptions in the process, it now becomes merely a case of deciding how to deal with a reject and under which circumstances a revocation is allowed. The transaction pattern covers all possible exceptions that may or may not happen in practice. It is up to the implementation to decide how to support all these exceptions. Not supporting all possible exceptions may result in the famous ‘computer says no’, or worse (article in Dutch).
This Post Has 0 Comments