Con TIM Open puoi partecipare alla community degli sviluppatori, pubblicare le tue soluzioni su TIM Digital Store, utilizzare e rivendere i servizi di TIM.

Guarda anche

Guida Syndication


Fai click qui per scaricare il PDF



Obiettivo

Questo documento descrive le modalità di interfacciamento a disposizione di un fornitore per la commercializzazione dei propri servizi su DigitalStore e/o DigitalStore Sales APP.

Il servizio sarà fruito dal cliente sulla piattaforma di servizio del fornitore integrata tramite la soluzione ASP-SDS con la piattaforma Odin.

La piattaforma Odin sottende la vendita on line dei servizi cloud su DigitalStore e/o DigitalStore Sales APP, gestendone l’acquisto, il change, la cessazione e il billing.


La soluzione di integrazione APS-SDS prevede l’adozione di una interfaccia standard per lo scambio di richieste tra la piattaforma Odin e quella del fornitore erogante il servizio, senza la necessità di sviluppare un APS specifico di integrazione (Application Packaging Standard).


Il fornitore dovrà adeguarsi agli standard previsto dalla soluzione.

Target

Il documento intende fornire le linee guida, ai fornitori di Telecomitalia, per l’onboarding del proprio servizio sulla piattaforma Odin tramite la soluzione APS-SDS.

Termini e abbreviazioni

Piattaforma Cloud Automation (Odin)

Sistema web based usato dai service providers worldwide per automatizzare il ciclo di vita della propria offerta : delivering, gestione e billing

Piattaforma Esterna di Servizio

Piattaforma esterna ad ODIN , erogante il  servizio del fornitore pubblicato dal provider

Servizio Syndicate

Servizio pubblicato e venduto su ODIN ma erogato su piattaforma esterna del fornitore di servizio

Marketplace

Sistema web based, integrato con Odin , disponibile ai clienti per l’acquisto dei Servizi Cloud di Telecomitalia

DigitalStore Sales App

DigitalStore Sales App, sistema web based , integrato con Odin disponibile agli agenti di telecomitalia per la vendita dei Servizi Cloud di Telecomitalia  

Integrazione SDS

Syndicated Delivery Solution   , modalità di interfacciamento tra Odin e le piattaforme esterne di  servizio per il delivery dei servizi

Provider

Il Provider è il gestore della piattaforma di Cloud Automation

Fornitore

Il fornitore è l’ISV che eroga il servizio venduto sulla piattaforma del Provider

Service Plan

Il service plan contiene le configurazioni incluse in un profilo di offerta compreso i prezzi di ciascun elemento costituente l’offerta

Customer, Subscriber

Singolo Cliente o azienda che acquista dei servizi dal Provider

Service User

End-user di un particolare Servizio deliverato per il Customer attraverso Odin.

Customer Control Panel (CCP)

Pannello di controllo web-based per il Customer

OOB

Out Of the Box behavior

Sales Order (SO)

L’ SO è l’ordine di primo acquisto di un servizio, contiene il dettaglio degli elementi da deliverare in fase di primo acquisto ovvero i Provisioning Item (PI).

Provisioning Item (PI)

Il Provisioning Item è l’elemento granulare di un ordine e descrive la richiesta elementare di delivery verso la piattaforma esterna

Provisioning Queue

Sono raggruppamenti di provisioning Item, accessibili dai fornitori per la gestione dell’esito delle attività di provisioning.

Subscription

La sottoscrizione è l’istanza di acquisto di un profilo di servizio da parte di un cliente. E’ identificata univocamente in piattaforma dall’ ID e contiene la consistenza del servizio del cliente.

La sottoscrizione è creata a fronte di un provisiong item contenuto in un Sales Order.

Subscription Period

Il subscription period è il periodo di validità contrattuale di una sottoscrizione , terminato il quale la sottoscrizione deve essere rinnovata (in automatico o manualmente) per continuare ad essere attiva

Change Order (CH )

Il CH è l’ordine di change di un servizio, corrisponde alla richiesta di cambiamento di 1 sola sottoscrizione

Cancellation Order (CL)

Il CL è l’ordine di cancellazione di un servizio corrisponde alla richiesta di cancellazione di 1 sola sottoscrizione

Hold Period

L’Hold Period è l’intervallo di tempo, configurato in piattaforma, che definisce dopo quanto tempo dopo una richiesta di cancellazione debba essere fatta l’effettiva rimozione del servizio di un cliente e dei sui dati , se presenti



Modello di integrazione Syndication APS-SDS


La soluzione APS-SDS introduce degli elementi di semplificazione nel  processo standard di onboarding di un servizio sulla piattaforma Odin, offrendo una strategia di GTM aggressiva e garantita nei tempi.

La soluzione APS-SDS, a differenza dell’APS standard, consente alla piattaforma ODIN la gestione del ciclo di vita dei servizi del fornitore senza eseguire operazioni dirette sulla piattaforma del servizio. In particolare la soluzione integra qualsiasi servizio del fornitore mediante uno scambio standardizzato di “richieste” tra le piattaforme.

Tutta la logica di gestione del servizio è quindi demandata alla specifica piattaforma esterna.


 



Struttura Richieste su DigitalStore


