link to the backoffice documentation

2 files changed, 4 insertions, 287 deletions

diff --git a/php/doc/tutorial.texi b/php/doc/tutorial.texi
index bb445cd..f410f26 100644
--- a/php/doc/tutorial.texi
+++ b/php/doc/tutorial.texi
@@ -416,149 +416,9 @@ anything goes wrong, the wallet will handle the respective error.
 @node Back-office-integration
 @chapter Integration with the back office
 
-This chapter shows how to implement the back office Web interface.
+Taler ships the back-office feature as a stand-alone Web application.
+See how to run it, on its own documentaion: @url{https://docs.taler.net/backoffice/html/manual.html}.
 
-We will use the term @emph{transaction} to refer to the business
-transaction that a merchant has with a customer (and the related
-communication with the Taler exchange for payment), and the term
-@emph{wire transfer} to refer to the exchange settling its accounts
-with the merchant.
-
-However, from the frontend's perspective, any transaction is denoted
-by the @emph{order id} contained in the proposal that led to the
-transaction.
-
-Given that Taler deals with microtransactions, not every customer
-payment processed with Taler will necessarily correspond to a wire
-transfer.  The Taler exchange may aggregate multiple payments from
-transactions into one larger wire transfer.  The @var{refund_deadline}
-and the @var{pay_deadline} values in the contract specify the
-timeframes within which the exchange is permitted to perform such
-aggregations, see @ref{The Taler proposal format}.
-
-In this chapter, we will see how a merchant can obtain the
-mapping from transactions to wire transfers and vice versa.
-Additionally, we will describe how to obtain a list of all
-transactions known to the backend.
-
-@section Entry page
-
-Given this charge, the back office's main tasks are:
-
-@itemize
-@item
-Allow the back office operator to specify a order id, and display the
-corresponding wire transfer identifiers.
-@item
-Allow the back office operator to specify a wire transfer ID, and
-display all of the corresponding order ids.
-@item
-Allow the back office operator to obtain a list of all transactions.
-@end itemize
-
-We implement these with a simple HTML form. For simplicity, we have
-one single page for gathering input data for both tracking directions:
-
-@smallexample
-// php/backoffice.html
-@verbatiminclude ../backoffice.html
-@end smallexample
-
-The imported script @code{history.js} is responsible for dynamically
-get the list of known transactions.  See below.
-
-@section Tracking a transaction
-
-The @code{track-transaction.php} script is now responsible for taking
-all the URL query parameter and use them on the @code{/track/transaction}
-request to the backend, see @url{http://api.taler.net/api-merchant.html#get--track-transaction}.
-The parameters are the @emph{order_id} and the @emph{instance} (see @ref{Instances})
-of this merchant.
-Note that the backend may then request this information from the
-exchange, or retrieve it from its own cache if it has already obtained
-it.  The backend will also check signatures from the exchange, persist
-the information obtained, and complain if the exchange ever changes
-its facts in an inconsistent manner.
-
-@smallexample
-// php/track-transaction.php
-@verbatiminclude ../track-transaction.php
-@end smallexample
-
-If the backend returned an HTTP status code @code{202} (Accepted),
-this means that the exchange simply did not yet perform the wire
-transfer. This is usually the case before @var{pay_deadline}, as the
-exchange is waiting for additional opportunities to aggregate transactions.
-In this case, we tell the user when to retry this operation later.
-
-In the @code{foreach} loop, we construct the list of all the
-wire transfers which paid back transaction @emph{order_id}.  For
-simplicity, the list will report only two values: the wire transfer
-identifier and the date when the transfer occurred. Nonetheless,
-the data returned by the backend contains more information that
-can be shown to the user.
-
-@section Tracking a wire transfer
-
-To track a wire transfer, the frontend just needs to forward the request
-it got from the Web form, to the backend.
-Again, the backend may request missing information from the exchange,
-verify signatures, persist the result and complain if there are
-inconsistencies.
-
-In the case that the backend detects inconsistencies, an HTTP status
-code of @code{402} is returned.  In this case, we report this
-situation to the user, who should now report this situation to the
-exchange's auditors as the exchange is misbehaving.
-
-In the usual case where everything went fine, we first output the
-amount that was supposed to have been transfered under the given
-@code{wtid}, and when it was performed (according to the exchange).
-Finally, in the @code{foreach} loop, we construct the list of the
-order ids paid by the wire transfer:
-
-@smallexample
-@verbatiminclude ../track-transfer.php
-@end smallexample
-
-
-@node History
-@section Listing all transactions
-
-In order to track transactions, order ids are needed as input.
-To that purpose, the frontend needs to make a HTTP GET request to
-@code{/history}, which is offered by the backend.
-
-The returned data lists the transactions from the youngest back to
-the oldest.
-
-The @code{/history} API is actually more rich, as it offers the way
-to skim results based on time or on index, but that goes beyond the
-scope of this tutorial.
-
-Our example frontend implements this feature by orchestrating two
-parts:
-
-@itemize
-@item A JavaScript function, imported within @code{backoffice.html},
-      that issues the HTTP GET to @code{/history.php?instance=tutorial}
-      and modifies the current page by adding a table showing the result.
-@item The @code{history.php} script, which is in charge of serving the request
-      coming from the JavaScript. Its task is to relay that request to the
-      backend, and echo the result back.
-@end itemize
-
-See below both parts:
-
-@smallexample
-// ../history.js
-@verbatiminclude ../history.js
-@end smallexample
-
-@smallexample
-// ../history.php
-@verbatiminclude ../history.php
-@end smallexample
 
 @node Advanced topics
 @chapter Advanced topics
diff --git a/python/doc/tutorial.texi b/python/doc/tutorial.texi
index 6cd731c..0ff23ce 100644
--- a/python/doc/tutorial.texi
+++ b/python/doc/tutorial.texi
@@ -471,154 +471,11 @@ bank running at @code{https://bank.test.taler.net/}.  After that, you
 should be able to point your browser at @code{http://localhost:5000/}
 and make a donation.
 
-
-
-
-
 @node Back-office-integration
 @chapter Integration with the back office
 
-This chapter shows how to implement the back office Web interface.
-
-We will use the term @emph{transaction} to refer to the business
-transaction that a merchant has with a customer (and the related
-communication with the Taler exchange for payment), and the term
-@emph{wire transfer} to refer to the exchange settling its accounts
-with the merchant.
-
-However, from the frontend's perspective, any transaction is denoted
-by the @emph{order id} contained in the proposal that led to the
-transaction.
-
-Given that Taler deals with microtransactions, not every customer
-payment processed with Taler will necessarily correspond to a wire
-transfer.  The Taler exchange may aggregate multiple payments from
-transactions into one larger wire transfer.  The @var{refund_deadline}
-and the @var{pay_deadline} values in the contract specify the
-timeframes within which the exchange is permitted to perform such
-aggregations, see @ref{The Taler proposal format}.
-
-In this chapter, we will see how a merchant can obtain the
-mapping from transactions to wire transfers and vice versa.
-Additionally, we will describe how to obtain a list of all
-transactions known to the backend.
-
-@section Entry page
-
-Given this charge, the back office's main tasks are:
-
-@itemize
-@item
-Allow the back office operator to specify a order id, and display the
-corresponding wire transfer identifiers.
-@item
-Allow the back office operator to specify a wire transfer ID, and
-display all of the corresponding order ids.
-@item
-Allow the back office operator to obtain a list of all transactions.
-@end itemize
-
-We implement these with a simple HTML form. For simplicity, we have
-one single page for gathering input data for both tracking directions:
-
-@smallexample
-TBD.
-@end smallexample
-
-The imported script @code{history.js} is responsible for dynamically
-get the list of known transactions.  See below.
-
-@section Tracking a transaction
-
-The TBD is now responsible for taking
-all the URL query parameter and use them on the @code{/track/transaction}
-request to the backend, see @url{http://api.taler.net/api-merchant.html#get--track-transaction}.
-The parameters are the @emph{order_id} and the @emph{instance} (see @ref{Instances})
-of this merchant.
-Note that the backend may then request this information from the
-exchange, or retrieve it from its own cache if it has already obtained
-it.  The backend will also check signatures from the exchange, persist
-the information obtained, and complain if the exchange ever changes
-its facts in an inconsistent manner.
-
-@smallexample
-TBD.
-@end smallexample
-
-If the backend returned an HTTP status code @code{202} (Accepted),
-this means that the exchange simply did not yet perform the wire
-transfer. This is usually the case before @var{pay_deadline}, as the
-exchange is waiting for additional opportunities to aggregate transactions.
-In this case, we tell the user when to retry this operation later.
-
-In the @code{foreach} loop, we construct the list of all the
-wire transfers which paid back transaction @emph{order_id}.  For
-simplicity, the list will report only two values: the wire transfer
-identifier and the date when the transfer occurred. Nonetheless,
-the data returned by the backend contains more information that
-can be shown to the user.
-
-@section Tracking a wire transfer
-
-To track a wire transfer, the frontend just needs to forward the request
-it got from the Web form, to the backend.
-Again, the backend may request missing information from the exchange,
-verify signatures, persist the result and complain if there are
-inconsistencies.
-
-In the case that the backend detects inconsistencies, an HTTP status
-code of @code{402} is returned.  In this case, we report this
-situation to the user, who should now report this situation to the
-exchange's auditors as the exchange is misbehaving.
-
-In the usual case where everything went fine, we first output the
-amount that was supposed to have been transfered under the given
-@code{wtid}, and when it was performed (according to the exchange).
-Finally, in the @code{foreach} loop, we construct the list of the
-order ids paid by the wire transfer:
-
-@smallexample
-TBD.
-@end smallexample
-
-
-@node History
-@section Listing all transactions
-
-In order to track transactions, order ids are needed as input.
-To that purpose, the frontend needs to make a HTTP GET request to
-@code{/history}, which is offered by the backend.
-
-The returned data lists the transactions from the youngest back to
-the oldest.
-
-The @code{/history} API is actually more rich, as it offers the way
-to skim results based on time or on index, but that goes beyond the
-scope of this tutorial.
-
-Our example frontend implements this feature by orchestrating two
-parts:
-
-@itemize
-@item A JavaScript function, imported within @code{backoffice.html},
-      that issues the HTTP GET to TBD
-      and modifies the current page by adding a table showing the result.
-@item The TBD, which is in charge of serving the request
-      coming from the JavaScript. Its task is to relay that request to the
-      backend, and echo the result back.
-@end itemize
-
-See below both parts:
-
-@smallexample
-TBD
-@end smallexample
-
-@smallexample
-TBD
-@end smallexample
-
-
+Taler ships the back-office feature as a stand-alone Web application.
+See how to run it, on its own documentaion: @url{https://docs.taler.net/backoffice/html/manual.html}.
 
 @node Advanced topics
 @chapter Advanced topics