ABAP - IDoc Definizione

L‘IDoc (Intermediate Document) è un messaggio di interscambio contenente un insieme di informazioni.

L’IDoc è usualmente utilizzato per lo scambio di informazioni tra sistemi e partner indipendenti tra loro.

Le informazioni sono contenute in semplici campi, organizzati in strutture chiamate segmenti.

L’IDoc è costituito da 3 sezioni:

Un record di controllo
Uno o più record di dati relativamente al documento in elaborazione
Uno o più record di stato

E‘ importante notare che lo scambio di IDoc tra i sistemi, siano essi SAP R/3 o altri , vengono inviati solo il record di controllo ed i record dei dati. Infatti, il record di stato rimane sul sistema specifico.

La sezione di controllo rappresenta l'intestazione dell’IDoc, contiene un identificatore del IDoc, insieme con i dati relativi al sistema mittente e il sistema ricevente.

La sezione di dati contiene uno o più segmenti che sono organizzati in modo gerarchico. C'è un concetto di segmento genitore e del segmento bambino, un concetto in cui il segmento bambino potrebbe non esistere se il segmento superiore genitore non esiste nella gerarchia.

Questa sezione è la più importante, perché, come è implicito nel suo nome, è questa sezione che contiene i dati dell'applicazione da trasmettere.

La sezione di stato è specifico al sistema in cui viene visualizzato l'IDoc. Infatti, dopo il suo trasferimento in un altro sistema, l'IDoc è in realtà ricostruito da copia, segmento per segmento. I segmenti di stato non sono trasferiti, e sono specifici a ciascuno dei sistemi. Questi segmenti sono organizzati in modo sequenziale, in modo che solo l'ultimo segmento ha una reale importanza. Di conseguenza, ciò che è riferito come stato del IDoc è in realtà copiato dallo stato di cui l'ultimo segmento della sezione dello stato del IDoc.

L’IDoc viene memorizzato in tre differenti tabelle di database in relazione al tipo di record:

Record di controllo (tabella EDIDC)

Il record di controllo viene memorizzato in tabella EDIDC (un solo inserimento)
Record di dati (tabella EDID4)

I record di dati vengono memorizzati in tabella EDID4 (N inserimenti)
Record di stato (tabella EDIDS)

I record di stato vengono memorizzati in tabella EDIDS (N inserimenti)

Prerequisito

Per poter lavorare con gli IDoc, è necessario personalizzare tutte le impostazioni di configurazione del sistema. Per fare ciò richiamare la transazione SPRO è scegliere il seguente percorso:

AP Reference IMG→ SAP NetWeaver → SAP Web Application Server → IDoc Interface/ Application Link Enabling (ALE)

Strutture dei Segmenti

A) Segmento di controllo

I campi più importanti del segmento di controllo sono le seguenti:

IDoc number: numero del IDoc nel sistema locale

Direction: direzione di IDoc, dal punto di vista del sistema locale; 1 sta per uscita, 2 per ingresso

Status: stato corrente della IDoc nel sistema locale

Basic type: tipo IDoc di base

Extension: tipo di estensione, se applicabile.

Message type: tipo di messaggio

Sender or Recipient information: dettagli riguardanti il mittente o il destinatario.

Port: porta

Partner number: numero di sistema logico

Partn.Type: tipo di partner; la maggior parte delle volte è settato a LS che sta per Logical System

SAP Release: il numero di versione del IDoc

Output Mode: modalità di uscita; 2 sta per immediato invio, 4 per l'invio di raccolta

B) Segmento di dati

La struttura di un segmento di dati dipende dal tipo di segmento. Ogni tipo di segmento ha un diverso numero di campi, ogni campo di lunghezza diversa.

C) Segmento di stato

La struttura di un segmento di stato è il seguente:

Stato: lo stato riportato dal segmento

Messaggio: il testo che descrive lo stato

Gli altri campi del segmento di stato sono usate per generare un messaggio che segue una struttura standard SAP.

Struttura di un'Interfaccia

L'interfaccia è composta dai seguenti elementi:

