Guia prático sobre

ALE – Application Link Enabling

IDoc – Intermediate Document

 Sumário

1. Conceituação 3
1.1. O que é ALE 3
1.2. Qual é a diferença entre ALE, EDI, IDoc e BAPI ? 4
1.3. Blocos de Construção de ALE e Seus Conceitos 5
2. Guia rápido para criar IDoc de saída – outbound 9
3. Guia rápido para criar IDoc de entrada – inbound 15
3.1. Criando um IDoc de entrada (inbound) usando BAPI 15
1. Conceituação

1.1. O que é ALE

SAP ALE (Application Link Enabling) é a tecnologia proprietária que permite a comunicação de
dados entre dois ou mais ambientes SAP R/3 ou R/3 e sistemas de terceiros. A tecnologia ALE
facilita rápida prototipação da aplicação e desenvolvimento do interface de aplicação, e ainda reduz
o tempo de implementação.
ALE vem com cenários de integração/distribuição de aplicação e um conjunto de ferramentas,
programas, definição de dados e metodologias que você pode facilmente configurar para construir
e rodar uma interface.
A arquitetura de ALE é composta de três camadas:
ƒ 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): Esta camada de distribuição filtra e converte mensagens
contendo dados baseados em regras pré-definidas ou customizadas. Estas conversões podem
ocorrer para assegurar a compatibilidade entre diferentes releases de R/3 e R/2.
ƒ Communications layer: As comunicações ALE são realizadas tanto sincronamente quanto
assincronamente. Transmissões de mensagens sincronamente são tipicamente usadas para
leitura direta de dados, enquanto transmissões de mensagens assincronamente são usadas
para transmitir e receber dados da aplicação.
Existem várias vantagens na utilização da tecnologia ALE:
9 A SAP garante a independência de release;
9 ALE oferece melhor performance de interface de entrada do que as técnicas tradicionais
tais como Batch Data Communications (BDC) ou Call Transactions. ALE não utiliza batch-
input baseada em telas.
9 ALE fornece tecnologia tipo “caixa-preta”, com isso, o usuário fica no nível mais alto de
desenvolvimento.
9 A maioria de interfaces ALE pode ser prototipada em alguns dias, resultando num prazo
menor de implementação.
9 Existe pequeno ou nenhum desenvolvimento em ABAP. Na maioria dos casos, as
funcionalidades ALE desenvolvidas pela SAP já preenchem os requisitos.
9 ALE oferece recursos sistemáticos e organizados para manutenção de melhorias e
extensões.
9 Uma interface ALE é de fácil manutenção devido ao acesso estruturado e ao número
mínimo de objetos de desenvolvimento.
9 ALE é a arquitetura estratégica do R/3 para efetuar conexão com sistemas legados e de
terceiros e é o elemento chave do Business Framework. Ele determina a arquitetura
baseada em mensagens para integração assíncrona de componentes de Business
Framework, incluindo Business Components, Business Objects, e BAPIs.
1.2. Qual é a diferença entre ALE, EDI, IDoc e BAPI ?
O conceito de interface do R/3 é baseado em duas estratégias diferentes: Remote Function Calls
(RFC) e a troca de dados através de documentos de mensagem IDoc. RFC faz a chamada direta e
sincronizada de programa no sistema remoto. BAPIs são subconjunto de módulos de função RFC,
especialmente desenhadas como Application Programming Interface (API) para objeto de negócio
SAP, ou seja, BAPIs são módulos de função liberados oficialmente pela SAP para serem
chamados por programas externos.
Idoc (Intermediate Document) é um documento de texto codificado com uma estrutura rígida e que
é utilizado para a troca de dados entre o R/3 e os sistemas externos. Ao invés de chamar o
programa diretamente pelo sistema destino, os dados são 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 assíncrono. A principal
diferença entre uma chamada simples de RFC e a troca de dados via IDoc é, de fato, que cada
ação executada em IDoc é protocolada pelo R/3 e IDocs podem ser reprocessados se algum erro
ocorrer durante um dos passos de mensagem.
Enquanto IDocs são entendidos como protocolo de troca de dados, EDI e ALE são casos típicos de
uso para IDocs. O R/3 utiliza IDocs tanto através de EDI quanto de ALE para distribuir dados ao
sistema receptor.
A grande diferença 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
confiável entre sistemas de confiança para armazenar cópia redundante de dados de IDoc. Para
esclarecer a diferença ainda mais, podemos pensar um pedido de compra que é enviado através
de um IDoc. Se nós enviarmos um pedido de compra para o fornecedor então o fornecedor vai
armazenar este pedido de compra como uma ordem de venda. (Isto é o conceito de EDI.) No
entanto, se nós enviarmos o pedido de compra via ALE para outro ambiente R/3, então o sistema
receptor vai armazenar o pedido de compra também como pedido de compra.