Di seguito un esempio della strutturazione di una richiesta utente sulla piattaforma ODIN, gli elementi caratterizzanti una richiesta sono :

  • accountid  : identificativo univoco del customer anagrafato, è assegnato al customer anagrafato in piattaforma al momento della creazione, tra gli attributi del customer ci sono tutti gli elementi di anagrafica, tutta l’anagrafica può essere soggetta a variazione (ad esclusione dell’accountid)
  • orderid : identificativo univoco per singola richiesta utente, le tipologie di ordine cambiano a seconda delle richieste cliente e sono riportate nella tabella sotto Tab. Tipologia Richieste
  • subsid: identificativo univoco per singola istanza di servizio acquistata da un cliente, non varia mai durante tutto il ciclo di vita del servizio, il ciclo di vita del servizio è determinato dalle richieste utente ovvero dagli ordini (SO,CH,CF..) o dagli eventi di piattaforma (Stop,Start,ChangeAnagrafica)
  • Itemid : identificativo univoco di ogni elemento di provisioning, si riferisce ad una precisa sottoscrizione ed è contenuto in un ordine, non necessariamente come unico elemento, cioè in uno stesso ordine possono esserci più items, l’ordine verrà considerato completato quando tutti gli items sono completati

 

Esempio:  ordine multiplo,  contenente  richieste di acquisto per  3 profili base + 1 risorsa aggiuntiva sul primo servizio, verranno creati in piattaforma Odin i seguenti oggetti così relazionati:


Le richieste dei clienti (acquisto, upgrade, dimissione, etc) generano in Odin Ordini di varie tipologie. Gli ordini possono essere SINGOLI se contenenti richieste riferite ad un solo servizio o multipli se contenenti più istanze di servizio (dello stesso servizio o di servizi differenti). Ogni istanza di servizio genera una sottoscrizione ogni sottoscrizione è relazionata a uno o più PROVISIONING ITEMS.

La sottoscrizione è anch’ essa identificata con un ID univoco su tutta la piattaforma ODIN e costituisce l’istanza di un servizio acquistato da un cliente.

Le richieste elementari contenute in un ordine sono dette “Provisioning Item” sono riferite ad una sottoscrizione presente nell’ordine e devono essere implementate sulla piattaforma di servizio esterna per completare gli ordini generati dai clienti.  

I Provisioning Items sono i soli elementi che il fornitore può modificare, a seguito delle operazioni che farà sulla propria piattaforma, in accordo con la tipologia dei singoli PI. 

Le attività del fornitore sui provisioning item determinano un cambiamento di stato registrato su Odin della sottoscrizione  del relativo servizio, non che dell’ordine che le contiene. Ad esempio il completamento con esito positivo di tutti i PI relazionati ad una sottoscrizione porta automaticamente la sottoscrizione in stato Active/Running e  l’ordine in stato Completed.

Tab. Tipologia Richieste


RICHIESTA


Ordine


Sottoscrizione


Provisioning Items I

Stato PI settato da ISV a richiesta completata


Stato Sottoscrizione        dopo esito PI  (*)


Stato Ordine dopo esito PI   (*)



Acquisto  Servizio

[PROVISIONING]

Creazione nuovo [SO ] Salels Order


Creazione Nuova Sottoscrizione per il servizio acquistato


Creazione nuovo PI di tipo

[New Subscription]


Completed

Active/ Running

Completed

Failed

Ordered/Not Provisioning

Failed

Incremento/decremento risorse aggiuntive al servizio

[CHANGE]


Creazione nuovo [CH ] Change Order

Modifica Sottoscrizione

Creazione nuovo PI di tipo

[Resource Upgrade]

Completed

Active/ Running

+ Configurazione VARIATA

Completed

Failed

Active/ Running

+  Configurazione INVARIATA

Failed

Cancellazione Servizio

[CANCELLATION]

Creazione nuovo [CF]  Cancellation Order

Cancellazione Sottoscrizione

Creazione nuovo PI di tipo

[Cancellation Subscription]

Completed

Terminated / Removed

Completed

Failed

Active/ Running


Failed

Rinnovo Servizio

[RENEWAL]

Creazione nuovo [RN]  Renewal Order

Rinnovo Sottoscrizione

Creazione nuovo PI di tipo

[Renewal Subscription]

Completed

Active/ Running


Completed

Failed

Terminated / Removed (dopo la scadenza dei termini di rinnovo configrata su ODIN)

Failed

Switch Plan

[SWITCHPLAN] (**)

Creazioone nuovo [CH]  Change Order

Cambio profilo di offerta della Sottoscrizione

Creazione nuovo PI di tipo

[Change Plan Period ]

Completed

Active/ Running

+

Profilo VARIATO

Completed

Failed

Active/ Running

+

Profilo INVARIATO

Failed

Sospensione Servizio (generato da piattaforma, non da cliente, quindi non genera ordini in ODIN)

[STOP] (**)

N/A

Sospensione Sottoscrizione

Creazione nuovo PI di tipo

[Stop]

Completed

Active/ Stopped


N/A

Failed

Active/ Running


N/A

Riattivazione Servizio (generato da piattaforma, non da cliente quindi non genera ordini in ODIN)

[START] (**)

N/A

Riattivazione Sottoscrizione

Creazione nuovo PI di tipo

[Start]

Completed

Active/ Running


N/A

Failed

Active/ Stopped


N/A

Change Anagrafica (generato da piattaforma, non da cliente quindi non genera ordini in ODIN)

