Integrazione aziendale: scambio di file e servizi Web

Più l'input è strutturato in modo approssimativo, più difficile sarà analizzarlo. In questo modo, XML è già strutturato in modo approssimativo. Quando ottengo il tag <price/> , mi aspetto che sia un numero, come <price>59.90</price> , ma nulla, in XML, garantisce che effettivamente riceverò un numero. Che dire di <price>USD59.90</price> o <price>59,90 €</price> o <price>I don't know what to put here because I'm lazy to read the API</price> ?

La parte interessante è che puoi convalidare l'XML con DTD. Lo stesso non vale per Excel.

Più il formato dei dati è vicino all'utente, più casuali saranno questi dati. Solo perché gli utenti apprezzano la possibilità per loro di aggiungere fogli in Excel o riordinare colonne, ecc. E si aspettano che qualsiasi parser utilizzi i dati di Excel in grado di capire ancora dove si trovano i dati e come viene salvato.

Ho dovuto lavorare su un'applicazione che ha analizzato alcuni documenti PDF. Una volta, il telefono ha suonato nel dipartimento di supporto IT. Il cliente stava urlando su come l'applicazione fa schifo: quando invia il suo PDF, l'applicazione risponde che il PDF non contiene testo. Quando il cliente ci ha finalmente inviato il PDF, abbiamo capito immediatamente che cosa non andava: era un documento scansionato senza OCR: ogni pagina conteneva solo una bitmap con il testo scansionato. Per questo cliente, era ancora testo e la nostra app avrebbe dovuto leggerlo come qualsiasi altro documento di testo.

Questa casualità rende molto difficile lavorare con quei file. In XML, ti aspetti almeno una struttura. Che cosa succede se si deve analizzare:

<product>
    <product <title>Product 1
    price="59.90
    in-stock >19<

    <product> title=Product 2
    price="Fourty nine USD ;
    inStock = 62
</products>

Questo è ancora XML e l'utente non capirebbe perché la tua stupida app non possa analizzare qualcosa di simile, mentre è molto chiaro.

Ora torniamo agli argomenti che puoi dare al tuo stakeholder senza alcun background tecnico:

1. Come verrà notificato il servizio di integrazione?

Con un servizio web, è facile. Lo invochi, inviando i dati delle risorse umane ad esso, e questo è tutto.

Con un file Excel su un'unità di rete, le cose si complicano:

• O il servizio di integrazione controlla costantemente i nuovi file su questa unità, nel qual caso ciò avrà un impatto importante in termini di larghezza di banda (inoltre, se l'unità di rete è inaffidabile, potrebbero sorgere anche più problemi),

• Oppure il servizio di integrazione deve essere richiamato dopo aver salvato il file Excel, nel qual caso invece di utilizzare direttamente il servizio Web, si sta utilizzando l'unità di rete, quindi un servizio Web.

2. Il caricamento dei dati da Excel è costoso

2. un. In termini di costi immediati

Qualsiasi linguaggio di programmazione decente può analizzare XML. Nessuno, credo, può leggere i file di Excel. Per poterli leggere, è necessario utilizzare COM di Microsoft Excel (che è limitato alla versione desktop e non può essere eseguito sul lato server) o alcuni prodotti di terze parti a pagamento.

2. b. In termini di risorse

Non ho i risultati del profiler per supportare questo, ma molto probabilmente il caricamento dei dati da un file Excel costerebbe molto di più in termini di CPU e quindi l'analisi di XML.

3. Il caricamento dei dati da Excel è soggetto a errori

I file di Excel hanno un problema: vengono modificati dagli utenti e gli utenti possono apportare qualsiasi modifica. Cosa succede se rinominano una colonna? Cosa succede se aggiungono un foglio prima di quello che devi analizzare? Cosa succede se esportano i dati di Excel in un formato che non ti aspetti?

Ecco la conclusione per lo stakeholder senza background tecnici:

Cost effective, you say?

Let's see. With the Excel on a network drive approach, you would need to develop two systems instead of one, given that one of the systems will be hugely error prone (heavily increasing the maintenance cost) and would require buying licenses and more powerful servers.

Higher infrastructure cost;
Higher development cost;
Higher maintenance cost.

Parla con loro e scopri chi si occupa veramente del lato tecnico del sistema di origine.

È improbabile che i dati siano conservati in un foglio di calcolo. È più probabile che il loro sistema abbia una funzione di "esportazione in fogli di calcolo" abbastanza semplice da usare, che è tutta la gente di cui parli.

Se è un grande cliente aziendale, probabilmente sta utilizzando un pacchetto molto costoso da uno dei fornitori di primo livello. Tutti supportano molte interfacce e dispongono di numerose funzionalità per esportare i dati su altri sistemi.

Se si passa al percorso dei file di scambio, provare ad ottenere un file di estrazione / scaricamento del database e provare a farlo generare automaticamente da "cron" o da un altro programma di pianificazione. Qualsiasi processo manuale fallirà ogni sei mesi circa.

Ho eseguito diversi sistemi che interagiscono con sistemi esterni utilizzando molti diversi meccanismi di trasporto: comunicazioni seriali, servizi Web, socket, MQ, interruzioni di file. Di tutti questi, il primo file è stato il più facile da implementare, comprendere e correggere.

Il problema è che si tratta di un modo low-tech di passare documenti e alle persone tecnologiche non piace, non quando c'è un meccanismo di accodamento transazionale, aziendale, orientato ai servizi per passare lo stesso documento in un rete!

Uno dei principali vantaggi del rilascio dei file è la possibilità di riprodurre i messaggi salvando il file manualmente. l'altro vantaggio è la registrazione: si desidera archiviare tutti i messaggi, la copia li metterà in una directory diversa. L'amministratore può anche vedere cosa è successo se le cose vanno male semplicemente leggendo il file. Sareste sorpresi di quanti sistemi mission critical utilizzino questo approccio poiché è semplice e le cose semplici tendono a funzionare in modo più affidabile.

Per le comunicazioni, è probabile che avrai ancora bisogno di un meccanismo di comunicazione "dammi tutti i dati" che guida il trasferimento di file-drop, e se questo viene implementato come un servizio web, allora puoi anche trasferire i file usando anche i servizi web. Tuttavia, il costo di implementazione per i clienti non deve essere sottovalutato.

Se, invece, trasferisci i documenti su base regolare (di notte, settimanale o ogni ora), non hai bisogno di un sistema di notifica, quando i documenti sono pronti, leggi il percorso di trasferimento e prendi tutto il documenti in attesa. Semplice. (quelli che non erano pronti, ad es. hai letto troppo presto, i documenti mancanti saranno lì per il prossimo trasferimento).

Ovviamente, puoi implementare un'API di modifica delle directory per attivare una lettura se desideri notifiche su richiesta.

Il grande vantaggio, ovviamente, è che è molto disaccoppiato. Tutto ciò che devi fare è attendere periodicamente o scrivere le tue notifiche pronte per il file. Tutto quello che il tuo cliente deve fare è scrivere un file. Il costo di implementazione è veramente minimo e qualsiasi negozio che non ha sviluppatori può farlo. Questo è probabilmente il fattore più importante nella decisione di progettazione: i tuoi clienti sono abbastanza esperti di tecnologia per scrivere codice o no.

(per i sistemi critici, ho usato un sistema di messaggistica SMS che ha accettato solo i drop di file di messaggi sms da inviare, il mio sistema ha fatto tutta l'elaborazione elaborata di solito, ma scrive i dati su un file invece di un socket o ws o mq. Dopo l'elaborazione, hanno scritto un file di stato.Dal mio PoV, era solo un altro livello di trasporto.Dal loro PoV, non dovevano lavorare con me per scrivere un canale di comunicazione connesso a 2 vie, hanno appena consegnato il exe e descritto le opzioni di configurazione).

Penso che la differenza tra le alternative sia più importante quando puoi elaborare i record del file / servizio in parallelo.

In termini generali, supponiamo che il file rappresenti un insieme di record. Supponiamo che ogni record abbia un id (in modo da poter segnalare gli errori legati a questo id) e supponiamo di poter creare un metodo thread-safe per importare un record nel sistema.

Quindi ora hai i mezzi per elaborare i record in parallelo. Ciò implica che puoi facilmente creare un metodo per il quale passi una raccolta di record - un sottoinsieme del file.

Quindi confrontiamo:
File : quando ottieni il file, puoi leggerlo in modo sequenziale e chiamare in modo asincrono il servizio di importazione per ogni gruppo di record, quindi l'elaborazione viene eseguita in parallelo.
Servizio Web : il contenuto del file viene inviato richiamando un servizio che passa un gruppo di record, un sottoinsieme del file.

Questi sono i vantaggi nella mia mente del servizio web sul trasferimento di file:

• Prestazioni: con un file sei limitato a un singolo processo che legge il file e lo elabora. Supponiamo che ci vogliono 50 ore per elaborarlo. Con un servizio è possibile ridimensionarlo in base alle esigenze: basta aggiungere server al cluster. Ad esempio con 10 server lo stesso lavoro può essere svolto in circa 5 ore.
• Prestazioni: anche utilizzando i servizi Web, qualsiasi elaborazione può essere avviata non appena il primo record è pronto (anche se non sarebbe pratico inviare una singola richiesta di registrazione. Sarebbe meglio inviare un gruppo di record per richiesta) ma con un file, l'elaborazione non può iniziare fino a molto più tardi.
• Segnalazione: durante l'elaborazione potrebbero esserci alcuni record non validi / in conflitto che è necessario comunicare nuovamente. con un trasferimento di file è necessario preoccuparsi di come comunicare il rapporto / i risultati dell'importazione. Devi inventare e investire in un altro meccanismo. Forse crei un file e consenti al cliente di scaricare questo file dei risultati. ma come faranno a sapere quando iniziare il download? Con un servizio web è sufficiente restituire una risposta contenente il rapporto. Tieni presente che il servizio web può avere una durata come la richiesta di avvio, inviare un gruppo di record in N richieste, inviare una richiesta finale che risponde con il rapporto / i risultati
• Comunicazione del contratto dati: con un file è necessario inventare un modo per comunicare al cliente la sintassi della richiesta e della risposta. Non è necessario farlo con un servizio (ci sono strumenti come Swagger che lo rendono ancora più semplice)
• Convalida del contratto di dati in anticipo: può convalidare facilmente i propri dati se si crea solo un metodo di servizio di stub.
• Privacy / Sicurezza: con il trasferimento di file c'è più potenziale per problemi di privacy che non ci sono quando si utilizza un servizio sicuro, vale a dire:
  1) una volta creato il file all'origine - qualcuno che può leggerlo / rubarlo
  2) lo stesso vale per quando il file arriva a destinazione
  3) è necessario occuparsi di trasferire il file in modo sicuro. trattare con la crittografia?
  4) potresti avere problemi di sicurezza / privacy con il rapporto resus che avresti bisogno di rispedire