1.3. Blocos de Construção de ALE e Seus Conceitos

Os seguintes blocos de construção são fundamentais para funcionalidade ALE:

a) Sistema Lógico
O Sistema Lógico (LS) é a representação de R/3 ou de um sistema externo para distribuição
de dados para/de sistema R/3. Cada cliente R/3 usado para ALE ou EDI precisa ter uma base
LS associada com o cliente. Este LS se torna o “sender” para mensagem de outbound e o
“receiver” para mensagem de inbound. Além disso, um segundo LS deveria ser criado para
representar o sistema externo usado na interface ALE. Neste caso, este segundo LS seria
“sender” quando for a mensagem de inbound e seria “receiver” quando for a mensagem de
outbound.
b) Tipo de Mensagem
Um tipo de mensagem representa a troca de mensagem de aplicação entre sistemas R/3 ou
um R/3 e um sistema externo. Um tipo de mensagem caracteriza os dados enviados entre
sistemas e se relaciona com uma estrutura de dado que se chama Tipo de IDoc.
c) Tipo de 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 inteligência embutida. Cada IDoc contém um e somente um
objeto de negócio.
Um IDoc consiste três 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 contém vários

campos com as informações sobre o IDoc, tais como o tipo de IDoc, o tipo de
mensagem, informação de sender e de receiver, e a direção (1 para outbound e 2 para
inbound). Estas informações determinam dados de controle em IDoc de outbound, e
opções de processamento em IDoc de inbound. Ele também possui a sua chave de
mandante (MANDT) e o número de IDoc (DOCNUM). O registro EDI_DC de um IDoc é
armazenado na tabela EDIDC. Cada IDoc tem um registro de controle.
ƒ Registro de dado, ou EDI_DD, ele contém os dados da aplicação. Cada registro
EDI_DD tem uma porção de chaves que contêm uma série de campos descrevendo o
conteúdo do registro. Depois das chaves vem o campo SDATA com tamanho de 1000
bytes do tipo “Long Char”. O campo SDATA guarda os dados da aplicação, e sua
estrutura é determinada pelo campo chave SEGNAM (nome do segmento). Um IDoc
consiste em um ou mais registros de dado. Registros de dado são armazenados na
tabela EDID4.
No SAP segmentos de IDoc aderem-se convenção de nomenclatura. Cada segmento
possui três componentes, e cada componente com prefixo diferente - E1 para tipo de
segmento, E2 para definição de segmento e E3 para documentação de segmento. Por
exemplo, o primeiro segmento do tipo de IDoc DEBMAS02 é E1KNA1M. Sua definição é
contida na estrutura E2KNA1M, e a documentação está na E3KNA1M. Quando o IDoc é
 externalizado, vemos o nome do segmento iniciado com prefixo E2. Na prática, em
todos os casos, usamos somente prefixo E2 para se referir segmentos de IDoc.
ƒ Registro de status, ou EDI_DS. Ele contém informações de estado de IDoc quando
IDoc passa pelo vários estágios de processamento. O registro de status mantém o
histórico de um IDoc. Um IDoc pode ter um ou mais registros de status, onde são
armazenados na tabela EDIDS.