[CHANGEACCOUNT] (**)

N/A

Cambio anagrafica cliente

Creazione nuovo PI di tipo

[ChangeAccount]

Completed

Active/ Running


N/A

Failed

Active/ Running


N/A

 

(*) il cambio stato della Sottoscrizione e dell’Ordine è pilotato da workflow di ODIN in funzione esito PI comunicato da iSV

(**) Disponibile in versioni successive

Le richieste che prevedono la comunicazione di un completamento, ovvero la chiusura di un PIpotranno riguardare le seguenti operazioni:

  • PROVISIONING– Richiesta Provisioning servizio, il completamento di questa operazione da parte dell’ ISV verrà comunicata ad ODIN tramite il  completamento di tutti i PI della relativa sottoscrizione , in automatico la sottoscrizione ordinata dal cliente verrà attivata e solo da quel momento
  • CHANGE- Modifica consistenza servizio  e modifica sottoscrizione
  • CANCELLATION– Rimozione servizio a valle della richiesta di cancellazione
  • SWICTHPLAN- Cambio profilo di offerta e sulla stessa sottoscrizione
  • RENEWAL – rinnovo sottoscrizione


Le richieste che NON prevedono la comunicazione di un completamento, ovvero la chiusura di un PIpotranno riguardare le seguenti operazioni:

  • START - Attivazione del servizio  ,riattivazione dopo sospensione per morosità
  • STOP – Sospensione servizio  per morosità
  • CHANGEACCOUNT– Modifica anagrafica customer


Di seguito una breve descrizione delle tipologie di richieste.

PROVISIONING - L’ acquisto di uno o più servizi crea una richiesta  di provisioning che il fornitore dovrà completare . Odin rimane in attesa dell’esito di completamento delle richieste (PI) per attivare la sottoscrizione e porla in stato Active/Running. Solo a partire dall’attivazione della sottoscrizione ODIN innesca il processo di billing sui canoni ricorrenti, nel caso di mancato provisioning vengono restituite le fee di setup in automatico

CHANGE -  L’ upgrade di una sottoscrizione crea una richiesta di cambiamento della consistenza di una sottoscrizione che conterrà i PI Provisioning Item da modificare . Odin rimane in attesa dell’esito delle richieste per effettuare i cambiamenti richiesti sulla sottoscrizione.

CANCELLATION - La richiesta di cancellazione di una sottoscrizione crea un Cancellation Order  (CF) . TI/TIDS non riconoscerà alcun onere al fornitore che dovrà lavorare i PI di richiesta rimozione, nessun ritardo sarà riconosciuto economicamente.

SWICTHPLAN – Se configurato, il cliente può effettuare un cambio di profilo di offerta tale attività crea una richiesta di change dove verrà indicato il profilo di origine e il profilo di destinazione.

L’ISV ha la responsabilità dell’implementazione dello switch garantendo la congruenza tra le configurazioni dei profili di origine e destinazione. In particolare dovranno essere “SEMPRE” rispettati questi criteri:


Dato: A=piano origine;B=piano destinazione
 
- Se A contiene delle risorse non previste nel piano B
  Le risorse vengono cancellate dal piano B
- Se A contiene delle risorse previste nel piano B
  Le risorse incluse+opzionali del piano A <= incluse+opzionali del piano B


RENEWAL di un servizio per un ulteriore periodo contrattuale. La richiesta di rinnovo, se configurato viene effettuato in automatico, 15 gg prima della scadenza. La richiesta di rinnovo può anche essere fatta direttamente dal cliente in qualsiasi momento della vita di una sottoscrizione, ma il rinnovo anticipato allunga il periodo contrattuale sempre a partire dalla data di scadenza del precedente periodo.


ES: Per una sottoscrizione :

               attivata il 01/06/2016 (startdate)

              con un periodo contrattuale di 1 Anno (planperiod)

              la sua data di scadenza è 01/06/2017(expirationdate) .

              In qualsiasi momento venga effettuato il rinnovo

              la nuova data di scandeza a seguito del rinnovo completato sarà sempre 01/06/2018

 


Ciclo di vita dei Provisioning Item


I Provisioning Items  costituiscono gli elementi di interfaccia tra la piattaforma Odin e la piattaforma di servizio del fornitore. L’ISV è il responsabile del ciclo di vita del PI .

Ciascun PI descrive la richiesta verso la piattaforma esterna e contiene le informazioni sull’operazione richiesta dal cliente, scomposta in operazioni più elementari da eseguire nell’ordine indicato.

Solo i PI in stato “Manual” possono essere chiusi dal fornitore che dovrà quindi farlo evolvere in uno degli stati possibili “Completed” o “Failed”.

I PI in stato “New”  sono lavorabili dal fornitore solamente dopo il completamento del PI da cui dipendono. Ad esempio il PI relativo al delivery di un piano base è in stato manual mentre i PI relativi alle risorse aggiuntive saranno in stato new, solo dopo il completamento con successo del PI relativo al piano base sarà possibile deliverare le risorse aggiuntive che nel frattempo andranno in stato manual.

Viceversa, il completamento di un PI nello stato “New”, preliminarmente al completamento del PI da cui dipende, verrà ignorata dalla piattaforma e pertanto non genera alcun passaggio di stato. Ne consegue che sarà a cura del fornitore lavorare i PI nella corretta sequenza, ovvero attendere che i PI in stato “New” transitino nello stato “Manual”, prima di procedere alla loro lavorazione.