Una View del modello di distribuzione (opzionale)
Nessuno, oppure uno o più filtri
Un sistema mittente
Un sistema destinatario
Un tipo messaggio
Interfaccia di Outbound:

o Una porta da cui inviare il messaggio

o Una modalità di uscita

o Una dimensione del pacchetto

o Un tipo di IDoc di base

Interfaccia di Inbound:

o Un codice di processo

A) View del modello di distribuzione

La creazione di una vista del modello distributivo è opzionale. Infatti, è strettamente obbligatorio solo nel caso in cui sia necessaria l'applicazione di un filtro.

Dopo la creazione di una vista nel modello di distribuzione, è possibile distribuire questa vista per il sistema partner, come è anche possibile generare i profili dei partner per questa vista.

B) Tipo messaggio e tipo di IDoc di base

Un tipo messaggio rappresenta il gruppo in cui ogni tipo IDoc base devono appartenere. Un tipo di messaggio è concettualmente la natura dei dati trasmessi in un IDoc.

Ad esempio, il tipo di messaggio MATMAS è legata alla dati anagrafici del materiale. Per questo tipo di messaggio MATMAS sono associati diversi tipi IDoc di base: MATMAS01, MATMAS02, MATMAS03, MATMAS04 et MATMAS05. Ogni tipo di IDoc di base è in grado di contenere i dati essenziali sui dati anagrafici del materiale. MATMAS01 è la prima versione, ogni versione successiva incrementa il numero di sequenza (MATMAS02, etc.) e aggiunge campi confronto con la versione precedente.

Per visualizzare la struttura di un IDOC utilizzare la transazione: WE61

Creazione di un IDoc custom e di un'interfaccia outbound

STEP NR. 1: Creazione e configurazione dell'IDOC

La prima cosa da fare, è costruire i segmenti che il nostro IDOC conterrà. Per costruire un segmento, occorre specificarne un nome e definire i campi che lo costituiscono, con i relativi data element.

Per fare ciò utilizziamo la transazione WE31 (sviluppo segmenti).

Nella schermata iniziale inseriamo il nome del tipo segmento che vogliamo creare ad esempio: ZSEGM99 e premiamo il pulsante NEW.

Inseriamo una descrizione del segmento e creiamo 3 campi e poi salviamo e ritorniamo nella schermata iniziale.

Dopo il salvataggio è necessario il “rilascio” del segmento, per fare ciò andiamo su EDIT->Set Release

A questo punto il segmento creato diviene utilizzabile. Alla destra della segment definition si vedrà che il checkbox "Release" è ora spuntato, come nella prossima figura:

A questo punto creiamo l'IDOC vero e proprio, ovvero definiamo il suo "Basic Type". Per fare ciò andiamo nella transazione WE30(sviluppo tipi IDoc).

Scegliamo il nome per il Basic Type: in questo esempio ho creato l'oggetto Y_BASICTYPE. Automaticamente la mia utenza viene utilizzata per definirne l'amministratore. Inoltre occorre inserire la descrizione.

Associare all’IDoc creato Y_BASICTYPE, il segmento creato in precedenza ZSEGM99, quindi selezioniamo EDIT->Create Segment

Ora, supponiamo di voler trasmettere un singolo IDOC contenente i dati relativi a tutti i nostri clienti, in questo caso dovremmo specificare che il numero di segmenti ZSEGM99 consentiti nel presente IDOC è infinito. Oppure potremmo trovarci nel caso in cui vogliamo spedire tanti singoli IDOCs, uno per ciascun cliente. In questo caso definiremo la numerosità uguale a 1. Ecco come vengono specificate queste informazioni.

In pratica specifichiamo se il segmento deve essere obbligatorio o facoltativo, ed il range numerico di segmenti che possono essere ripetuti. Salviamo e come nella transazione precedente, anche qui è necessario attivare il basic type, settando la release dal menù EDIT.

A questo punto, bisogna creare il Message Type usando la transazione WE81.

Qual è lo scopo del nostro IDOC? Con lo stesso basic type, potrei voler trasmettere dati con scopi differenti. Per esempio, il basic type che abbiamo costruito, potrebbe servire per aggiornare le anagrafiche di due sistemi differenti. Per questo motivo è necessario definire uno o più message types ed in seguito associarli al basic type costruito. Andiamo in WE81.