d) Porta
É a representação lógica de canal de comunicação em SAP, com os IDocs sendo os dados
comunicados. São 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.
e) Destino RFC
O destino RFC é o termo que define as características de comunicação ligado a um sistema
remoto onde uma função precisa ser executada. A comunicação R/3-para-R/3 utiliza tRFC
(transactional RFC). O prefixo transactional indica meramente que uma função específica é
executada por unidade lógica de trabalho, que pode ser Mestre de Material, ou a entrega,
ou o faturamento.
f) Códigos de Processo
 Códigos de processo são usados em ALE e EDI para identificar o módulo de função ou API
para ser chamado e conseqüentemente processado. Cada código de processo é associado
a um tipo de mensagem. Códigos de processo tipo outbound são armazenados na tabela
TEDE1 e códigos de processo tipo inbound são armazenados na tabela TEDE2.
g) 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 Lógico). Tipo de
parceiro define vários elementos de ALE e EDI com os parâmetros de comunicação entre
dois ou mais sistemas. Os principais parâmetros são: tipos de mensagem, tipos de IDoc,
códigos de processo, funções parceiro, identificadores da aplicação, funções de mensagem,
tipos de saída e portas.
Tipo de parceiro exerce um papel muito importante pois ele age como um gateway para
comunicação ALE e EDI. Ele transfere mensagens específicas através de tipos de IDoc
definidos para a porta depois da execução de certos módulos de função para
processamento outbound. Ele também pode receber tipo específico de IDoc, e identifica
módulos de função apropriados para que insira dados no banco no caso de interface
inbound.
h) Modelo de Distribuição
No sistema R/3, o Modelo de Distribuição é uma ferramenta que armazena informações
sobre o fluxo de dados entre vários sistemas. O modelo de distribuição armazena dados
que informam quais as mensagens (tipos de mensagem) sejam transmitidas para quais
Sistemas Lógicos. Várias mensagens podem ser transmitidas para um Sistema Lógico, e
uma única mensagem pode ser transmitida para vários Sistemas Lógicos.
2. Guia rápido para criar IDoc de saída – outbound
Vamos criar um IDoc de saída (outbound) usando a BAPI: BAPI_BANK_GETLIST.
1º passo: Criar os segmentos através da transação WE31:
Criar segmento conforme a estrutura BAPI1011_LIST:
Tipo de segmento: ZE1BANKLIST
Descrição breve: Lista de Bancos
Item Nome de campo Elemento de dados
1 BANK_CTRY BANKS
2 BANK_KEY BANKK
3 BANK_NAME BANKA
4 CITY ORT01_GP

Salvar e liberar o segmento.

2º passo: Criar Tipo de IDoc através da transação WE30:
Nome IDoc: ZID_BANKLIST
Descrição: Lista de Bancos
Ligar o segmento ZE1BANKLIST abaixo do nome do IDoc:
Número mínimo: 1
Número máximo: 99999999
Salvar e liberar o tipo de IDoc.
3º passo: Criar Tipo de mensagem através da transação WE81:
Tipo de mensagem: ZMG_BANKLIST
Descrição breve: Lista de Bancos
4º passo: Relacionar tipo de mensagem ao tipo de IDoc através da transação WE82:
Tipo de mensagem: ZMG_BANKLIST
Tipo Básico: ZID_BANKLIST
Release: 46C
5º passo: Criar destino RFC através da transação SM59:
Clicar no botão <Criar>,
Destino RFC: DESTINO_RFC_IDOC005
Tipo de conexão: T
Descrição: Teste de destino RFC para IDoc ZID_BANKLIST
6º passo: Criar porta através da transação WE21:
Posicionar o cursor na palavra RFC Transacional
Portas
+-------RFC Transacional
Clicar o ícone <Criar>
 Selecionar a opção “Gerar nome de porta”, o sistema irá gerar a porta com o próximo
número subseqüente, no nosso caso: A000000025
Descrição: Porta de saída para IDoc ZID_BANKLIST
Destino RFC: DESTINO_RFC_IDOC005
7º passo: Criar um módulo de função através da transação SE37:
Módulo de função: ZALE_GET_BANKLIST
Grupo de função: ZIDOC (criar se for necessário)
Texto breve: Buscar lista de bancos
Importação:
Nome parâmetro Atrib. Tipo referência Valor proposto Opc. Trans
BANK_CTRY LIKE BAPI1011_LIST X
SERIAL_ID LIKE SERIAL-CHNUM '0' X X

