Si sta inviando un IDoc custom ad un canale receiver di tipo IDoc_AAE.
Effetto
L’invio del messaggio fallisce nel channel monitor con il seguente errore:
Error before sending due to IDoc parsing error: (7) IDOC_ERROR_PARSE_FAILURE: An IDocConversionException occurred while parsing IDocXML for type <IDoc_type>: state=READING_FIELD_VALUE_TAG, charPosition=…, lineNumber=…, columnNumber=…
Soluzione
Applicare la nota 2036878 – IDoc_AAE: Disable field datatype validation during IDoc-XML parsing che suggerisce di inserire il parametro FieldValidationEnabled fra gli Additional Parameters del canale e attribuirgli il valore false.
Il parametro disabilita il controllo del DataType dell’idoc, generato in maniera non conforme dall’adapter Idoc-AAE.
In un mapping già configurato in repository e directory, si cambia la cardinalità del messaggio da 1:1 a 1:n.
Effetto
L’esecuzione del messaggio fallisce nel channel monitor con l’errore
Adding control record to payload failed due to IDoc structure of incoming message is not correct – element IDOC has no non-whitespace child elements
Soluzione
Oltre a cambiare la cardinalità del message mapping e nell’operation mapping occorre reimportare l’operation mapping nella Interface Determination dello scenario.
Nel caso in cui l’Adapter sender non preveda il tab Content Convertion (per esempio l’SFTP) si può adottare il modulo AF_Modules/MessageTransformBean
In questo caso, il file letto
Num. Mensaje;Fecha;Error
W0051326G J20150721;20150721;Muy Sres. nuestros:
W0051326G J20150721;20150721;Nos referimos a su/s factura/s abajo relacionada/s.
W0051326G J20150721;20150721;Al objeto de verificar su conformidad, y como quiera que no
assume il seguente payload
Il canale receiver mail
I parametri della mail devono essere assunti dal mapping e quini impostare Using Mail Package.
Prerequisito perché il file in attach abbia il nome del file di turno
La Receiver Interface
Il test
Limitazioni
Se il canale sender è configurato per leggere più file, questi verranno inviati come attach in mail separate.
La presente soluzione gestisce solo file di testo e non anche file binary.
In un contesto di generazione IDoc verso ECC, occorre generare i segmenti di testo E1EDT01/E1EDT02 e/o E1EDP01/E1EDP02 partendo da una stringa in ingresso.
l’UDF splitForLength() è utile nella generazione dei segmenti di testo negli idoc sia nella sezione testata E1EDKT1/E1EDKT2 che in quella di posizione E1EDPT1/E1EDPT2
In particolare, l’UDF consente di generare tanti contesti E1ED*T2 quante sono le sottostringhe di src che si ottengono dividendola per la lunghezza ln.
E’ possibile utilizzare la function standard RFC_READ_TABLE per leggere qualunque tabella di dictionary. Di seguito, un esempio di valorizzazione per la lettura della tabella MARA.
La condizione va passata nel campo OPTIONS[]-TEXT e, se è formata da più condizioni, queste vanno concatenate in una unica stringa e relazionate con l’operatore AND.