Qui troviamo semplicemente una tabella, dove possiamo stabilire un nome per il nostro message type e fornire la descrizione. Aggiungiamo quindi una nuova entry a questa tabella, poi salviamo.

L'associazione tra message type e basic type la faremo usando la transazione WE82 (vedi table EDIMSG).

Occorre anche indicare la release, che corrisponde a quella relativa al segmento usato. L'IDOC è pronto per l'utilizzo, e lo step 1 è concluso.

STEP NR. 2: Programma che carica e spedisce l’IDoc

Scrivere il programma che caricherà e spedirà l'IDOC al sistema receiver.

Dalla SE38 creiamo un programma che faccia le opportune estrazioni di dati con cui caricare l'IDOC. Questo programma verrà poi probabilmente usato come Job, e quindi schedulato per girare periodicamente, oppure lanciato a seconda delle esigenze. Ecco la struttura base del programma:

DATA: gw_edidcp TYPE edidc,

gw_ediddp TYPE edidd,

gt_ediddp TYPE TABLE OF edidd.

CONSTANTS: c_mestypp LIKE edidc-mestyp VALUE 'ZMESSAGETYPE',

c_idoctpp LIKE edidc-idoctp VALUE 'Y_BASICTYPE',

c_rcvprt VALUE '', "Partner Type of Receiver: da configurare in WE20

c_rcvprn VALUE '', "Partner Number of Receiver:da configurare in WE20

c_segmname TYPE edidd-segnam VALUE 'ZSEGM99',

c_hlevel TYPE edi_hlevel VALUE '02'.

START-OF-SELECTION.

PERFORM extract_data TABLES gt_data.

IF gt_data[] IS NOT INITIAL.

PERFORM set_idoc TABLES gt_data gt_ediddp CHANGING gw_edidcp.

PERFORM create_idoc TABLES gt_log.

ENDIF.

In questo esempio, la routine extract_data prepara i dati nella

tabella gt_data. Questa verrà usata per alimentare l'idoc nella routine set_idoc.

Vediamola:

*&------------------------------------------------------------*

*& Form SET_IDOC

*&------------------------------------------------------------*

FORM set_idoc TABLES lt_idoc_data STRUCTURE gt_data

lt_ediddp STRUCTURE edidd

CHANGING lw_edidcp STRUCTURE gw_edidcp.

DATA: lw_main_segm LIKE ZSEGM99,

lw_ediddp TYPE edidd.

*Fill_edidc

CLEAR lw_edidcp.

lw_edidcp-mestyp = c_mestypp.

lw_edidcp-idoctp = c_idoctpp.

lw_edidcp-rcvprt = c_rcvprt.

lw_edidcp-rcvprn = c_rcvprn.

*Fill_edidd

LOOP AT lt_idoc_data.

CLEAR: lw_main_segm.

MOVE-CORRESPONDING lt_idoc_data TO lw_main_segm.

CLEAR: lw_ediddp.

MOVE lw_main_segm TO lw_ediddp-sdata.

MOVE c_segmname TO lw_ediddp-segnam.

MOVE c_hlevel TO lw_ediddp-hlevel.

APPEND lw_ediddp TO lt_ediddp.

ENDLOOP.

ENDFORM. " SET_IDOC

Infine, la routine create_idoc inoltrerà l'idoc. Eccola:

*&------------------------------------------------------------*

*& Form CREATE_IDOC

*&------------------------------------------------------------*

FORM create_idoc TABLES lt_log STRUCTURE gt_log.

DATA: lt_control LIKE edidc OCCURS 0 WITH HEADER LINE,

lf_idoc LIKE edidc-docnum.

*Send a single IDOC

CALL FUNCTION 'MASTER_IDOC_DISTRIBUTE'

EXPORTING

master_idoc_control = gw_edidcp

TABLES

communication_idoc_control = lt_control

master_idoc_data = gt_ediddp

EXCEPTIONS

error_in_idoc_control = 1

error_writing_idoc_status = 2

error_in_idoc_data = 3

sending_logical_system_unknown = 4

