Design / Processo rispetto ai sistemi mission-critical (Web Services)

Question

Design / Processo rispetto ai sistemi mission-critical (Web Services)

#1 da (1 voti)

0

Panoramica

Per la società abc, i team sono separati in termini di applicazioni mission-critical e delle loro applicazioni estese. Ad esempio, customer xyz utilizza dati mission-critical, ma ci sono vincoli / flussi aziendali che non possono essere raggiunti con il solo sistema mission-critical. Per mantenere l'integrità dei dati (sistema mission-critical è il sistema di registrazione), i servizi Web sono stati creati per interagire con i dati mission-critical. Questi servizi Web inviano un'entità (oggetto business) rispetto al sistema mission-critical.

Dal lato mission-critical, c'è una dipendenza da alcuni strumenti di terze parti. Uno di questi strumenti accoda le chiamate al servizio Web in thread e ha la possibilità di rifiutare le chiamate al servizio web in attesa o nuove. Rifiuto che significa che i dati non sono stati inclusi nel sistema di destinazione. Sebbene non abbia ottenuto chiarimenti su tutti i criteri, vengono utilizzate le preoccupazioni tipiche, come i grandi set di dati, il traffico di rete o i blocchi del database.

Richiesta cliente

Come indicato sopra, l'applicazione estesa dovrebbe fornire funzionalità più in linea con i flussi di lavoro previsti. È stata effettuata una richiesta per modificare in blocco i dati dell'applicazione estesa, ad esempio il fornitore x è stato acquistato dal fornitore w in modo che tutte le transazioni correnti in corso debbano essere mappate / impostate sul nuovo fornitore. In questo caso, ci possono essere record 1 - n che devono essere modificati e ogni record non può esistere insieme come un'unica entità nel sistema mission-critical.

L'ultimo passaggio a questo processo sarebbe caricare i dati modificati nel sistema mission-critical, perché i sistemi esterni (contabilità, fornitori, ecc.) hanno l'obbligo di utilizzare solo i dati di quel sistema.

Note

C'è la possibilità di ottenere un servizio web personalizzato, ma ci sarebbe comunque un problema se lo strumento di terze parti decidesse di rifiutare la chiamata dopo che è stata determinata una chiamata al servizio web di successo.

Esistono processi in cui i dati di massa vengono esportati in file (CSV o foglio di calcolo), ma l'uso è stato focalizzato su dati che vanno al di fuori dell'azienda. Se un servizio web può accettare un file, allora c'è il problema del rigetto. Se è possibile utilizzare un batch / ETL, esiste un rischio con l'integrità dei dati, poiché ciò creerebbe un ramo diverso per manipolare i dati che non rientrano nel contesto del sistema mission-critical.

Un'idea era stata gettata in giro per mettere in coda le voci di dati nella nostra area di staging / transazione, in modo che potessimo ancora caricare attraverso il servizio web e tenere traccia, se non fosse stato completamente elaborato. La preoccupazione di questa idea è il traffico di rete. (EX: 1000 voci sono state aggiornate e questi dati si estendono su 50 entità.Il servizio web avrà 50 chiamate da effettuare con il suo formato corrente.)

Domande

Per il design:

Dove si adatta la manipolazione dei dati di massa in relazione alla richiesta del cliente?

Il sistema mission-critical dovrebbe definire un modo per accettare i dati collettivi?

Questo dovrebbe essere solo la responsabilità del team associato all'applicazione estesa? (EX: Definire un processo "ragionevole" per il cliente rispetto a come viene mantenuta l'integrità dei dati, oppure definire aree di staging / transazione con qualche tipo di lavoro che trasmette solo i dati tramite chiamate al servizio web)

Con l'attuale struttura aziendale (molti team per gestire i sottoinsiemi), cosa potrebbe essere aggiunto al processo di un singolo team per aiutare con future richieste di funzionalità a un livello simile a quello precedente? (richiede l'incrocio con l'integrità dei dati mission-critical)