Di seguito il ciclo di vita di un PI.




Step di configurazione APS- SDS


  1. Definizione Offerta DigitalStore
  2. Sviluppo Integrazione Syndicate

Definizione Offerta DigitalStore


  1. L’offerta può prevedere da 1 ad max di  3 profili di servizio, Offerta


  2. Profili


  3. Risorse


1.1.   nome e descrizione dell’offerta

1.2.   profili di servizio per l’offerta:  l’offerta può prevedere da 1 ad max di  3 profili di servizio.  I profili di servizio sono definiti da :

  • un piano base con un numero di risorse incluse nel primo acquisto (risorse incluse)  
  • opzioni aggiuntive al piano base , cioè disponibilità di risorse/opzioni  da acquistare successivamente (risorse opzionali)

1.3.   subscription period  per profilo di servizio:  il servizio avrà un periodo di validità di 12 mesi con rinnovo automatico

1.4.   fee per subscription period: per il subscription period   , è possibile definire le seguenti fee :

     Fee di attivazione del piano :  prezzo iniziale del piano base

    

     Fee di attivazione di ciascuna risorsa opzionale:  prezzo iniziale della risorsa

     Recurring Fee di ciascuna risorsa opzionale:  prezzo ricorrente mensile del piano base

      

      


1.5.   Notifiche al Cliente: Welcome Mail a cura del ISV

 


Definizione Parametri Servizio

 

Sviluppo integrazione Syndicate


La modalità di interfacciamento Syndicate prevede 3 steps obbligatori per la lavorazione di una richiesta, in sequenza ASINCRONA .

ODIN invocherà un ws esposto dall’ISV al verificarsi di un evento di interesse dell’ISV, innescando il flusso di operation per l’espletamento delle richieste, come da diagramma sotto




Step

REQUEST

RESPONSE

4

ODIN invoca ws dell’ISV  per l’invio dell’ID della subscription su cui è fatta richiesta

L’ISV ritorna ad ODIN un codice di ritorno per ricezione richiesta


5

L’ISV invoca  ws ODIN per la richiesta dettaglio PI della subscription ricevuta allo step1

ODIN ritorna il dettaglio della richiesta per la sottoscrizione ricevuta in input

7

L’ISV invoca ws ODIN  per impostare lo stato dei PI della richiesta

ODIN ritorna un codice di ritorno per esito impostazione



Requisiti ISV per Integrazione:

  1. Disponibilità ws POKE esposto dal fornitore:
    1. raggiungibile via internet  alla BaseURL indicata dall’ISV in fase di configurazione servizio
    2. compliant alle linee guida di sviluppo sotto riportate.
  2. Disponibilità procedure automatiche di elaborazione richieste  : PROVISIONING ; CHANGE ; CANCELLATION ; SWICTHPLAN ; RENEWAL ; START ; STOP ; CHANGEACCOUNT innescate dalle richieste ricevute via POKE
  3. Disponibilità credenziali di autenticazione per invocazione ws  esposti da ODIN , rilasciate all’ISV in fase di registrazione
  4. Raggiungibilità ws ODIN esposti su internet


WS integrazione syndicated


 I webservices della soluzione Syndicate sono standard REST   e usano strutture JSON per lo scambio di dati.

 Se possibile , in ambiente di produzione per i ws esposti dal fornitore deve essere previsto l’uso di un  certificato per https e prevedere un access list su base IP dei chiamanti.

 Access list IP piattaforma ODIN da autorizzare alle WS POKE:


Collaudo

156.54.48.13 ; 156.54.48.30

Produzione

62.77.52.84 ; 62.77.52.86; 156.54.48.28


I ws disponibili per l’integrazione nella modalità syndicate sono:

ISV::WS::POKE Sviluppato ed esposto obbligatoriamente dall’ISV . Gli consentirà di essere attivato in caso di richieste di operation sulle sottoscrizioni dei propri servizi.

ODIN::WS:: getOItembySubs  consente all’ISV la retrieve di tutte le informazioni di dettaglio della richiesta di operation (OITEM) sulla sottoscrizione  di cui ha ricevuto notifica tramite ws:poke

ODIN::WS::setOItemStatus consente all’ISV di comunicare ad ODIN l’esito delle operazioni per il provisioningitem ricevuto da ODIN tramite il set sullo stato di ciascun OITEM

ODIN::WS:: updateServiceParam consente all’ISV di modificare i parametri di servizio della sottoscrizione se configurati.


WS Authentication & Data Segregation

Tutti I metodi esposti da ODIN prevedono l’uso dell’ Header Authentication , la user e la password nell’ header di ciascuna richiesta consentono l’autenticazione e definiscono il perimetro dei dati di competenza.

Il contenuto completo dell’ Header dovrà contenere le seguenti informazioni di tracciabilità:

Username : Nome utente per l’accesso alla piattaforma

Password  : Pwd per l’accesso alla piattaforma

SourceSystem: Sistema da cui proviene la richiesta

InteractionTime: Data e ora di invocazione del servizi [AAAA-MM-GG HH:MM:SS.d]


