Escolar Documentos
Profissional Documentos
Cultura Documentos
Manual Prático de IDOC, ALE e EDI
Manual Prático de IDOC, ALE e EDI
IDoc
Manual Prtico de ALE/EDI e IDoc
O que ALE?
SAP ALE (Application Link Enabling) a tecnologia proprietria que permite a comunicao de dados
entre dois ou mais ambientes SAP R/3 ou R/3 e sistemas de terceiros. A tecnologia ALE facilita rpida
prototipao de aplicao e desenvolvimento de interface de aplicao, e ainda reduz o tempo de
implementao.
Application layer. Esta camada fornece a ALE uma interface para criar ou receber mensagens contendo
dados para/de sistemas externos (ou outra SAP R/3).
Distribution layer (ALE layer). A camada de distribuio filtra e converte mensagens contendo dados
baseados de regras predefinidas ou customizadas. Estas converses podem ocorrer para assegurar a
compatibilidade entre diferentes releases de R/3 e R/2.
IDoc(Intermediate Document) documento de texto codificado com uma estrutura rgida que
usado para troca de dados entre R/3 e sistemas externos. Ao invs de chamar o programa
diretamente no sistema destino, os dados so primeiramente empacotados para um IDoc e
depois o IDoc enviado para sistema receptor, onde ele analisado e adequadamente
processado. Por isso a troca de dados via IDoc sempre um processo assncrono. A principal
diferena entre uma chamada simples de RFC e a troca de dados via IDoc , de fato, que cada
ao executada em IDoc protocolada pelo R/3 e IDocs podem ser reprocessados se algum
erro ocorrer durante um dos passos de mensagem.
Enquanto IDocs so entendidos como protocolo de troca de dados, EDI e ALE so casos
tpicos de uso para IDocs. R/3 utiliza IDocs atravs tanto EDI quanto ALE para distribuir dados
ao sistema receptor. A grande diferena entre EDI e ALE o seguinte: se eu enviar dados para
um parceiro externo, de forma geral eu estou falando de EDI, enquanto ALE o mecanismo
para replicar dados de forma confivel entre sistemas de confiana para armazenar cpia
redundante de dados de IDoc. Para esclarecer a diferena ainda mais, podemos pensar um
pedido de compra que enviado atravs de um IDoc. Se ns enviarmos um pedido de compra
para o fornecedor ento o fornecedor vai armazenar este pedido de compra como uma ordem
de venda. (Isto o conceito de EDI.) No entanto, se ns enviarmos o pedido de compra via
ALE para outro ambiente R/3, ento o sistema receptor vai armazenar o pedido de compra
tambm como pedido de compra.
Tipo de IDoc e IDoc. Um tipo de IDoc representa a estrutura de dados associada a um tipo de
mensagem, enquanto um IDoc um objeto contendo os dados de um tipo de mensagem particular. IDoc
um recipiente de dados com inteligncia embutida. Cada IDoc contm um e somente um objeto de
negcio.
Um IDoc consiste trs tipos de registro: o registro de controle, registro de dado e registro de status.
Registro de controle, ou EDI_DC, uma estrutura de controle que contm vrios campos com
as informaes sobre o IDoc, tais como o tipo de IDoc, o tipo de mensagem, informao de
sender e de receiver, e a direo (1 para outbound e 2 para inbound). Estas informaes
Registro de dado, ou EDI_DD, ele contm os dados da applicao. Cada registro EDI_DD tem
uma poro de chaves que contm uma srie de campos descrevendo o contedo do registro.
Depois das chaves vem o campo SDATA com tamanho de 1000 bytes do tipo Long Char. O
campo SDATAguarda os dados da aplicao, e sua estrutura determinada pelo campo chave
SEGNAM (nome do segmento). Um IDoc consiste um ou mais registros de dado. Registros de
dado so armazenados na tabela EDID4.
No SAP segmentos de IDoc aderem-se conveno de nomenclatura. Cada segmento possui trs
componentes, e cada componente com prefixo diferente - E1 para tipo de segmento, E2 para
definio de segmento e E3 para documentao de segmento. Por exemplo, o primeiro segmento
do tipo de IDoc DEBMAS02 E1KNA1M. Sua definio contida na estrutura E2KNA1M, e a
documentao est na E3KNA1M. Quando o IDoc externalizado, vemos o nome do segmento
iniciado com prefixo E2. Na prtica, em todos os casos, usamos somente prefixo E2 para se referir
segmentos de IDoc.
Registro de status, ou EDI_DS. Ele contm informaes de estado de IDoc quando IDoc passa
pelo vrios estgios de processamento. O registro de status mantm o histrico de um IDoc. Um
IDoc pode ter um ou mais registros de status, onde so armazenados na tabela EDIDS.
Porta. Porta a representao lgica de canal de comunicao em SAP, com os IDocs sendo os dados
comunicados. So quatro tipos de portas que podem ser definidos em R/3: tRFC, File, R/2, e Internet.
ALE pode utilizar todas os tipos de porta para distribuir IDocs, enquanto EDI tipicamente utiliza a porta
baseada em file. As portas tipo tRFC e file podem ser ligadas aos destinos RFC conectados em R/3-
para-R/3 ou TCP/IP.
Destino RFC. O destino RFC o termo que define as caractersticas de comunicao ligado a um
sistema remoto onde uma funo precisa ser executada. A comunicao R/3-para-R/3 utiliza
tRFC(transactional RFC). O prefixo transactional indica meramente que uma funo especfica
executada por unidade lgica de trabalho, que pode ser Mestre de Material, ou a entrega, ou o
faturamento.
Cdigos de Processo. Cdigos de processo so usados em ALE e EDI para identificar o mdulo de
funo ou API para ser chamado e conseqentemente processado. Cada cdigo de processo
associado a um tipo de mensagem. Cdigos de processo tipo outbound so armazenados na tabela
TEDE1 e cdigos de processo tipo inbound so armazenados na tabela TEDE2.
Tipo de parceiro. Tipo de parceiro um identificador do sistema para comunicar mensagens. Existem
quatro tipos de parceiro: KU (Cliente), LI (Fornecedor), B (Banco) e LS (Sistema Lgico). Tipo de parceiro
define vrios elementos de ALE e EDI com os parmetros de comunicao entre dois ou mais sistemas.
Os principais parmetros so: tipos de mensagem, tipos de IDoc, cdigos de processo, funes parceiro,
identificadores da aplicao, funes de mensagem, tipos de sada e portas.
Tipo de parceiro exerce um papel muito importante pois ele age como um gateway para comunicao
ALE e EDI. Ele transfere mensagens especficas atravs de tipos de IDoc definidos para a porta depois
da execuo de certos mdulos de funo para processamento outbound. Ele tambm pode receber tipo
especfico de IDoc, e identifica mdulos de funo apropriados para que insira dados no banco no caso
de interface inbound.
Modelo de distribuio. No sistema R/3, o Modelo de Distribuio uma ferramenta que armazena
informaes sobre o fluxo de dados entre vrios sistemas. O modelo de distribuio armazena dados que
informam quais as mensagens (tipos de mensagem) sejam transmitidas para quais Sistemas Lgicos.
Vrias mensagens podem ser transmitidas para um Sistema Lgico, e uma nica mensagem pode ser
transmitida para vrios Sistemas Lgicos.
Texto fonte:
*-------------------*
* Tabelas internas
*-------------------*
DATA: BEGIN OF ti_bank_list OCCURS 0.
INCLUDE STRUCTURE bapi1011_list.
DATA: END OF ti_bank_list.
*-------------------*
* Variveis globais
*-------------------*
DATA: idoc_control LIKE bdicontrol,
idoc_data LIKE edidd OCCURS 0 WITH HEADER LINE,
idoc_receiver LIKE bdi_logsys OCCURS 0 WITH HEADER LINE,
idoc_comm LIKE edidc OCCURS 0 WITH HEADER LINE,
syst_info LIKE syst.
*----------------*
* Processamento
*----------------*
*-------------------*
* Seleo de dados
*-------------------*
LOOP AT receivers.
CLEAR: syst_info.
* distribute idocs *
REFRESH: idoc_receiver, idoc_comm.
APPEND receivers TO idoc_receiver.
IF sy-subrc <> 0.
MESSAGE ID sy-msgid TYPE sy-msgty NUMBER sy-msgno
WITH sy-msgv1 sy-msgv2 sy-msgv3 sy-msgv4
RAISING error_creating_idocs.
ENDIF.
IF communication_documents IS REQUESTED.
LOOP AT idoc_comm.
CLEAR communication_documents.
communication_documents-objtype = 'IDOC'.
communication_documents-objkey = idoc_comm-docnum.
communication_documents-logsys = idoc_comm-rcvprn.
communication_documents-describe = space.
APPEND communication_documents.
ENDLOOP.
ENDIF.
ENDLOOP.
ENDFUNCTION.
*---------------------------------------------------------------------*
* FORM inserir_segmento_banklist *
*---------------------------------------------------------------------*
* Criar IDoc data-record *
*---------------------------------------------------------------------*
FORM inserir_segmento_banklist
TABLES
ti_bank_list STRUCTURE bapi1011_list
idoc_data STRUCTURE edidd.
LOOP AT ti_bank_list.
CLEAR ze1banklist.
MOVE-CORRESPONDING ti_bank_list TO ze1banklist.
ENDFORM.
9 passo: Atribuir mdulo de funo a tipo de mensagem e de IDoc atravs da transao WE57:
Mdulo: ZALE_GET_BANKLIST
Categoria: F
Tp.bsico: ZID_BANKLIST
Tipo mensagem: ZMG_BANKLIST
Direo: 1
Salvar.
10 passo: Identificar o sistema lgico do prprio mandante atravs dos seguintes passos:
Transao: SALE
Abrir a opo:
Preparar sistema receptor e de envio
Instalar sistemas lgicos
Atribuir sistema lgico a mandante
Double-click na linha onde est o mandante do sistema
E descobrir qual o sistema lgico do mandante, no nosso caso DEV46
Executar a funo.
Verificar o IDoc criado com o status 03 Transferncia de dados para a porta OK. - O IDoc foi
enviado para um sistema R/3 ou para um programa externo, atravs de um RFC transacional.
Vamos comear o exemplo pela forma mais fcil, a de aproveitar a estrutura existente de BAPI.
4 passo: Atribuir mdulo de funo a tipo de mensagem e de IDoc atravs da transao WE57:
Verificar se o tipo bsico BANK_CREATE01 est cadastrado na transao WE57. Caso
contrrio, clicar no cone <Entradas novas>.
Mdulo: BAPI_IDOC_INPUT1
Categoria: F
Tp.bsico: BANK_CREATE01
Salvar.
5 passo: Identificar o sistema lgico do prprio mandante atravs dos seguintes passos:
Transao: SALE
Abrir a opo:
Preparar sistema receptor e de envio
Instalar sistemas lgicos
Atribuir sistema lgico a mandante
Double-click na linha onde est o mandante do sistema
E descobrir qual o sistema lgico do mandante, no nosso caso DEV46
2) Suponha que no SAP no existe uma BAPI que satisfaz a necessidade do usurio. Por exemplo, o
SAP precisa receber IDocs para alimentar uma tabela Z.