---
tags: Mercury, DirectLink
---

# Stima progetto DirectLink via SMS

Desiderata rilascio in pre: fine Aprile

| descrizione | stima gg coppia | nuova |
|:----------------------------------------------- |:---------------:|:--------------:|
| Servizio lista terminali per merchant abilitato | 3 | 3 |
| Servizio invio DirectLink | 2 | 1 |
| Servizio ricerca DirectLink | 5 | 5 |
| Servizio invio massivo DirectLink | 5 | 1 |
| Localizzazione mail in 5 lingue | 6 | 6 |
| Servizio generazione short link per DL via SMS | 5 | 5 |
| Integrazione servizi con SMS | 8 | 8 |
| **TOTALE** | **21 + 5 + 8** | **16 + 5 + 8** |

## Aggiornamento 14/04/2020

* servizio lista terminali per merchant abilitati
* invece di un merchantId riceve un array di merchantId. Restituisce un json con elenco terminali raggruppati per merchant. Ogni merchant ha i suoi terminali

* servizio invio directLink
* va chiamata via HTTP, non via json, per utilizzare servizio così come è
* teniamo risposta in XML
* gestione degli errori rimane così come è

* servizio ricerca directLink
* deve restituire in json le stesse informazioni che al momento vengono visualizzate da backoffice
* anche in questo caso, gli errori vengono gestiti come su backoffice, e restituiti al chiamante
* quanto costa aggiungere la valuta come campo di ricerca?

* servizio invio massivo directLink
* chiamato non json, ma come adesso, con POST http
* va solo esteso per la parte SMS

* url shortener per SMS
* utilizzare servizio di google shortener
* l'url corto solo per la parte SMS

#### Servizio lista terminali per merchant abilitato

Realizzazione di un nuovo servizio web per verificare l'abilitazione di un merchant al pagamento con DirectLink.

Il servizio riceverà l'identificativo del Merchant, e dovrà restituire una lista dei terminali associati al merchant, se abilitati al DirectLink.
Per ogni terminale verranno riportate alcune informazioni, tra cui ad esempio la possibilità di gestire o meno il MultiCurrency.

#### Servizio invio DirectLink

Modifica dell'attuale servizio di invio di email contenenti DirectLink.

Il servizio, attualmente utilizzato nel solo portale di backoffice MonetaWeb, dovrà poter essere invocato dal nuovo portale Ecommerce.
Dovranno essere definiti il formato di invio dei dati dal portale al servizio, ed i messaggi di risposta del servizio.

Ad esempio, il portale invierà al servizio i dati necessari per la mail con il DirectLink (id del terminale, indirizzo email del cardHolder...), e riceverà dal servizio un messaggio di avvenuto invio della mail.

Dovranno inoltre essere definiti i messaggi da inviare a fronte di possibili scenari di errore.

Il servizio dovrà essere modificato per consentire l'invio di DirectLink via SMS. A tale scopo, dovrà essere effettuata l'integrazione con il servizio esterno esistente "SMSSender".

L'interfaccia utente dell'attuale backoffice dovrà essere modificata di conseguenza, per consentire all'operatore di selezionare il canale di invio del DirectLink (email oppure SMS) e di inserire il numero di telefono dell'utente cui inviare l'eventuale SMS.

#### Servizio di ricerca DirectLink

Modifica dell'attuale servizio di ricerca di DirectLink inviati.

Il servizio viene attualmente richiamato dal backoffice a seguito della compilazione di una apposita form di ricerca.
Il servizio dovrà ricevere i parametri di ricerca anche dal nuovo portale Ecommerce, e restituire al portale l'esito della ricerca in un formato concordato (ad esempio JSON).

In caso di errori nella ricerca (parametri mancanti, errori di sistema o altro) il servizio dovrà restituire al portale dei messaggi di errore, secondo un formato concordato.

#### Servizio di invio massivo DirectLink

Modifica dell'attuale servizio utilizzato per inviare massivamente email DirectLink mediante file CSV.

Il servizio dovrà poter ricevere un file CSV, contenente le informazioni per inviare diverse email DirectLink contemporaneamente, dal nuovo portale Ecommerce.

Il servizio restituirà l'esito dell'invio massivo, positivo o negativo. In caso di esito negativo, verrà indicato l'errore secondo un formato concordato.

Il servizio dovrà essere modificato per consentire l'invio di DirectLink via SMS, analogamente a quanto indicato nella voce "Servizio invio DirectLink".
Il file CSV, caricato dall'attuale back-office piuttosto che dal portale Ecommerce, dovrà quindi essere esteso con un nuovo campo, indicante il canale su cui inviare il DirectLink (email o SMS).

#### Mail in 5 lingue

I servizi di "invio DirectLink" ed "invio massivo DirectLink" dovranno permettere di inviare mail in cinque lingue diverse (Italiano, Inglese, Francese, Tedesco, Spagnolo).
Andranno creati, dove non già esistenti, i diversi template di email, ciascuno contenente il DirectLink.
Ogni email andrà personalizzata inoltre per indirizzare l'acquirente verso una pagina di pagamento localizzata nella lingua stessa dell'email.

#### Short link per DirectLink via SMS

Realizzazione di un servizio che restituisca una versione breve di un url di DirectLink.