Nota: le credenziali da usare per accedere ai webservices esposti da Odin sono recapitate via mail all'utenza registrata come Admin dell'azienda nel momento in cui viene richiesta la pubblicazione della prima App. In caso di problemi sulla ricezione dell'utenza o per richiedere il reset della password è necessario contattare il supporto TIM Open.


WS::poke (ISV)

 

La struttura del ws esposto dall’ISV deve essere compliant a questa documentazione

 

POST

/nsrequest/poke

    Invia all’ISv una notifica di presenza richiesta operation su una sottoscrizione



{
            subsid (string,required),
            reqtype (string, required
}


Invocato da ODIN per ogni sottoscrizione presente nella richiesta di interesse dell’ISV dovrà prevedere

 

parameters:

subsid           :  identificativo della sottoscrizione/servizio a cui si riferisce l’evento

reqtype           può assumere I seguenti valori PROVISIONING ; CHANGE ;SWITCHPLAN;    CANCEL ; RENEWAL ; START(*) ; STOP(*) ; CHANGEACCOUNT(*)       



PROVISIONING

richiesta nuova istanza di servizio

CHANGE

modifica della configurazione di un servizio esistente (es. richiesta aggiunta risorse opzionali)

SWITCHPLAN

Cambio di profilo commerciale e/o tecnico sulla stessa istanza di servizio

RENEWAL

rinnovo sottoscrizione servizio

CANCELLATION

cancellazione di una istanza di servizio

STOP (*)

stop istanza di servizio

START (*)

start istanza di servizio

CHANGEACCOUNT (*)

cambio dati anagrafici customer del servizio

                                        

(*)  non disponibili in questa versione

 

 

response Standard HTTP Status code

 


WS::getOItembySubs

 

GET

https://tidsapi.tidigitalsolutions.it/sds/subscriptions/{subsid}/items

    Retrieve Provisionig Items for subscription

   

{
subsid (string,required)
}


parameters:

subsid :  identificativo della sottoscrizione/servizio di cui richiedere il dettaglio degli items da lavorare

 

response Standard HTTP Status code


response body

getOItembySubsDTO{
	customerattributes(customerattributesDTO,required),
	subscription(subscriptionDTO,required),
}


customerattributesDTO{
	VendorID(string, required),    
	AccountID(integer,required),
    CompanyName (string,required),
    Address (string,required),
	City (string,required),
    Province (string,required),
    Zip (string,required),
	Country (string,required),
	Nome (string,required),
    Cognome (string,required),
    Email (string,required),
    Tel (string,required),
    TaxRegID (string,required),
	CF (string, optional),
	PIVA (string, optional),
	CreationDate (string,required),
	Status (string,required)
}


subscriptionDTO{
	subsid(string, required),
	plan(string, required),                
	planperiod(string, required),    
	expirationdate(string, optional),            
	planname(string, required),      
	serviceparameters (Array[serviceparametersDTO, optional),
	includedresources (Array[includedresourcesDTO, optional),
	addedresources (Array[addedresourcesDTO, optional),
	provisioningitems(itemsDTO, required),
}


serviceparametersDTO{
	<idparameter>(string,required),
    … each parameter define in service configuration
}


includedresourcesDTO{
	resource(resourceDTO,required)
	…each included resource define in service configuration
}


addedresourcesDTO{
	resource(resourceDTO,required)
	…each additional resource define in service configuration
}


resourceDTO{
	name (string,required),
	quantity (integer,required),
	id (string,required)
}


itemsDTO{
	item(itemDTO,required)
}


itemDTO{
	itemid (string,required)
	orderid (string,optional)
	status (string,required)
	request (string,required)
	typeid (integer,required)
	type (string,required)
	resource (resourceDTO,optional)
	targetplan (integer,optional)
}



Di seguito il contenuto la descrizione del contenuto informativo del response:

 

customerattributesDTO

Dati del  customer che sottoscrive il servizio. Ogni attributo eccetto l’accountID può subire modifiche durante il ciclo di vita del customer.
VendorIDè l’identificativo univoco del rivenditore che ha venduto la sottoscrizione . Solo nel caso di TI contiene una stringa negli altri casi contiene un codice

AccountID

Identificativo univoco del customer che sottoscrive il servizio

TaxRegID

Codice Fiscale o PI (viene garantita solo la validità formale, non c’è alcun controllo di esistenza)

CFCodice Fiscale (viene garantita solo la validità formale, non c’è alcun controllo di esistenza)
PIPartita IVA (viene garantita solo la validità formale, non c’è alcun controllo di esistenza)

CompanyName

Ragione Sociale

Nome

Nome

Cognome

Cognome

Email

Email (viene garantita solo la validità formale, attualmente non c’è alcun controllo di esistenza)

Tel

Tel

Address

Indirizzo

Zip

Cap

City

Comune

Province

Provincia

CreationDateData di creazione del customer (timestamp UNIX)
StatusIndica lo stato del customer (0 per clienti regolarmente attivi)

subscriptionDTO

Dati della sottoscrizione

subsid

Identificativo univoco della sottoscrizione ovvero del servizio acquistato dal customer , e identificherà tutto il ciclo di vita commerciale del servizio

plan

identificativo univoco del profilo di offerta a cui si riferisce la sottoscrizione acquistata

planperiod

Indica la durata contrattuale della sottoscrizione

expirationdate

E’ la data di scadenza della sottoscrizione, è valorizzata solo nei casi in cui la sottoscrizione è già stata attivata

Nel caso di richiesta di renewal verrà modificata in automatico da ODIN al completamento della richiesta da parte dell’ISV

planname

nome del profilo di offerta a cui si riferisce la sottoscrizione acquistata

serviceparametersDTO

Parametri associati alla sottoscrizione, se previsti e configurati per il servizio (es: dati richiesti al cliente in fase di acquisto, dati di scambio tra ODIN e ISV …)

Tali parametri possono essere definiti in fase di configurazione del servizio, dove configurare come: obbligatorio/opzionale ; da richiedere al cliente Y/N

<idparameter>

Valore del parametro di input necessario alla provisiong del servizio.

includedresourcesDTO

Risorse incluse nella la sottoscrizione, l’ISV potrebbe scegliere di specificare  per il proprio servizio delle risorse e per ciascuna indicare quante sono incluse in ciascun profilo.

Questo dato è solo informativo e consente all’ISV il ricevere la consistenza della sottoscrizione da lavorare, non fa parte della richiesta

resourceDTO

Dati di dettaglio della risorsa inclusa nella sottoscrizione

addedresourcesDTO

Risorse opzionali in consistenza, l’ISV potrebbe scegliere di specificare  per il proprio servizio delle risorse opzionali che il cliente può comprare opzionalmente oltre al piano base previsto dal profilo acquistato Questo dato è solo informativo e consente all’ISV il ricevere la consistenza della sottoscrizione da lavorare, non fa parte della richiesta

resourceDTO

Dati di dettaglio della risorsa inclusa nella sottoscrizione

resourceDTO

Dettaglio risorsa

name

Nome della risorsa

quantity

Quantità ,  può contenere un valore negativo nel caso di richiesta di Downgrade di una risorsa opzionale

id

Identificativo univoco della risorsa

itemsDTO

item di provisioning, ovvero le richieste elementari che l’ISV deve implementare sulla propria piattaforma secondo i criteri indicati nel par. “Ciclo di vita dei Provisioning Item”

itemDTO

Dati di dettaglio dell’item da implementare


itemDTO

Dettaglio richiesta elementare che l’ISV deve implemetare sulla propria piattaforma

itemid

identificativo univoco del PI , deve essere utilizzato per riferirsi a questo item nelle chiamate successive di completamento richiesta

orderid

Identificativo dell’ordine del cliente, è un campo informativo, non è valorizzato per richieste generate direttamente dalla piattaforma ODIN (es: stop o start )

status

Stato corrente del provisioning item 

request

Descrizione del provisioning item ovvero della richiesta

typeid

indica la tipologia di attività richiesta al fornitore può assumere i seguenti valori:

-          10 = Nuova istanza di servizio

-          20= Rinnovo servizio

-          40=Cancellazione Servizio

-          60 = Upgrade/downgrade di risorse

-          80= Swicth di profilo Servizio

-          (*)1000= account change

-          (*)1010= Stop

-          (*)1020= Start

(*) disponibili nella prossima release

type

descrizione dell’ attività richiesta al fornitore

resourceDTO

risorsa oggetto della richiesta, presente solo nel caso di typeid=60 ovvero richiesta di upgrade/dowgrade risorsa

targetplan

Identificativo del profilo di offerta di destinazione nell’operazione di switch plan, presente solo nel caso di typeid=80 richiesta di modifica del profilo di offerta


WS:: setOItemStatus

 

{
itemid (string,required),
status (integer,required),
comment (string,required),
}


parameters

itemid               : identificativo del provisioningitem da chiudere

status                : 1 =provisioning effettuato con successo / 0= provisioning fallito

comment         : stringa da utilizzare per tracciare informazioni utili al supporto, specie in caso di fallimento dell’operation richiesta


response: Standard HTTP Status code


response body


{
result (string,required),
message(string, optional)
}

result

Esito dell'operazione

message

Messaggio relativo a info o errore



WS:: updateServiceParam 

 

{
subsid (string,required),
id (string,required),
value (string,required),
}


parameters

subsid  : identificativo della sottoscrizione su cui modificare

id           : identificativo del parametro , univoco per sottoscrizione ,da chiudere

value   : nuovo valore parametro

 

response Standard HTTP Status code


{
response_code (integer,required),
message (string,required),
}

response_code

0  => operazione effettuata con successo

99=> Unauthorized

1=> Invalid input format

10=> Not found valid role for user

Lo user utilizzato nell’autenticazione non ha I privilege necessari per effettuare l’operazione

11=> Not found role definition

Lo user utilizzato nell’autenticazione non ha I privilege necessari per effettuare l’operazione

12=> Not allowed to work this plan

13=> Subscription unknown

14=>Update failed


message

Messaggio relativo a info o errore





Sezione TEST

Questa sezione di TEST consente la simulazione del Deployment della macchina virtuale con installata l’applicazione, nel modello Deploy o dei flussi di informazioni per la gestione delle richieste degli utenti tra DigitalStore e la piattaforma di erogazione del servizio, nel modello Syndication.

La pagina si popolerà automaticamente con le informazioni inserite nella sezione “Configurazione”.



Modello SYNDICATION


Nel modello Syndication, attraverso la sezione di TEST è possibile familiarizzare con le richieste che la piattaforma di erogazione del servizio dovrà realmente gestire a valle della pubblicazione sul marketplace DigitalStore.

Per ciascun Profilo di Servizio creato nella sezione “Configurazione” verrà visualizzata una sottosezione nella qual è possibile scegliere il tipo di evento ed avviare il test.

Nell’esempio in figura sono stati creati 2 profili di servizio: Basic e Advanced. 



Da DigitalStore potranno essere generate, verso la piattaforma di erogazione del servizio, fondamentalmente tre tipologie di ordini che dovranno essere necessariamente elaborati dalla piattaforma, e successivamente quest’ultima dovrà restituirne l'esito a DigitalStore.




Tale esito potrà essere positivo o negativo: l'esito positivo porterà al completamento del relativo ordine su DigitalStore, l'esito negativo sarà preso in carico dal backoffice (e potrà poi portare o alla correzione e relativa ri-sottomissione dell'ordine o alla cancellazione dell'ordine se irrecuperabile).

Oltre a verificare le informazioni da e verso DigitalStore, è possibile inserire la url dell’endpoint su cui ricevere direttamente i "poke" relativi ai diversi eventi simulati, in modo da verificare la capacità della piattaforma di erogazione del servizio di ricevere e "reagire" a tale evento.


TEST “Crea Servizio”

Per simulare un nuovo acquisto su DigitalStore:

  1. Dal menù a tendina "Ordine" selezionare “Crea Servizio”
  2. (opzionale) inserire la url dell’endpoint (si consiglia di inserire ove disponibile l’endpoint di collaudo)
  3. Avviare il test selezionato con il tasto "Esegui"



Cliccando il tasto "Esegui", verrà richiesto a DigitalStore di generare un test case. Il contenuto del test è casuale (ad es. la quantità di risorse ordinate potrà essere variabile, etc.), ma sempre relativo al profilo di servizio selezionato.

Il test case di acquisto genererà su DigitalStore la creazione di:

  1. una nuova subscription
  2. di un nuovo ordine di “acquisto” relativo alla subscription creata (1)
  3. provisioning items relativi all’ordine
  4. la chiamata al web service “poke” dell’interfaccia di TEST, e dell’endpoint se è stato popolato il campo url

La chiamata “poke” innesca dall’interfaccia di TEST (e dovrebbe innescare anche dall’endpoint, come meglio descritto nella guida specifica), l'interrogazione "getItems" verso DigitalStore sulla subscription appena generata e contenuta appunto nel payload “poke”. L’id della subscription verrà mostrato sull’interfaccia. Come esito del “getItems” verranno mostrati: nel riquadro “Provisioning Info” i dati del cliente “fittizio” e dei parametri della subscription e, già formattati in una tabella, gli items contenuti nell'ordine (è possibile vederne anche la struttura “raw” attraverso il tasto “show”):



Il test "Crea Servizio" vedrà sempre come primo item un item di tipo "New subscription", mentre gli altri items, se presenti, saranno di tipo "Resource Upgrade", con quantità positive.

Sarà possibile, sempre attraverso l’interfaccia di TEST, dare riscontro a DigitalStore relativamente all’ordine generato dal caso di test, compilando i due campi "Esito" e "Note" e cliccando il tasto "Set item status". Così facendo la pagina di test darà, in sostituzione dell’endpoint del servizio, il comando "setItemStatus" a DigitalStore.

Per ciascuna azione di “set item status”, l’item sparisce in quanto non è più lavorabile. L’ordine sarà completato (positivamente o negativamente) solo quando saranno scomparsi tutti gli items dell'ordine.

Per verificare lo stato dei diversi items su una certa subscription è necessario cliccare sul tasto "Aggiorna" (selezionandola nella tendina superiore, senza cliccare però "Esegui", che genererebbe un nuovo test).


TEST “Upgrade Servizio”

Per simulare un upgrade/downgrade da DigitalStore di una/più risorse su un servizio esistente:

  1. Dal menù a tendina "Ordine" selezionare “Upgrade Servizio”
  2. Selezionare l’id della subscription già attiva su cui generare il relativo test
  3. (opzionale) inserire la url dell’endpoint (si consiglia di inserire ove disponibile l’endpoint di collaudo)
  4. Avviare il test selezionato con il tasto "Esegui"



Cliccando il tasto "Esegui", verrà richiesto a DigitalStore di generare un test case. Il contenuto del test è casuale (ad es. la quantità di risorse ordinate potrà essere variabile, etc.), ma sempre relativo al profilo di servizio selezionato.



Il test case di upgrade/downgrade genererà su DigitalStore la creazione di:

  1. di un nuovo ordine di “change” relativo alla subscription selezionata
  2. provisioning items relativi all’ordine, tutti gli item saranno di tipo "Resource Upgrade" con quantità positive o negative
  3. la chiamata al web service “poke” dell’interfaccia di TEST, e dell’endpoint se è stato popolato il campo url

La chiamata “poke” innesca dall’interfaccia di TEST, (e dovrebbe innescare anche dall’endpoint, come meglio descritto nella guida specifica), l'interrogazione "getItems" verso DigitalStore sulla subscription interessata. Inoltre come esito del “getItems” verranno mostrati analogamente al caso precedente, le informazioni comuni di provisioning e la tabella degli items:



Sarà possibile, sempre attraverso l’interfaccia di TEST, dare riscontro a DigitalStore relativamente all’ordine generato dal caso di test, compilando i due campi "Esito" e "Note" e cliccando il tasto "Set item status". Così facendo la pagina di test darà, in sostituzione dell’endpoint del servizio, il comando "setItemStatus" a DigitalStore.

Per ciascuna azione di “set item status”, l’item sparisce in quanto non è più lavorabile. L’ordine sarà completato (positivamente o negativamente) solo quando saranno scomparsi tutti gli items dell'ordine.

Per verificare lo stato dei diversi items su una certa subscription  è necessario cliccare sul tasto "Aggiorna" (selezionandola nella tendina superiore, senza cliccare però "Esegui", che genererebbe un nuovo test).


TEST “Cancella Servizio”

Per simulare una cancellazione da DigitalStore di un servizio esistente:

  1. Dal menù a tendina "Ordine" selezionare “Cancella Servizio”
  2. Selezionare l’id della subscription già attiva su cui generare il relativo test
  3. (opzionale) inserire la url dell’endpoint (si consiglia di inserire ove disponibile l’endpoint di collaudo)
  4. Avviare il test selezionato con il tasto "Esegui"



Cliccando il tasto "Esegui", verrà richiesto a DigitalStore di generare un test case.



Il test case di cancellazione genererà su DigitalStore la creazione di:

  1. di un nuovo ordine di “cancel” relativo alla subscription selezionata
  2. un unico item di tipo "Cancellation subscription"
  3. la chiamata al web service “poke” dell’interfaccia di TEST, e dell’endpoint se è stato popolato il campo url

La chiamata “poke” innesca dall’interfaccia di TEST, (e dovrebbe innescare anche dall’endpoint, come meglio descritto nella guida specifica), l'interrogazione "getItems" verso DigitalStore sulla subscription interessata. Inoltre come esito del “getItems” verranno mostrati analogamente al caso precedente, le informazioni comuni di provisioning e la tabella degli items:



Sarà possibile, sempre attraverso l’interfaccia di TEST, dare riscontro a DigitalStore relativamente all’ordine generato dal caso di test, compilando i due campi "Esito" e "Note" e cliccando il tasto "Set item status". Così facendo la pagina di test darà, in sostituzione dell’endpoint del servizio, il comando "setItemStatus" a DigitalStore.

Per ciascuna azione di “set item status”, l’item sparisce in quanto non è più lavorabile. L’ordine sarà completato (positivamente o negativamente) solo quando saranno scomparsi tutti gli items dell'ordine.

Per verificare lo stato dei diversi items su una certa subscription è necessario cliccare sul tasto "Aggiorna" (selezionandola nella tendina superiore, senza cliccare però "Esegui", che genererebbe un nuovo test).


Sequenza TEST

La sequenza di test "naturale" è quella in cui si ha:

  1. prima un acquisto -> Crea Servizio
  2. poi una o più variazioni (o anche nessuna...) sulla subscription creata al passo 1 -> Upgrade Servizio
  3. infine la cancellazione della subscription -> Cancella Servizio

Alcune regole di base:

  • Non è concesso aprire un nuovo ordine su una stessa subscription se il precedente è ancora aperto (oppure è fallito, e non rilavorato).
  • Non è necessario concludere una sequenza su una subscription prima di crearne un'altra, puoi certamente crearne più d'una e "intrecciarne" le richieste, simulando la normale attività casuale dei clienti.

Dopo aver familiarizzato con queste entità: ordine, subscription, provisioning item, è possibile procedere ad uno stadio più avanzato di test, in cui è possibile non usare più questa pagina, anche gradualmente, e provare a ricevere o interrogare direttamente dell’endpoint i servizi esposti da DigitalStore, identici a quelli che saranno utilizzati in produzione:

  1. Popolando la casella "URL" è possibile ricevere, direttamente al proprio endpoint specificato, il "poke" relativo al test selezionato al momento della creazione dell'ordine (con il tasto "Esegui"), così da verificare la capacità di ricevere e "reagire" a tale invocazione.
  2. In qualsiasi momento, è possibile invocare dal proprio endpoint direttamente il servizio "getItems" con una GET a "https://tidsapi.tidigitalsolutions.it/sds/subscriptions/<...subsid...>/items" (*)  per ricevere all’endpoint le informazioni relative all'ordine aperto su una subscription, con tutti i suoi items da lavorare.

  3. Inoltre, sugli items in stato "Manual" è possibile invocare dal proprio endpoint il servizio "setItemStatus" con una PUT a "https://tidsapi.tidigitalsolutions.it/sds/subscriptions/<...subsid...>/items/<...itemid>" (*)  per impostarne l'esito.


I due servizi esposti da DigitalStore sono autenticati (è necessario utilizzare la basic authentication, protetta da https, con la stessa username/password con cui accedi a DigitalStore/TIM Open).

Gradualmente quindi sarà possibile abbandonare questa interfaccia grafica (ad eccezione del primo passo di creazione del test-case, che simula quanto fatto da un ipotetico cliente) ed eseguire dei test dialogando direttamente con DigitalStore, in maniera del tutto identica a quanto accadrà poi in produzione.

(*): queste url sono quelle provvisiorie nella fase pilota, saranno poi sostituite con le definitive al rilascio del portale TimOpen in produzione.