design development-process web-services data-integrity

posta eparham7861 26.04.2018 - 07:36

fonte

1 risposta

Leggi altre domande sui tag design development-process web-services data-integrity

Iniezione dinamica di viste con PRISM e WPF Invia più tipi di record a un singolo stream Kinesis o no?

score 1 · Accepted Answer

Dovresti utilizzare una libreria di terze parti o creare il tuo sistema che immediatamente scrive su un database prima di tentare qualsiasi altra cosa. Se qualcosa va storto, hai ancora quell'informazione salvata da qualche parte per il recupero. Idealmente riproverà ad inviare se dovesse fallire, ancora una volta, tenendo traccia dello stato sul database prima di eseguire qualsiasi azione.

Se è necessario, è possibile collegare messaggi con un identificatore comune in modo tale che se un singolo messaggio fallisce, è possibile invertire o almeno tentare di invertire tutti i messaggi con lo stesso identificatore comune nell'ordine opposto in cui verrebbe eseguito , partendo dal punto di errore e lavorando all'indietro. Ricorda sempre di tenere traccia dello stato prima tentando eventuali rollback!

Ovviamente si avrebbe il problema in cui non è possibile scrivere nel database, ma il database dovrebbe essere locale al server e, quindi, difficilmente avrà problemi di rete. C'è la possibilità che fallisca lo stesso, e se continua a fallire dopo diversi tentativi, ci dovrebbe essere almeno un ultimo sforzo per notificare a un amministratore di sistema tramite e-mail che qualcosa è seriamente sbagliato. Questa sarebbe davvero una situazione rara, in quanto dovrebbero esserci problemi sia con l'invio che con la scrittura nel database prima che si verifichi questa situazione.

Where does the bulk data manipulation fit in respect to the customer request? Should the mission-critical system define a way to accept bulk data?

Non rendere ogni aggiornamento un singolo messaggio! Ricorda che è necessario solo salvare sufficienti informazioni necessarie per ricreare la richiesta. Salvare il file csv / foglio di calcolo sul server con un nome univoco e nel messaggio, indicare il percorso sul server per ottenere il file. Stai riducendo la confusione nella coda dei messaggi e rimuovendo la complicazione necessaria per ospitare tutte le colonne e i relativi valori nel database. La parte del tuo programma responsabile per riprovare i messaggi dovrebbe anche essere in grado di elaborare csv / foglio di calcolo in tali casi e analizzarli / inviarli come sarebbe stato fatto se la richiesta fosse andata bene in primo luogo.

Should this only be the responsibility of the team associated with the extended application? (EX: Define a "reasonable" process to the customer in respect to how data integrity is maintained; Or defining staging/transaction areas with some kind of job that only passes the data via web service calls)

Il team responsabile del servizio web che riceve i dati dovrebbe avere tutto il diritto di rifiutarli qualora i dati non fossero validi. Tuttavia, ti consiglio vivamente di creare un sistema di errore standard che definisca errori comuni che potrebbero verificarsi (e potenzialmente la possibilità di errori che sono unici per quel servizio web).

Il sistema che ho definito sul mio posto di lavoro era il codice 0 per "tutto andava bene", i codici 100-199 per gli avvertimenti, 200-299 per gli errori comuni e qualsiasi cosa oltre il 1000 per i codici di errore personalizzati. Quindi, ad esempio, sai di riprovare se c'è un errore interno da parte loro, ma non riprovare se i dati sono considerati non validi.

Eviterei anche di dare garanzie al cliente. Invece di dire loro la politica che si utilizza in caso di errore, compresi i tentativi e quando vengono effettuati i tentativi, e infine qualsiasi notifica dovrebbe qualcosa non andare come previsto.

La linea di fondo è che finché scrivi al database prima di qualsiasi operazione, puoi rintracciare il punto esatto di errore per i sistemi mission-critical, e anche se non puoi garantire il successo, con questo, almeno tu può intraprendere azioni in caso di fallimento.