Lavoro anche per una compagnia di assicurazioni (P & C, non Life). Sono abbastanza familiare con la cattiveria che è ACORD XML. Parla di qualcosa progettato dal comitato, eh? È simultaneamente prolisso (molti nodi) e vago (guida limitata su quali nodi usare per cosa) ... difficile da credere.
Il mio suggerimento sarebbe quello di costruire qualcosa come un modello di facciata dai servizi web in questione. In altre parole, si dispone di questo servizio fornitore che prevede ACORD XML per un carico utile della richiesta. I tuoi clienti non hanno bisogno di diventare esperti di ACORD - probabilmente hanno una piccola quantità di dati che raccolgono. Quindi, costruisci una facciata che accetti qualcosa che sia più facile da fornire (forse un endpoint JSON REST), trasforma i dati JSON in ACORD XML (nelle parti appropriate dell'albero dei nodi), quindi esegui un processo che "arricchisce" la pura ACORD XML in modo che sia accettabile per il tuo fornitore. Poi fai la stessa cosa al contrario sulla via del ritorno.
Avrai bisogno che il tuo componente "arricchimento" sia "basato su regole" come puoi farlo. Ad esempio, saprà che tutte le parti dell'albero dei nodi ACORD sono obbligatorie e avranno implementazioni predefinite per tutte loro. Dovrebbe anche aggiungere nodi al messaggio ACORD che spieghi con precisione cosa è stato modificato / aggiunto e perché (probabilmente vorrai creare un'interfaccia o una classe astratta implementata da ogni regola). Quindi, quando restituisci la risposta al tuo cliente, puoi dire loro tutte le decorazioni che hai fatto alla loro richiesta, che diventeranno importanti perché ti forniscono forse 10 pezzi di dati, lo stai arricchendo a 100, e vorranno sapere da dove vengono le altre 90 cose e perché.
Potresti anche voler creare una sorta di affinità tra il carico utile dell'endpoint REST e il componente di arricchimento. Quello che voglio dire è che potresti voler mettere qualcosa nell'endpoint in modo che ci sia un modo definito di "scavalcare" ciò che fa il tuo componente di arricchimento - accessibile per tornare alla richiesta dell'endpoint. In questo modo, se il tuo consumatore decide che una delle tue regole è stupida, o non applicabile, ha un po ' modo di aggirarla senza che tu faccia tutta la codifica. Potrebbe essere qualcosa di simile a un modo definito di comporre un ACORD XPath e un valore che si aggiunge alla struttura dei nodi dopo le regole sono state eseguite e un modo definito per cancellare un elenco di nodi ACORD.
Infine, assicurati di fare un buon logging nel tuo componente di arricchimento. Assicurati di avere un modo per ricostruire facilmente ciò che è successo dal punto in cui ricevi la richiesta JSON fino al punto in cui restituisci una risposta JSON al tuo consumatore. Questo tipo di registrazione a livello di transazione diventa fondamentale in questo tipo di app.
Spero che sia utile. Ho fatto cose del genere per 15 anni. Questo approccio generale ti farà risparmiare un sacco di mal di testa.