OTHERS = 5.

CASE sy-subrc.

WHEN 0.

COMMIT WORK.

CALL FUNCTION 'DEQUEUE_ALL'.

LOOP AT lt_control.

lf_idoc = lt_control-docnum.

EXIT.

ENDLOOP.

CLEAR lt_log.

WRITE icon_green_light AS ICON TO lt_log-type.

CONCATENATE text-006 lf_idoc INTO lt_log-message SEPARATED BY space.

WHEN OTHERS.

CLEAR lt_log.

WRITE icon_red_light AS ICON TO lt_log-type.

CASE sy-subrc.

WHEN 1.

MOVE text-001 TO lt_log-message.

WHEN 2.

MOVE text-002 TO lt_log-message.

WHEN 3.

MOVE text-003 TO lt_log-message.

WHEN 4.

MOVE text-004 TO lt_log-message.

WHEN 5.

MOVE text-005 TO lt_log-message.

ENDCASE.

CONDENSE lt_log-message.

APPEND lt_log.

ENDFORM. " CREATE_IDOC

STEP NR. 3: Configurazione del partner profile e distribution model

A questo punto bisogna inviare l’IDoc al sistema partner. Il partner viene definito nella transazione WE20 (vedi tabella EDP21 per inbound parameters e tabella EDP13 per outbound parameters).

Questa transazione (Accordi partner) consente di parametrizzare il canale di comunicazione tra 2 sistemi, specificando le porte di comunicazione, e le CALL REMOTE FUNCTION.

NOTA: Per vedere quale FM elabora l’IDoc, nell’ambiente in cui viene creato l’idoc, leggere il campo FNAME_INB dalla tabella TBDBE inserendo nel campo IDOCTYPE = il basic .

