Come devo gestire i sink di dati esterni?

Question

Come devo gestire i sink di dati esterni?

#1 da (1 voti)

3

Recentemente ho assunto un contratto che prevede in gran parte la generazione di feed di dati dai dati del mio cliente e l'invio a partner esterni, tramite feed e invocazioni API.

Ho sempre trovato questo particolare tipo di codifica frustrante, per una serie di motivi:

Devi fare affidamento sulle specifiche, che spesso divergono dall'attuale implementazione o semplicemente non entrano in dettagli sufficienti
Hai poca o nessuna capacità di vedere nel sistema esterno, per garantire che i tuoi dati siano stati accettati e interpretati correttamente
Se c'è qualche tipo di problema con i dati che hai generato, non è sempre semplice annullare le modifiche e riprovare
Gli ambienti di testing esterni e di staging spesso divergono dalla logica di produzione e dal database di produzione

Quali sono le migliori pratiche per fare questo tipo di lavoro?

Creare mock e stub non risolverà necessariamente i miei problemi, perché la mia vera preoccupazione è: i miei feed hanno l'effetto corretto su un altro sistema, che è fondamentalmente una scatola nera? I mazzi duplicano semplicemente le mie ipotesi.

api-design data-structures

posta Bill 06.02.2012 - 01:47

fonte

1 risposta

Leggi altre domande sui tag api-design data-structures

Creazione automatica di oggetti dall'input dell'utente Retexturing un modello tramite API sul web

score 1 · Accepted Answer

Ho fatto un po 'di lavoro negli ultimi anni con EDI, e ha tutti i problemi che hai menzionato. Il problema più grande è che i partner non seguono le loro specifiche e quando lo fai notare, dicono "questa è una deviazione" ma non la documentano mai.

Ecco come mi occupo di esso e riesco a dormire la notte:

Creare un framework per la creazione e il mantenimento di numerosi test unitari. All'inizio testerai solo le specifiche più le tue ipotesi, ma alla fine (ogni volta che trovi una deviazione) devi scrivere un'altra serie di test per verificare questi nuovi fatti.
Il tuo sistema deve registrare tutto . Deve registrare tutto ciò che è successo, quando è successo, chi l'ha fatto, cosa ha ricevuto, cosa ha scritto, dove, ecc. Ne avrai bisogno quando vai in punta di piedi con la tua controparte dall'altra parte, non solo per risoluzione dei problemi, ma come prova per dimostrare che il tuo sistema sta facendo tutto ciò che deve fare. Le conferme sono particolarmente importanti per la registrazione. Questi log sono inestimabili quando vai a scrivere nuovi test.
Aumenta la capacità di riprovare con le modifiche. Quando succede qualcosa, vorrai essere in grado di modificare i dati e inviarli di nuovo.
Evita gli intermediari (ovvero "terze parti"). Purtroppo nel nostro caso abbiamo in realtà 3 diversi sistemi che i nostri dati viaggiano tra noi e la destinazione finale (due dei quali sono chiamati "rivenditori a valore aggiunto", o VAR, che è completo BS perché dal mio punto di vista non aggiungono alcun valore) . Quando qualcosa va storto, veniamo contattati dall'utilizzatore finale dall'altra parte, e poi dobbiamo salire di un livello dalla nostra parte, chiedere loro di controllare, e poi salire di livello e parlare con il loro VAR, che deve parlare con l'altro VAR, ecc. È frustrante. Se hai la capacità di comunicare direttamente con l'altro sistema, fallo.