Tabelas:
Nome parâmetro Atrib. Tipo referência Opc.
RECEIVERS LIKE BDI_LOGSYS
COMMUNICATION_DOCUMENTS LIKE SWOTOBJID X

Exceção:
ERROR_CREATING_IDOCS
Texto fonte:
*-------------------*
* Tabelas internas
*-------------------*
DATA: BEGIN OF ti_bank_list OCCURS 0.
INCLUDE STRUCTURE bapi1011_list.
DATA: END OF ti_bank_list.
*-------------------*
* Variáveis 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
*----------------*
* Popular registro de controle
* Tipo de mensagem
idoc_control-mestyp = 'ZMG_BANKLIST'.
* Tipo de IDoc
idoc_control-idoctp = 'ZID_BANKLIST'.
idoc_control-serial = sy-datum.
idoc_control-serial+8 = sy-uzeit.
*-------------------*
* Seleção de dados
*-------------------*
LOOP AT receivers.
CLEAR: syst_info.
CALL FUNCTION 'BAPI_BANK_GETLIST'
EXPORTING
bank_ctry = bank_ctry
max_rows = 0
TABLES
bank_list = ti_bank_list.
* call subroutine to create IDoc data-record *
CLEAR: syst_info, idoc_data.
REFRESH idoc_data.
PERFORM inserir_segmento_banklist TABLES ti_bank_list
idoc_data.
* distribute idocs *
REFRESH: idoc_receiver, idoc_comm.
APPEND receivers TO idoc_receiver.
CALL FUNCTION 'ALE_IDOCS_CREATE'
EXPORTING
idoc_control = idoc_control
chnum = serial_id
TABLES
idoc_data = idoc_data
receivers = idoc_receiver
created_idocs_additional = idoc_comm
EXCEPTIONS
idoc_input_was_inconsistent = 1
OTHERS = 2.
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.
* applications do commit work to trigger communications *
COMMIT WORK.
ENDFUNCTION.
*---------------------------------------------------------------------*
* FORM inserir_segmento_banklist *
*---------------------------------------------------------------------*
* Criar IDoc data-record *
*---------------------------------------------------------------------*
FORM inserir_segmento_banklist
TABLES
ti_bank_list STRUCTURE bapi1011_list
idoc_data STRUCTURE edidd.
DATA: ze1banklist LIKE ze1banklist,
ti_ze1banklist LIKE edidd OCCURS 0 WITH HEADER LINE.
* for segment 'ZE1BANKLIST'
CLEAR ti_ze1banklist.
REFRESH ti_ze1banklist.
ti_ze1banklist-segnam = 'ZE1BANKLIST'.
LOOP AT ti_bank_list.
CLEAR ze1banklist.
MOVE-CORRESPONDING ti_bank_list TO ze1banklist.
IF NOT ze1banklist IS INITIAL.
 ti_ze1banklist-sdata = ze1banklist.
APPEND ti_ze1banklist.
ENDIF.
APPEND ti_ze1banklist TO idoc_data.
ENDLOOP.
ENDFORM.
8º passo: Criar código de processo – saída através da transação WE41:
Cód.processo: ZCP_BANKLIST
Módulo de função: ZALE_GET_BANKLIST
Clicar <Enter> (O sistema traz a descrição automaticamente)
Double-click na palavra “Mensagem lógica”
Clicar no botão <Entradas novas>
Tipo mensagem: ZMG_BANKLIST
Salvar o código de processo
9º passo: Atribuir módulo de função a tipo de mensagem e de IDoc através da transação
WE57:
Módulo: ZALE_GET_BANKLIST
Categoria: F
Tp.básico: ZID_BANKLIST
Tipo mensagem: ZMG_BANKLIST
Direção: 1
Salvar.
10º passo: Identificar o sistema lógico do próprio mandante através dos seguintes passos:
Transação: SALE
Abrir a opção:
Preparar sistema receptor e de envio
Instalar sistemas lógicos
Atribuir sistema lógico a mandante
Double-click na linha onde está o mandante do sistema
E descobrir qual o sistema lógico do mandante, no nosso caso é “DEV46”
11º passo: Criar tipo de parceiro através da transação WE20:
Abrir o tipo de parceiro LS (sistema lógico) e selecionar algum outro sistema lógico que não
seja do próprio “DEV46”, o nosso caso escolhemos “BCDEV46”
No parâmetro de saída, clicar o ícone <Criar parâmetro de saída>
Tipo de mensagem: ZMG_BANKLIST
Prt.Destinat: A000000025
Modo de saída: <Transf.imediatam.IDoc>
 Tipo básico: ZID_BANKLIST