• Sintassi: con un file è necessario leggere il contenuto e convalidarne la sintassi. È inoltre necessario generare la risposta in modo che sia conforme al contratto. Con un servizio il contenitore crea l'oggetto di richiesta Java dal payload prima che venga inserito il codice del servizio e crea la risposta, quindi non è necessario gestirlo e il tuo cliente
• Hai bisogno di Rilevamento file: con un file hai bisogno di un meccanismo per rilevare quando il file ha completato il suo trasferimento e pronto per essere elaborato. non hai bisogno di questo con un servizio. Inoltre, se questo meccanismo di rilevamento dei file fallisce, sei bloccato, quindi hai bisogno di un modo per resuscitarlo in caso di crash. con il servizio Web si hanno diversi server nel cluster e tutti possono elaborare questa richiesta.
• Potenziale di errore di comunicazione: più grande è il file, più è probabile che l'operazione fallisca e debba essere ripetuta
• Massive I / O di file ridondanti: con il trasferimento dei file c'è il costo di creare il file all'origine. scrivere il file dopo averlo ricevuto e aver letto il file per elaborarlo. Tutto questo tempo viene salvato se viene chiamato il servizio web.
• È necessario un meccanismo di trasferimento dei file: con il trasferimento dei file è necessario investire e fornire i mezzi per trasferire file (FTP?) soprattutto se si dispone già di un server Web.
• Reputazione: il trasferimento di file è a bassa tecnologia - fa una brutta impressione.

Basato su file:

1. Se uno dei sistemi non funziona, i dati non elaborati rimangono e alla fine sono sincronizzati.
2. Dead simple to implement.
3. Elevato rendimento.
4. Utilizza i file speciali sourcefile.trigger per segnalare che la scrittura è finita per sourcefile .
5. Test semplice del servizio clienti.
6. Ultimi dati disponibili dopo un ritardo.

Basato sui servizi Web:

1. Perdita di dati a meno che non venga utilizzato il recupero basato su timestamp o il buffer di dati
2. Gli ultimi dati sono sempre disponibili se il produttore chiama immediatamente il consumatore.

Entrambi:

1. La struttura dei file / dati deve essere rigorosamente concordata.