Al fine di poter inserire un DirectLink in un messaggio SMS, verrà implementato un servizio che riceverà in ingresso l'indirizzo di un DirectLink, e restituirà un differente indirizzo ma con un numero ridotto di caratteri.
Lo stesso indirizzo funzionerà come un qualunque DirectLink: verrà inviato nella mail all'utente, e gli consentirà di accedere direttamente alla pagina di pagamento.

## Domande / Dubbi

* a livello di database, dove verifichiamo l'abilitazione al pagamento con DirectLink? Sul terminale (tabella `terminals`) o a livello utente (tabella `users`)?
* ci serve saperlo per comprendere la possibile richiesta Mercury di spostare l'abilitazione Merchant a livello di terminale invece che di utente (punto sollevato da Mantovani ma non molto chiaro).
* `UserAuthenticationController` => `UserAuthenticator#authenticate` => `UserRepository#findByUsernameAndMerchantId` => `UserRepository#createUserFrom` => `TerminalRepository#findByMerchantId`
* quindi **ogni `User` ha un `MerchantID` associato. Tramite il `MerchantID` si possono recuperare i `Terminals`**
* **nota:** il terminale deve essere abilitato (colonna `Enabled` a true) per essere mostrato nell'elenco terminali directLink

* in quale formato vengono restituiti adesso i dati nella response alla chiamata POST su `/monetaweb/backoffice/directlink/init`? In quale formato vanno restituiti se invocati dal nuovo portale?

* quale struttura dei dati dovrà avere il json di risposta del servizio di `/search`?

* il servizio di `/upload`dovrà rispondere al chiamante con un esisto, positivo o negativo?
* in caso positivo, quale messaggio inviamo al portale? In quale formato? Con quale struttura dati?
* in caso negativo, quali sono i possibili messaggi di errore da inviare al portale? Con quale struttura dati?

## Spike

### Spike chiamata servizio `invio directLink`

* url: `/backoffice/directlink/init`

* Funziona correttamente se chiamato previa autenticazione SSO (generate/consume token)

* es. una

POST 
/monetaweb/backoffice/directlink/init

body: id=22220000&amt=1%2C00&currencycode=978&mailLanguage=ITA_ENG&trackId=123456&customField=&description=&member=&cardholderemail=edoardo.parlato%40xpeppers.com&emailSubject=Oggetto+mail&emailAdditionalText=testo+mail+aggiuntivo

Restituisce response

<response>
<token>5zbF3AE_TTS-UgC4_k8jgwO-</token>
<msg>DirectLink mail sent</msg>
</response>

#### Punti attenzione

* `DirectLinkInitResponse#writeTo` scrive un XML suola response. Se un domani dovrà scrivere anche un Json quanto costa la modifica?

### Spike servizio `ricerca DirectLink`

* url: `/backoffice/directlink/search

* Funziona correttamente se chiamato previa autenticazione SSO (generate/consume token)

* nel `BackofficeSearchController` gli oggetti che "fanno la ricerca" sono `PaginatedCriteriaRepository` e `CriteriaGenerator`, quest'ultimo cerca eventuali errori

* `BackofficeSearchController` è costruito in `DirectLinkSearchControllerFactory`, invocato quando si atterra sul link del servizio di `/search`
* si potrebbe scegliere nel `DirectLinkSearchControllerFactory` se chiamare l'attuale `BackofficeSearchController` se la chiamata arriva da backoffice, chiamare invece che un nuovo controller in caso la chiamata arrivi dal portale ecommerce.
* il nuovo controller utilizzerebbe `PaginatedCriteriaRepository` e `CriteriaGenerator` (più gli altri collaboratori di supporto, tipo webRequest ed environment) e restituirebbe il risultato della ricerca (elenco di directLink oppure errori) in formato json
* **NOTA 1**: per l'attuale `BackOfficeSearchController` come `CriteriaGenerator` si utilizza `DirectLinkSearchForm` che estende `CriteriaForm`, che valida i dati in ingresso costruendo una `WidgetList`. **Se facciamo un nuovo controller andrebbe creato una nuova estensione di `CriteriaGenerator`**
* **NOTA 2**: il servizio che restituirà i dati in json deve restituirli paginati? In tal caso si potrebbe riutilizzare `PaginatedCriteriaRepository`

### Spike servizio `upload massivo directLink`

url: `/backoffice/directlink/upload`
...

### Spike servizio `GetListaTerminaliAbilitati(merchantID)`

`GetListaTerminaliAbilitati(merchantID)` --> (vedi gli utenti associati abilitati al DL e quindi i terminali con la proprietà della multicurrency del teminale)

digraph hierarchy {
                Merchant ->{Terminals Users}         
}          

* nuovo servizio
* query al db su più tabelle
* response in json (?)

* `DirectLink/Upload(streamCSV)` --> ritorna esito. Servizio esistente!
* definire la risposta (es. numero ricevuti, numero inviati, numero con errore)
* definire la risposta in caso di errore

* Mail in 5 lingue
* l'erogato della commessa precedente che prevedeva: creazione del campo lingua nel db, gui per invio, ricerca, template per csv e template della lingua in inglese.
* totale 10 gg (80 ore) di cui 20% di PO e 20% di analisi