Nella WE20, specifico il partner profile di outbound (solitamente in questa fase occorre l'aiuto dei sistemisti). Ovvero specifico che un certo message type, deve essere recapitato ad un certo sistema receiver. Quindi l'IDOC ZMESSAGETYPE potrebbe per esempio essere mandato al Logical System PI di sviluppo (che in questo caso si chiama DPI001) e avremo:

Inoltre andrà indicato il numero di porta del sistema receiver ed il basic type dell'IDOC.
Per finire, configuriamo il Distribution Model, dalla transazione BD64.
Qui definiamo un nome di modello, e gli associamo il nome del sistema sender, del receiver ed il message type dell'IDOC.

Clicchiamo su Add Message Type (stando in modalità modifica) ed inseriamo queste informazioni.

Abbiamo finito. Non ci rimane che lanciare il programma. Questo estrarrà i dati dal DB di R/3, caricherà l'IDOC e lo inoltrerà al sistema receiver. Il risultato di ciò sarà visualizzabile sulla transazione WE05 oppure con la transazione WE02.

Creazione di un IDoc custom e di un'interfaccia inbound

STEP NR. 1: Creazione e configurazione dell'IDOC

Il primo passo è uguale al primo passo che abbiamo visto in precedenza per la creazione di un IDoc Custom e di un’interfaccia OUTBOUND

STEP NR. 2: Function Module per leggere l’IDoc

Scrivere un FM custom, per leggere l’IDoc partendo ad esempio dal FM standard IDOC_INBOUND_WRITE_TO_DB.

STEP NR. 3: Specificare la tipologia del Function module

Nella transazione BD51 viene specificato la tipologia del Function module definito in precedenza.

Inserire il nome del FM creato in precedenza ed associare nel campo Input type uno dei seguenti valori:

· 0 = Mass processing

· 1 = Individual input

· 2 = Individual input with IDoc lock in CALL TRANSACTION

STEP NR. 4: Legame tipo messaggio con il modulo di elaborazione di ingresso

Per associare il tipo messaggio al modulo di elaborazione di ingresso (FM creato in precedenza) usare la transazione WE57.

STEP NR. 5: Creare un codice di processo personalizzato

Il legame tra il tipo messaggio e il modulo di elaborazione di ingresso viene ulteriormente specificato attraverso il codice processo visibile dalla transazione WE42

STEP NR. 6: Associare il FM al codice di processo

Il legame tra il FM creato in precedenza con lii codice di processo personalizzato creato in precedenza avviene mediante la transazione BD67.

STEP NR. 7: Eseguire l’entrata IDoc

Per eseguire l’entrata IDoc usare la transazione WE19, inserire il numero di IDoc e premere il pulsante ad esempio Standard Inbound

Struttura XSD dell'Idoc

Per generare il file xml della struttura dell’Idoc richiamare la transazione WE60

Inserire il nome del tipo base dell’idoc MAT05 e dal menu documentazione selezionare Schema XML

Idoc in entrata stato 64

Transazione Tcode: SWE2

Inserire la riga relativa al tipo oggetto: IDOC

Elenco programmi utili per gestire Idoc

TRANSAZINI ALE / EDI/ IDOCS
Programma	Descrizione
RSEINB00	Elaborazione Ingresso da file
RSEOUT00	Elaborazione Uscita da file
RBDAPP01	Elaborazione Ingresso idoc stato 64 e 66
RBDMANI2	Elaborazione Ingresso idoc stato 51 (err. Applicazione)
RBDAGAI2	Elaborazione Ingresso idoc stato 56, 61, 63, 65 (err. ALE)
RBDAGAIE	Elaborazione Idoc editati stato 32 (uscita) e 69 (ingresso)
RBDINPUT	Elaborazione Idoc ingresso
RBDSYNEI	Elaborazione Idoc ingresso stato 60 (con errore di sintassi)
RBDSYNEO	Elaborazione Idoc uscita stato 26 (con errore di sintassi)

Elenco transazioni Ale / Edi / IDocs

TRANSAZINI ALE / EDI/ IDOCS
Transazioni	Descrizione
WE02	List Of All Idocs Created. (Default, Additional, EDI)
WE05	List Of Idocs Created. (Standard, Additional)
WE06	Active Monitoring For Idoc Processing.
WE07	Idoc Statistics.
WE08	Display View u201CFile Statusu201D:Overview-Path Name.
WE09	Idoc Search For Business Contents (Database).
WE10	Idoc Search For Business Contents (Archive).
WE12	Modification Of Outbound File, Triggering Inbound Processing.
WE14	Process All Selected Idocs.
WE15	Selection Program For Issuing Output.
WE16	Trigger Inbound Processing.
WE17	Trigger Status Processing.
WE18	Generate Test Status File For Outbound Idocs.
WE19	Test Tool For Idoc Processing
WE20	Partner Profile.
WE21	Ports In Idoc Processing.
WE23	Display Test Catalog Test Idoc Interface.
WE24	Maintain Table View. Direction-1.(Outbound)
WE27	Maintain Table View. Direction-2.(Inbound)
WE30	Develop Idoc Type.
WE31	Develop Idoc Segments.
WE32	View Development.
WE33	Maintain Table Views.
WE34	Change View u201CTable Of Style Ids With The Objects To Be Loadedu201D
WE40	Display System Process Code.
WE41	Display View: Logical Msg Overview. For Outbund.
WE42	Display View: Logical Msg Overview. For Inbound.
WE43	Display Status Records.
WE44	Display Partner Types
WE45	Maintenance Interface: Forwarding Inbound/EDILOGADR For Application
WE46	Global Parameter For Idoc Interface.
WE47	VISUALIZZA TUTTI GLI STATI DI UN IDOC
WE50	Display Text For Process Code System.
WE54	Idoc Function Module For File Name
WE56	Display Status Process Code
WE57	Idoc Assignment Of FM To Log. Message And Idoc Type.
WE58	Text For Process Code Status.
WE60	Documentation For Idoc Type.
WE61	Documentation For Idoc Record Type.
WE62	Documentation For Idoc Segment Type.
WE63	Documentation For Idoc Record Types And Idoc Types (Parser).
WE64	Process Code In Idoc Inbound And Outbound.
WE70	Conversion Table For Basic Types.
WE71	Conversion Table For Extensions.
WE72	Conversion Table For Field DOCTYP.
WE73	Conversion Table For Logical Message Type.
WE81	EDI:Logical Message Type.
WE82	Message Types And Assignment To Idoc Types.
WE84	Assignment Table Between Idoc And Application Field.
BD10	Send Material (Matmas)
BD11	Get Material.
BD12	Send Customer.
BD13	Get Customers
BD14	Send Vendor.
BD15	Get Vendor.
BD16	Send Cost Center. (Cosmas)
BD17	Request Cost Center.
BD18	Send G/L Accounts.
BD19	Get Master Data G/L Accounts.
BD20	Inbound Processing Of Idocs Ready For Transfer.
BD21	Creating Idoc Types For Change Pointers.
BD22	Delete Change Pointers.
BD23	Serialization Using Time Stamp: Deletion Of Old Time Stamp.
BD24	Send Cost Elements.
BD25	Send Activity Type (COAMAS)
BD26	Request Activity Type
BD27	Cost Center/Activity Types: Transmit Plan Quantities And Acty Prices.
BD28	Cost Center/ Cost Elements: Send Control Records.
BD30	Material Bom Distribution. (Bommat).
BD31	Document Structure Distribution. (Bomdoc)
BD32	Plant Allocation To Material Boms Distribution.
BD33	Distribution Of Material Variants. (STTMAT)
BD34	Distribution Of Boms (BOMORD)
BD35	ALE: Send Business Process Group.
BD36	ALE: Send Business Process.
BD37	ALE: Send Business Process Price.
BD40	Generate Idocs For Serialization Group From Change Pointers.
BD41	Dispatch Of Idocs Of Serialization Group.
BD42	Check Dispatch Status Of Idocs Of Serialization Group.
BD43	Processing Inbound Idocs Of Serialization Group.
BD44	Change View u201CSerialization Groupu201D.
BD47	Dependence Between Methods.
BD48	Dependence Between Methods And Message Type.
BD50	Activate Change Pointers For Message Type.
BD51	Characteristics Of Inbound Function Module.
BD52	Determine Work Area.
BD53	Reduce Message Type.
BD54	Change View: Logical Systems
BD55	Idoc Conversion.
BD56	Maintain Idoc Segment Filters.
BD57	Link Type And Serialization Type Of Message Type.
BD58	Convert Organizational Unit.
BD59	Allocation Of Object Type.
BD60	Additional Data For Message Type.
BD61	Activate Change Pointers Generally.
BD62	Display Conversion Rule.
BD63	Transport Of Ale Tables For A Message Type.
BD64	Display Distribution Model.
BD65	Maintain Idoc Type Required Fields.
BD66	Change Idoc Fields.
BD67	Function Module For ALE/EDI Overview.
BD68	Maintain List.
BD69	Assignment Of Idoc Type To Message Type.
BD70	Cross-System Comparison Of Number Range Objects.
BD71	Attributes For Receiver Determination.
BD72	Active Events For ALE/EDI
BD73	Start Error Handling For Non-Posted Idocs.
BD75	Status Conversion With Trfc Execution.
BD77	Generate Transport Requests For Distributing ALE Customizing Data.
BD78	Monitoring Ale Customizing Data Transport
BD79	ALE IDOC Segments - Conversion Rule
BD81	Filter Objects For BAPI Parameter Filtering
BD82	Generating Partner Profile
BD83	Re-Processing Incorrect Outbound Odocs.
BD84	Re-Processing Of Idocs After ALE Input Error.
BD85	Consistency Check: Reassignment Between Two System.
BD86	ALE Consistency Check: Create Purchase Order From Sales Order.
BD87	Select Idocs
BD89	Customizing Data Modeling For Distribution Model.
BD91	Distribute All Characteristics Via ALE.
BD92	Distribute Class Via ALE: Send Direct.
BD93	Distribution Of Classification Data Via ALE.
BD95	Ale Object View
BD96	Filter Object For Receiver Determination Of Methods.
BD97	Assign RFC Destination For Synchronous Method Calls.
BD98	Consistency Check With Workflow Link
BD99	Dependencies Between Message Types.
BD100	Display Serialized Idocs. (Serialization Using Object Types)
BD101	Serialization Using Object Types: Consistency Check.
BD102	Ale: Outbound Channel Registry.