Aperte <Enter> e salvar
12º passo: Criar modelo de distribuição através da transação BD64:
Clicar no botão: <Criar visão modelo>
Texto breve: Lista de bancos
Nome técnico: BANKLIST
Selecionar a linha “Lista de bancos” e clicar no botão <Inserir tipo de mensagem>
Visão de modelo: BANKLIST
Emissor: DEV46
Destinatário: BCDEV46
Tipo de mensagem: ZMG_BANKLIST
Salvar o modelo de distribuição.
13º passo: Testar a função para disparar IDoc através da transação SE37:
Função: ZALE_GET_BANKLIST
BANK_CTRY: BR
RECEIVERS: BCDEV46
Executar a função.
14º passo: Listar IDocs enviados através da transação WE05:
Verificar o IDoc criado com o status 03 “Transferência de dados para a porta OK”. - O IDoc
foi enviado para um sistema R/3 ou para um programa externo, através de um RFC
transacional.
3. Guia rápido para criar IDoc de entrada – inbound
Existem duas formas de realizar IDoc de entrada, dependendo da disponibilidade de recursos
no SAP. A primeira forma é aproveitar a estrutura existente de BAPI no SAP, se esta atende a
necessidade do usuário; caso contrario, é necessário criar uma função e configurar o ambiente
para que a entrada do IDoc seja efetuada.
Vamos começar o exemplo pela forma mais fácil, a de aproveitar a estrutura existente de BAPI.

3.1. Criando um IDoc de entrada (inbound) usando BAPI

1º passo: Buscar o “bus” da BAPI através da transação BAPI: BAPI_BANK_CREATE

