[dd 36] update with SQL triggers logic

1 files changed, 43 insertions, 54 deletions

diff --git a/design-documents/036-currency-conversion-service.rst b/design-documents/036-currency-conversion-service.rst
index 72a504c5..be3a01a0 100644
--- a/design-documents/036-currency-conversion-service.rst
+++ b/design-documents/036-currency-conversion-service.rst
@@ -35,11 +35,11 @@ currency.
 Requirements
 ============
 
-* CCS must not impact the Nexus structure.
+* CCS must not impact the libeufin-nexus structure.
 * CCS must trigger Taler withdrawls every time a customer buys the
-  regional currency ('buy-in' operation).
+  regional currency ('cash-in' operation).
 * CCS must offer cash-out operations.
-* CCS should react as soon as possible to buy-in and cash-out operations.
+* CCS should react as soon as possible to cash-in and cash-out operations.
 * CCS must show its state to administrators and offer management tools.
 * CCS must link every fiat-side of a cash-out to its regional currency
   counterpart.  In particular, because every cash-out starts with a
@@ -49,60 +49,49 @@ Requirements
 Proposed Solution
 =================
 
-The following design assumes that CCS is coded into libeufin Sandbox.
+The following design assumes that CCS is coded in libeufin-bank and that 
+libeufin-bank and libeufin-nexus share the same database with separate 
+schemas. The solution relies on SQL triggers to atomically synchronise 
+cash-in and cash-out operations between the two schemas.
+
+SQL triggers and conversion operations
+--------------------------------------
+
+Libeufin-bank controls the conversion support and sets up or removes 
+conversion SQL triggers when necessary. In order for the SQL triggers to 
+perform the conversion operations, the configurable rates/fees are stored 
+in the database and the conversion operations are performed using stored 
+SQL procedures. The SQL triggers and conversion procedures are stored in 
+the libeufin-bank schema.
 
 Cash-out operation
 ------------------
 
-The libeufin Sandbox component learns instantly about a cash-out
-operation, because it's *the* service offering such feature.
-Therefore, as soon as a cash-out operation gets TAN-confirmed,
-Sandbox performs a first wire transfer from regio-user to regio-issuer
-by specifying the amount without any rates/fees applied.  Along
-the same database transaction, Sandbox stores the *instructions*
-of another payment *P* from fiat-issuer to fiat-target, but this time
-**with** the cash-out rates/fees.  Notably, P includes the **current**
-fiat-target and the rates/fees, since these are configurable.
-
-Asynchronously, a background task picks P and sends it to the fiat bank.
-Finally, fiat bank conducts P and fiat-target receives the wanted
-amount.  The same background task should also retry previous payments
-like P that failed to be submitted to fiat bank.
-
-CCS offers management endpoints for prepared fiat-transactions.
-Through them, adminisrators can see, retry, or cancel every fiat-transaction
-that was prepared to pay fiat-target.
-
-Buy-in operation
+Libeufin-bank learns instantly about a cash-out operation, because it's
+*the* service offering such feature. Therefore, as soon as a cash-out 
+operation gets TAN-confirmed, libeufin-bank performs a wire transfer from 
+regio-user to regio-issuer by specifying the amount without any rates/fees 
+applied. Along the same database transaction, a SQL trigger store the 
+*instructions* of another payment *P* from fiat-issuer to fiat-target, 
+but this time **with** the cash-out rates/fees.
+
+Asynchronously, a libeufin-nexus background task picks P and sends it to 
+the fiat bank. Finally, fiat bank conducts P and fiat-target receives the 
+wanted amount. The same libeufin-nexus background task should also retry 
+previous payments like P that failed to be submitted to fiat bank.
+
+Cash-in operation
 ----------------
 
-A buy-in operation starts as soon as the customer sends a fiat
-payment from fiat-customer to fiat-issuer.  Sandbox is responsible to
-detect such an incoming payment in a timely fashion.  The detection
-happens by long polling on the Nexus JSON API.  Nexus is ultimately
-responsible to query the fiat bank via EBICS every X seconds.  X
-should match the tightest interval allowed by the bank.
-
-When Sandbox detects one incoming payment on fiat-issuer, it applies the
-**current** buy-in rates/fees and wires the resuling amount from regio-issuer
-to regio-exchange.  At this point, Nexus detects the incoming payment on
-regio-exchange and makes the exchange aware via the Taler Wire Gateway API.
-From now on, the system proceeds like it always did in Taler.
-
-Milestones to a MVP
-===================
-
-*  Refactor configuration in Sandbox: `7527 <https://bugs.gnunet.org/view.php?id=7527>`_, `7515 <https://bugs.gnunet.org/view.php?id=7515>`_.
-*  Make rates/fees and TAN channels configurable in Sandbox: `7694 <https://bugs.gnunet.org/view.php?id=7694>`_.
-*  Long polling in Nexus to serve TWG: `6987 <https://bugs.gnunet.org/view.php?id=6987>`_, `6383 <https://bugs.gnunet.org/view.php?id=6383>`_.
-*  Long polling in Nexus to serve fiat-transactions via native API: `7693 <https://bugs.gnunet.org/view.php?id=7693>`_.
-*  Long polling in Sandbox to ask Nexus fiat-transactions via native API.
-*  Serve transactions with date ranges in Sandbox Access API: `7685 <https://bugs.gnunet.org/view.php?id=7685>`_
-*  Implement JSON-based "bank connection" in Nexus.  That's how Nexus
-   gets regio-transactions to serve in the TWG.
-*  Implement fiat-bank's EBICS flavor.
-*  Ask transactions with date ranges in such flavor in Nexus: `7686 <https://bugs.gnunet.org/view.php?id=7686>`_.
-*  Implement fiat-transactions management tools.
-
-.. note::
-  The list can be incomplete and not necessarily ordered.
+A cashin-in operation starts as soon as the customer sends a fiat
+payment from fiat-customer to fiat-issuer. 
+
+The libeufin-nexus component is responsible to query the fiat bank 
+via EBICS every X seconds. X should match the tightest interval allowed 
+by the bank.
+
+When libeufin-nexus registers an incoming payment on fiat-issuer in the 
+database, a SQL trigger applies the **current** cash-in rates/fees and 
+performs a wire transfer from regio-issuer to regio-exchange. Libeufin-bank 
+makes the exchange aware via the Taler Wire Gateway API and from now on, 
+the system proceeds like it always did in Taler.
\ No newline at end of file