Na transação BAPI, selecionar o folder “Alfabetic”, abrir a estrutura do ”bank” e clicar na
palavra “create”. Na parte direita da tela double-click a opção “create BAPI List” e depois na
tela inferior mostra o “bus” da BAPI no campo “CtgObjeto”. Anotar o bus. No nosso caso é
“BUS1011”.
2º passo: Gerar interface ALE através da transação BDBG:
Na transação BDBG, entrar o nome do “bus” no campo “CtgObjeto/tp.interface” (BUS1011),
e no campo de “Método”, clicar no match-code, selecionar a opção “CREATE” e depois
clicar no ícone <criar>.
Se o interface já foi criado, então a mensagem “Existe o tipo de mensagem BANK_CREATE
para objeto BUS1011 e método CREATE” é mostrada. Neste caso, podemos consultar o
interface criado clicando o ícone <Verificar interface>. O sistema mostrará o tipo de
mensagem “BANK_CREATE”, o tipo básico (tipo de IDoc) “BANK_CREATE01”, os
segmentos e as funções de entrada (“IDOC_INPUT_BANK_CREATE”) e saída
(“ALE_BANK_CREATE”). Todos estes componentes de interface já foram criados.
Se o interface ainda não foi criado, então o sistema mostra uma janela pedindo o tipo de
mensagem, e depois mostra outra janela para que entre com os dados de tipo de IDoc,
módulos de função de entrada e saída. Após de entrar todos os dados, o sistema gerará
tipo de mensagem, IDoc, os segmentos e as função de entrada e saída automaticamente.
(Tipo de mensagem é gravado na tabela standard EDMSG).
3º passo: Criar código de processo – entrada através da transação WE42:
Na transação WE42, selecionar o código de processo BAPI (double-click)
Double-click na palavra “Mensagem lógica” situada no lado esquerdo da tela.
No table-control do lado direito da tela, verificar se tipo de mensagem “BANK_CREATE”
está cadastrado. Caso contrário, clicar no ícone <Entradas novas>.
Tipo de mensagem: BANK_CREATE
Salvar o código de processo.
4º passo: Atribuir módulo de função a tipo de mensagem e de IDoc através da transação
WE57:
Verificar se o tipo básico “BANK_CREATE01” está cadastrado na transação WE57. Caso
contrário, clicar no ícone <Entradas novas>.
Módulo: BAPI_IDOC_INPUT1
Categoria: F
Tp.básico: BANK_CREATE01
Tipo mensagem: BANK_CREATE
Direção: 2
Salvar.
5º passo: Identificar o sistema lógico do próprio mandante através dos seguintes passos:
Transação: SALE
Abrir a opção:
Preparar sistema receptor e de envio
Instalar sistemas lógicos
Atribuir sistema lógico a mandante
Double-click na linha onde está o mandante do sistema
E descobrir qual o sistema lógico do mandante, no nosso caso é “DEV46”
6º passo: Criar tipo de parceiro através da transação WE20:
Abrir o tipo de parceiro LS (sistema lógico) e selecionar algum outro sistema lógico que não
seja do próprio “DEV46”, o nosso caso escolhemos “BCDEV46”
No “parâmetro de entrada”, clicar o ícone <Criar parâmetro de entrada>
Tipo de mensagem: BANK_CREATE
Cód.processo: BAPI
Processamento através módulo função: <Acionamento imediato>
Teclar <Enter> e salvar os dados.(Os dados são gravados na tabela standard EDP21).
7º passo: Criar modelo de distribuição através da transação BD64:
Clicar no botão: <Criar visão modelo>
Texto breve: Criar banco
Nome técnico: BANKCREATE
Aperte <Enter>
Selecionar a linha “Criar banco” e clicar no botão <Inserir BAPI >
Visão de modelo: BANKCREATE
Emissor: BCDEV46
Destinatário: DEV46
NomeObjeto/Interface: Bank
Método: Create
 Aperte <Enter>
Salvar o modelo de distribuição.
8º passo: Testar a entrada de IDoc através da transação WE19:
Na transação WE19, vamos entrar com o nome de IDoc: BANK_CREATE01 no campo
Tp.básico e executar.
Na tela seguinte, clicar na linha EDIDC, o sistema mostra uma janela para entrar com os
dados de registros de controle:
Destinatário:
Port: SAPTRN (é a palavra “SAP” concatenado com o nome do sistema local,
que no nosso caso é “TRN”)
Nº parceiro: DEV46 (sistema lógico do próprio mandante descoberto no
passo 5)
TpParceiro: LS
Remetente:
Port: A000000025 (criado no exemplo anterior. Se não encontrou então
consultar a página 7 passo 6 sobre como criar a porta)
Nº parceiro: BCDEV46
TpParceiro: LS
Tipo mensagem: BANK_CREATE
Tecle <Enter>
Clicar na linha do segmento “E1BANK_CREATE” e entrar os seguintes dados:
BANK_CTRY: BR
BANK_KEY: 999005 (chave do banco, entrar com uma chave inexistente)
Tecle <Enter>
Clicar na linha do segmento “E1BP1011_ADDRESS” e entrar os seguintes dados:
BANK_NAME: BANCO TESTE IDOC INBOUND S/A
REGION: SP
STREET: RUA FLORIDA 1670
CITY: SÃO PAULO
BANK_NO: 999005
Tecle <Enter>
Clicar no botão <Entrada standard>, o sistema mostra uma janela com as informações
resumidas sobre protocolo de transmissão, teclar <Enter> e um IDoc de entrada é criado.
9º passo: Listar IDocs recebidos através da transação WE05:
Verificar o IDoc criado com o status 53 “Documento de aplicação gravado”. - BAPI CREATE
foi chamado com êxito.
Verificar também a tabela standard BNKA (Mestre de bancos) um novo banco foi criado.