Agente SAP - Centralized Computing Center Management (CCMS)

O Agente SAP usa conexões de Chamadas de Função Remotas (RFC) para pesquisa de Centralized Computing Center Management (CCMS) e coleção de dados de alerta CCMS. Este comportamento é específico para a arquitetura de SAP RFC.

O Agente SAP abre uma conexão RFC dedicada para o sistema SAP que é monitorado pelo agente. O sistema SAP abre, então, uma conexão interna por servidor de aplicativos para coleta de dados por meio de módulos e programas de função. Se os alertas CCMS forem coletados pelo agente, o sistema SAP abrirá uma conexão RFC adicional (interna do sistema) para cada servidor de aplicativos para esse encadeamento de coleção. Quando a coleta de dados for iniciada, uma conexão RFC para o agente será aberta. Em seguida, até o dobro do número de servidores de aplicativos SAP para as conexões RFC adicionais do sistema interno serão abertos.

Você deve assegurar que a instância que está sendo monitorada pode acomodar sessões RFC adicionais, especialmente em grandes sistemas com 10 instâncias ou mais. Quando a carga RFC antecipada para monitoramento puder afetar contrariamente o desempenho do sistema e as tolerâncias, ajuste o parâmetro do perfil SAP

princípio funcional do agente do CCMS SAPCCMSR

Definição

O princípio funcional do agente do CCMS SAPCCMSR foi estendido no caso de o SAPCCMSR estar monitorando um J2EE Engine. Em um caso desse tipo, deve ser possível que o segmento de monitoramento do agente SAPCCMSR não pertença ao sistema de monitoramento central. Isso é obtido estendendo o termo do sistema para incluir componentes Java (como o J2EE Cluster). O agente SAPCCMSR com a opção -j2ee existe para esse propósito.


É mais fácil entender as outras etapas se você usar as seguintes analogias:

ABAP

Java

Sistema ABAP

Cluster J2EE

Servidor de aplicação

Mecanismo J2EE

Processo de trabalho

Máquina Virtual (VM)

Um sistema não é mais apenas uma quantidade de servidores de aplicativos clássicos com um ambiente de tempo de execução ABAP, mas simplesmente um número de componentes associados que possuem um nome de sistema comum. Combinações de instâncias ABAP e instâncias Java também podem criar um sistema, se todas essas partes forem combinadas sob um único ID do sistema.


Você especifica o ID do sistema e o número do sistema da instância Java monitorada durante o registro do agente em seu arquivo de perfil (consulte Arquivo de Perfil dos Agentes do CCMS).

Ao monitorar, deve ser possível exibir os dados para as instâncias ABAP e as instâncias Java do mesmo sistema em um CCMS central sob o ID do sistema monitorado. Tanto quanto possível, uma instância Java não deve ser diferente de uma instância ABAP; Também deve ser possível monitorar todas as instâncias com o mesmo ID de sistema localmente como uma unidade de sistema.

Exemplo
Sistema monitorado sem instâncias ABAP
O SAPCCMSR monitora uma instância de um sistema Java e se registra com um sistema central CEN. A conexão com o CEN também é a conexão RFC primária.




Este gráfico é explicado pelo respectivo texto

Sistema Monitorado com Instâncias Java e ABAP
O SAPCCMSR monitora uma instância de um sistema em que ainda há pelo menos uma instância ABAP. Nesse caso, o agente deve ser registrado principalmente no sistema local, para que o sistema possa ser monitorado localmente como uma unidade.




Este gráfico é explicado pelo respectivo texto

Sistema monitorado com instâncias Java e ABAP e um CEN
Além do caso descrito acima, o sistema local, ao qual a instância Java pertence, pode ser monitorado por um sistema de monitoramento central CEN:

Notas sobre diferentes tipos de Dumps

Vários erros relacionados a DUMPS

Ao me deparar com novas situações, vou acrescentar a este documento de tempos em tempos.

RAISE_EXCEPTION

Um módulo de função gera uma exceção que não foi interceptada por um programa mais alto na pilha. Se isso ocorrer em um programa do cliente, o desenvolvedor precisará manipular a exceção no programa de chamada. Se isso acontecer em um programa SAP, pode ser uma situação inesperada. Muitas vezes é útil para este tipo de falha olhar os valores de sy-msgid e sy-msgno . Você também deve procurar por notas que contenham o ID e o número da mensagem e / ou palavras-chave importantes da seção "Como corrigir o erro".

RFC_ATTACH_GUI_FAILED

Isso geralmente acontece quando um módulo de função habilitado por RFC é executado, que então faz algo conectado ao manuseio de telas. Como não tem tela, falha. Isso também pode acontecer se o SAPGui (ou componentes dele, como um BEX) tiver um problema ou estiver instalado incorretamente.

LOAD_PROGRAM_LOST

O programa que você estava executando foi alterado enquanto você estava executando. Em um BI (e outros ambientes similares) isso acontece com bastante frequência se você estiver em seções do sistema que geram código - como o desenvolvimento de rotinas em transformações. Não há muito a fazer além de reiniciar a transação que você estava executando. Para evitar isso no RSA1, se você está fazendo um monte de desenvolvimento complicado, é uma boa idéia reiniciar a transação de tempos em tempos.

DBIF_RSQL_SQL_ERROR

Indica um problema ocorrido no banco de dados. Você pode encontrar mais informações no log do sistema via SM21. A natureza exata da falha é geralmente vista na seção "Como corrigir o erro". Se isso ocorrer no código SAP standard, pode haver uma nota corretiva. Ele pode estar conectado com a configuração do banco de dados, portanto, se a causa não for óbvia (como um SQL dinâmico malformado de um de seus próprios programas), talvez valha a pena conversar com sua equipe de base.

MESSAGE_TYPE_X

Se esta mensagem aparecer, significa que o programa encontrou uma situação que simplesmente não sabia o que fazer. Na seção "Análise de erro", você verá o texto curto e longo da mensagem de erro. Às vezes, o erro indica dados inconsistentes, às vezes, como Rob Dielemans aponta, ele pode ser usado deliberadamente durante o processo de desenvolvimento.

Se, durante o desenvolvimento, você simplesmente quer saber se uma determinada parte do código é executada (geralmente em segundo plano, como fluxo de trabalho), você apenas codifica uma mensagem do tipo X com alguns valores, como sy-uname ou outra variável. Essa é uma maneira muito boa de descobrir exatamente o valor de um parâmetro quando as diferenças podem ocorrer na depuração.

ASSIGN_TYPE_CONFLICT

O mais provável é um erro de programação. Esta mensagem indica que está ocorrendo um ASSIGN que está indo para um símbolo de campo digitado incorretamente. Verifique o extrato de código-fonte para ver exatamente onde o problema ocorre e verifique cuidadosamente se a digitação do objeto corresponde.

OBJECTS_OBJREF_NOT_ASSIGNED_NO

Foi feita uma tentativa de acessar um objeto (o tipo de classe é fornecido), que não foi instanciado. O mais provável é um erro de programação.

TSV_TNEW_PAGE_ALLOC_FAILED e MEMORY_NO_MORE_PAGING

Isso indica que seu processo ficou sem memória. Isso pode ser um problema de programação - verifique o tamanho das tabelas internas e a quantidade de dados que você está selecionando. Talvez haja um loop eterno que apenas continua adicionando a uma tabela. Pode ser um problema de hardware - que simplesmente não há memória suficiente disponível. Esse tipo de erro pode ser difícil de rastrear, já que o local onde a memória está realmente esgotada pode variar. “O que você pode fazer” mostra a quantidade de memória dos vários tipos que estavam disponíveis. Pode haver informações na seção “Análise de erros”, que mostra exatamente qual tabela interna não pode mais ser esticada para conter mais dados.

UNCAUGHT_EXCEPTION

Este é o equivalente orientado a objetos de RAISE_EXCEPTION . Isso significa que uma exceção baseada em classe foi levantada em um método / módulo de função / formulário que não foi pego mais alto. Geralmente isso indica um erro de programação. Eu vi tentativas de corrigir isso, usando CATCH cx_root e, em seguida, continuando o processamento. Essa é uma maneira muito ruim de corrigir o erro, já que ele simplesmente ignora a causa da exceção. Ignorar uma exceção como essa é como ignorar a sub-regra não-zero.

COMPUTE_INT_ZERODIVIDE

Exatamente o que diz - foi feita uma tentativa de dividir por zero. Isso é um erro de dados ou programação. Na verdade, é sempre um erro de programação, uma vez que qualquer divisão deve sempre verificar se o denominador é zero e corrigir uma condição de erro, se for.

RFC_NO_AUTHORITY

Simples um presente. O usuário que tentou executar um módulo de função habilitado por RFC, via RFC, não foi autorizado via objeto de autorização S_RFC para executar o módulo de função. O nome do módulo de função está no texto curto. O nome do ID do usuário está na seção “O que aconteceu?”.

TEMPO ESGOTADO

Há uma configuração básica que define um limite para o tempo de execução de uma transação ou relatório, geralmente quinze minutos. Se um processo de diálogo exceder esse limite, o kernel o localizará e interromperá o programa com um dump de TIME_OUT. Causas comuns são:

• Usuário selecionando dados em excesso - como todas as empresas ou todas as áreas de controle.
• Um erro de programação resultando em um loop infinito
• Programação ineficiente. Por exemplo, usando tabelas STANDARD em vez de HASHED ou SORTED, faz loops dentro de loops, selecionando os mesmos dados novamente e novamente, etc.

A solução comum é estender o tempo de execução permitido. No entanto, esse deve ser o último recurso, pois só corrige o sintoma, não a causa raiz e, conforme os volumes de dados aumentam, é provável que você atinja o novo limite eventualmente. É muito melhor consertar o programa. Quando os usuários selecionam muitos dados, por exemplo, a tela de seleção pode ser ajustada para evitar isso. Se uma seleção ampla for necessária, talvez o programa possa ser executado em segundo plano e, se necessário, preencher uma tabela de banco de dados que possa ser relatada.

sap_basis (Monitoramento do SAP Basis)

O probe sap_basis (SAP Basis Monitoring - Monitoramento do SAP Basis) monitora a integridade e o desempenho do cenário SAP. Este probe ajuda as empresas a monitorarem seus aplicativos SAP críticos à missão. O probe sap_basis pode monitorar as instâncias do SAP, as instâncias de banco de dados e sistemas de arquivos, que são os principais componentes de uma implantação do SAP Basis. Consulte Métricas do sap_basis para compreender os recursos de monitoramento do probe.
O probe permite que os administradores do Basis tenham uma visão holística do ambiente SAP Basis e os ajuda a detectar problemas antes que eles afetem os usuários finais. Com esse probe, a equipe do Basis pode monitorar o desempenho de seus aplicativos em um único console, ver os alertas assim que as ocorrências surgem, diagnosticar e solucionar os problemas, acompanhar as tendências e planejar usando os gráficos no USM (Unified Service Manager - Gerenciador de serviços unificados). O probe monitora os códigos de transação do SAP a partir da camada do SAP Basis, usando o SAP CCMS (Computing Center Management System), em intervalos personalizáveis.
Recursos de monitoramento:

•  Transações críticas de rastreamento de desempenho do SAP, incluindo:
  • Solicitações de atualização (SM13)
  • Desempenho do sistema SAP (ST03)
  • Visão geral de processos de trabalho (SM50)
  • Mensagem de log do sistema (SM21)
  • Memória SAP (ST02)
  • Visão geral sobre a instância do servidor de aplicativos (SM51)
  • RFC transacional (SM58, SMQ1, SMQ2, SMRQ, SMQS)
  • RFC em fila (SMQ1, SMQ2, SMRQ, SMQS)
  • CCMS (RZ20)
  • Tarefas em segundo plano (SM37)
  • Monitoramento e administração de servidor de banco de dados SAP (DB02)
  • Status de backup do SAP (para Oracle) (DB12, DB13)
  • Atualização das estatísticas do banco de dados (DB13)
  • Impressão — erros de spool (SP01/SP02)
  • Resumo do banco de dados (ST04)
  • SAPConnect: Enviar o status da solicitação (SOST)
• Serviços, utilização de recursos, backups, esquemas, estatísticas de mesclagem e estatísticas de log para a implantação local do banco de dados do SAP HANA e do HEC (HANA Enterprise Cloud da SAP). 
• Principais indicadores de desempenho para implantações do SAP NetWeaver (pilha Java) usando os Java Web Services. Essas métricas permitem monitorar o estado dos serviços, do desempenho e do kernel do Java, os quais são parte integrante do sistema SAP NetWeaver.
• Status do canal, contagem de status do canal, cache do servidor de integração e do adaptador, status das mensagens e contagem do status das mensagens são os principais componentes das implantações do SAP PI (Process Integration) e PO (Process Orchestration).
• Desempenho do servidor, utilização de recursos, disponibilidade do sistema, tempo de resposta, pico de carga e tarefas de pico para o SAP BOBJ (BusinessObjects) BI.

É possível definir os alarmes a serem gerados quando os limites especificados forem violados ou quando o servidor do SAP estiver indisponível. Também é possível configurar os modelos de fábrica para monitorar o SAP ABAP, SAP HANA, SAP PI, SAP NetWeaver e o SAP BOBJ, e usar os painéis prontos para uso para exibir o estado desses produtos SAP.

Princípio Funcional dos Agentes do CCMS - SAP

As informações de tempo de execução para os objetos de monitoramento são armazenadas nos segmentos de monitoramento. Um agente do CCMS sempre usa exatamente um segmento de monitoramento que está na memória do processo local ou na memória compartilhada local.

· SAPCCMSR

Esse agente monitora os componentes nos quais não há instância ativa do SAP (como arquivos de log, TREX, bancos de dados independentes ou componentes do sistema operacional). O SAPCCMSR está intimamente ligado ao sistema de monitoramento central de monitoramento.

Após sua instalação, o agente do CCMS SAPCCMSR tenta se conectar a um segmento de monitoramento na memória compartilhada quando é iniciado. Se esse segmento ainda não existir, o agente o criará. O SAPCCMSR sempre trabalha em um segmento de memória compartilhada que é independente da execução de sistemas SAP. O sistema de monitoramento central deve ter um status de liberação de pelo menos o SAP R / 3 4.6B.


SAPCCM4X

Este agente melhora o monitoramento de instâncias ABAP com o SAP R / 3 4.X ou superior. O sistema de monitoramento central deve ter um status de liberação de pelo menos o SAP R / 3 4.6C. Esse agente fornece uma rota de conexão alternativa para as informações de monitoramento na memória compartilhada de uma instância ABAP. Como este método de conexão alternativo não requer um processo de trabalho livre, o método de acesso é independente dos estados de erro da instância do SAP e, portanto, é mais robusto.

Os sistemas do SAP R / 3 4.0 possuem seu próprio ambiente de tempo de execução de arquitetura de monitoramento CCMS. Isso significa que eles têm seu próprio segmento de monitoramento na área de memória compartilhada do sistema em execução. Após a instalação, o agente SAPCCM4X tenta se anexar e trabalhar com esse segmento de monitoramento na memória compartilhada quando é iniciado.

Se esse segmento não existir (ou seja, se o sistema monitorado não estiver em execução), o agente não o criará, para evitar a interferência no gerenciamento de memória compartilhada no sistema de reinicialização. Nesse caso, o agente SAPCCM4X trabalha com o segmento de monitoramento que ele cria em sua memória de processo e cujo conteúdo é sincronizado com o sistema monitorado. O SAPCCM4X verifica constantemente se o sistema monitorado está ativo novamente e, quando está, trabalha com o segmento de monitoramento na memória compartilhada novamente, após a sincronização.

O sistema de monitoramento central tenta primeiro primeiro ler os dados do sistema monitorado através do destino RFC do agente CCMS. Se o agente não estiver ativo, o sistema lê os dados de monitoramento da instância do SAP monitorada usando o RFC padrão, como anteriormente (para obter mais informações, consulte a Nota SAP 322075). Observe que você ainda precisa da conexão RFC padrão, mesmo se estiver usando o SAPCCM4X.





SAPCM3X

Esse agente permite o monitoramento de instâncias do SAP com o SAP R / 3 3.X por meio da arquitetura de monitoramento do CCMS. Esses sistemas não possuem seu próprio ambiente de tempo de execução de arquitetura de monitoramento do CCMS. Portanto, o SAPCM3X funciona sempre com um segmento de monitoramento que ele cria em sua memória principal (para obter mais informações, consulte a Nota SAP 308061).

Comunicação
Um agente do CCMS se comunica com o sistema de monitoramento central usando o RFC.

· Como servidor RFC, fornece acesso aos dados no segmento de monitoramento. Este acesso é, por exemplo, usado na transação RZ20. O agente cria automaticamente os arquivos de configuração local e o destino RFC no sistema central durante o registro.

Você pode definir a frequência da consulta pela arquitetura de monitoramento no Monitor de alertas. Para fazer isso, chame a transação RZ20, selecione um nó no monitor desejado, escolha Propriedades e, na ficha de registro Métodos, corrija o valor para Iniciar o método de coleta de dados a cada.

Nota

A frequência máxima dessa consulta depende se o programa subjacente é um programa ABAP ou um programa em C. No caso de programas ABAP, a frequência máxima é de cinco minutos, enquanto a frequência máxima para programas em C (e, portanto, para agentes do CCMS) é de um minuto.

· Como cliente RFC, ele envia, de forma independente, alertas e valores para os atributos de monitoramento para o sistema SAP de monitoramento central (tecnologia push). Esses dados são então armazenados em um cache para permitir que o sistema os exiba mais rapidamente ou aciona métodos centrais de auto-reação lá. Isso melhora o desempenho, pois o sistema de monitoramento central não precisa mais consultar periodicamente os agentes.

O sistema de monitoramento central deve ter um status de release de pelo menos o SAP Web AS 6.10 para o relatório automático de alertas. A partir desta versão, a ativação da tecnologia push é obrigatória. A partir do SAP Web AS 6.20, os agentes também relatam automaticamente os valores dos atributos de monitoramento.

Todos os agentes do CCMS podem processar várias tarefas simultaneamente (procedimento multi-thread). Isso significa que eles podem simultaneamente:

· Coletar dados automaticamente

· Processar solicitações como um servidor RFC

· Enviar dados para o sistema central como um cliente RFC

Agentes do CCMS - SAP

A arquitetura de monitoramento fornece uma infraestrutura para monitorar seu ambiente de TI e seus componentes. Os dados de monitoramento são armazenados na memória compartilhada de cada servidor com uma instância do SAP em execução ou um agente em execução.

O acesso de leitura e gravação do sistema de monitoramento central é possível de duas maneiras diferentes:

· Usando uma interface ABAP definida, no caso de uma instância do SAP

· Usando o agente do CCMS, no caso de qualquer servidor no qual o agente esteja instalado e ativo

Agentes CCMS são processos independentes com uma interface através de RFC para um sistema de monitoramento central e uma interface para a memória compartilhada. Portanto, eles permitem que você:

· Incluir componentes do SAP que não tenham uma interface ABAP, como o J2EE Engine ou o Internet Transaction Server (ITS)

· Incluir componentes que não fazem parte do ambiente SAP

· Disponibilizar uma rota de conexão alternativa para um segmento de memória compartilhada

· Otimizar o desempenho ao ler e gravar atributos e alertas de monitoramento, usando a tecnologia push

· Conecte-se a um segmento de memória compartilhada sem exigir um processo de trabalho gratuito

Os agentes também possibilitam funções de monitoramento inteiramente novas dentro da arquitetura de monitoramento:

· Você pode monitorar qualquer arquivo de log.

· Você pode monitorar processos no nível do sistema operacional. O monitoramento real é executado usando o coletor do sistema operacional SAPOSCOL. Para obter informações detalhadas sobre isso, consulte Coletor do sistema operacional SAPOSCOL.

· Você pode criar reações automáticas centrais nas quais um método de reação automática é iniciado no sistema de monitoramento central como uma reação a um alerta em um sistema monitorado. Para obter informações detalhadas sobre isso, consulte Configuração de métodos de reação automática central.

Agentes monitoram dados de rede, incluindo:

¡A configuração do ambiente de rede, como uma interface ou Sistema de Nomes de Domínio (DNS)

¡Métricas de rede, como o tempo gasto para uma resolução de endereço DNS

Considerações de implementação
Você precisa de agentes CCMS para monitoramento central, uma vez que os dados de monitoramento são transferidos principalmente entre os componentes monitorados e o sistema de monitoramento central usando os agentes do CCMS. Para obter informações sobre como configurar o monitoramento central, consulte Configurando a arquitetura de monitoramento.

Dicas - SAP - CCMS

CCMS

• Na infra-estrutura do CCMS, se o sistema identificar um problema, ele deve executar uma reação automática, como informar a pessoa responsável.

• Os alertas de mensagens concluídas não são mais armazenados no segmento de monitoramento, mas em uma tabela de banco de dados ( ALALERTDB ). Esta tabela deve ser limpa regularmente (reportar RSALDBRG ). As mensagens completas ainda podem ser exibidas usando o Histórico de alertas.

• Do ponto de vista da segurança, é recomendável que você defina também uma segunda conexão RFC entre os sistemas, com a qual os métodos de análise podem ser iniciados no sistema remoto a partir do sistema de monitoramento central. Se ocorrer um problema, você poderá ramificar diretamente do monitor central para o sistema remoto para analisar a situação com mais detalhes.

• A SAP recomenda que, para o seu trabalho regular, você crie seus próprios monitores que exibem precisamente os dados entre sistemas ou locais necessários para o seu trabalho. Os sets e monitores entregues pela SAP não podem ser modificados.

• Os valores de limite devem ser armazenados localmente em todos os sistemas. No entanto, em vez de manter os mesmos valores limite em todos os sistemas, a SAP recomenda que você atualize os valores no sistema de monitoramento central e distribua-os aos sistemas SAP monitorados usando o sistema de transporte.

• Os monitores SAP fornecidos devem sempre ser usados ​​apenas como modelos. Os monitores copiados são então ajustados aos requisitos do cliente.

• Transferir o mínimo de dados possível pelo RFC

• Antes de criar seu próprio monitor, você deve esclarecer a finalidade do monitor. O monitor deve exibir o mínimo de dados possível da forma mais clara possível.

• O pré-requisito para transportar os valores de limite para outros sistemas SAP é que você os armazenou nas variantes de propriedades.
• Na conexão RFC usada para o início do método de análise, não insira um usuário, mas verifique o campo Usuário atual .

• Como um valor guia global, a SAP recomenda 10-20 atributos de monitoramento para cada instância monitorada no monitor central.
• Observe a convenção de nomenclatura que seu conjunto de monitores não deve começar com o SAP.

VISÃO GLOBAL - sobre IDoc

O IDoc é um objeto SAP que transporta dados de uma transação comercial de um sistema para outro na forma de mensagem eletrônica. IDoc é um acrônimo para I ntermediate Doc ument. O objetivo de um IDoc é transferir dados ou informações do SAP para outros sistemas e vice-versa. A transferência do SAP para o sistema não SAP é feita via subsistemas EDI (Electronic Data Interchange), enquanto para a transferência entre dois sistemas SAP, o ALE é usado.

O IDoc pode ser acionado no sistema SAP ou no subsistema EDI.Isso depende da direção na qual o IDoc é enviado e é chamado como IDoc de entrada e IDoc de saída de acordo. No caso de fluxo de saída, o IDoc é acionado no SAP por meio do controle de mensagens do documento, que é então enviado ao subsistema EDI.EDI converte os dados do IDoc em XML ou formato equivalente e, em seguida, envia os dados para o sistema parceiro através da Internet.

Para o fluxo de entrada, o EDI converte os dados do parceiro e o IDoc é criado no SAP. Após o processamento bem-sucedido deste IDoc, o documento de aplicação é lançado no SAP.

PADRÕES EDI E IDOC

“EDI is electronic exchange of business document between the computer systems of business partners, using a standard format over a communication network”. EDI stands for Electronic DataInterchange.

Para transmissão de informações eletronicamente, dois padrões amplamente utilizados são ANSI ASC X12 e EDIFACT. O ANSI ASC X12 é um comitê formado por representantes de grandes organizações, órgãos governamentais e empresas de software de EDI que define padrões e diretrizes para o intercâmbio de informações sobre o EDI. UN / EDIFACT significa EDI das Nações Unidas para Administração, Comércio e Transporte e foi formado em 1985 usando ANSI X12 e UNTDI (intercâmbio de dados de comércio das Nações Unidas) como padrões básicos. ANSI X12 descreve o documento de negócios como transações e cada transação é representada por um número de três dígitos, por exemplo, 850 - Pedido de Compra, 855 - Reconhecimento de Pedido de Compra.EDIFACT descreve documentos comerciais como mensagens, representados por nomes padrão, por exemplo, ORDERS para pedidos.

TERMINOLOGIAS DO IDOC

TIPO DE IDOC (BASIC)

Os tipos de IDoc são baseados nos padrões EDI e principalmente nos padrões EDIFACT. 

Tipos Básicos (ou Tipo de IDoc) define a estrutura de um IDoc. Cada tipo básico descreve segmentos IDoc padrão, formato de campos de dados e seu tamanho. Tipo básico também define o número de segmentos e campos em um IDoc. Todos os campos necessários para transmissão de mensagem para uma transação comercial específica são mapeados em segmentos diferentes. Ele também define a estrutura e o relacionamento de segmentos de IDoc junto com segmentos obrigatórios e opcionais.

EXTENSÃO DO IDOC

O tipo básico contém todos os campos padrão necessários para realizar uma transação comercial. No entanto, se algum valor adicional precisar ser enviado ao parceiro, poderemos usar o recurso IDoc Extension. A extensão IDoc é a extensão do tipo básico e contém segmentos e campos IDoc personalizados adicionais que não estão disponíveis no tipo básico padrão.

SEGMENTOS DO IDOC

Os segmentos de IDoc contêm os dados reais enviados ourecebidos de um parceiro. Esses segmentos contêm os valores reais enviados como parte da transmissão do IDoc.

SEGMENTOS DE PAIS E CRIANÇAS

O segmento de IDoc é denominado como segmento pai se contiver seus próprios segmentos. Os segmentos dependentes são chamados de segmentos filhos.

IDOCS INBOUND / OUTBOUND

Os IDocs enviados fora do sistema são denominados como IDocs de saída e os que são recebidos no sistema são chamados de IDocs de entrada.

DIREÇÃO DO IDOC

Isso significa que a direção é para qual informação é enviada e é semelhante à terminologia usada nos correios. Se a informação for enviada para fora do sistema, a direção é a caixa de saída quando é recebida no sistema e a direção é a caixa de entrada. Na direção da Caixa de Saída do SAP, representa “1”, ou seja, a caixa de saída e a direção da Caixa de Entrada são representadas por “2”.

PARCEIRO

Parceiro é o parceiro de negócios com o qual a troca de informações deve ocorrer usando o IDoc. Pode ser um fornecedor ou cliente ou qualquer outro sistema. Dependendo da direção da informação na qual a informação é enviada, ela desempenha um papel de “parceiro de envio” ou “parceiro de recebimento”.

TIPO DE PARCEIRO

O tipo / função de parceiro é usado para identificar parceiros nos sistemas sap. O tipo de parceiro é KU para o cliente, LI para o fornecedor e LS para o sistema lógico.

TIPO DE MENSAGEM

O processamento de IDoc envolve a transmissão ou o recebimento do documento na forma de uma mensagem, cada qual representando um documento no SAP. Esses documentos podem ser Pedido, Confirmação de Envio, Notificação de Envio Antecipado, Entrada de Mercadorias ou Fatura. O tipo de mensagem é associado ao tipo básico de IDoc (tipo básico) e define o tipo de dado ou documento que é trocado com o parceiro.

CÓDIGO DE PROCESSO

O código do processo contém os detalhes do módulo de função que são usados ​​para o processamento do IDoc. O tipo de mensagem pode ser vinculado ao código do processo.

PORTA

Porta IDoc contém as informações sobre a maneira como os dados são enviados entre o sistema de origem ou de destino. O tipo de porta define as informações contidas na porta. Para o tipo de porta "Internet", a porta conterá o endereço IP do sistema de destino. Para o tipo de porta “arquivo”, as informações do diretório ou nome do arquivo são mantidas. A porta “tRFC” contém informações sobre o destino RFC do sistema de destino. Para transmissão IDoc usando ALE “tRFC” as portas são usadas.

MANUTENÇÃO DO PERFIL DO PARCEIRO

PERFIL DO PARCEIRO (WE20)

O perfil do parceiro deve ser mantido para todos os parceiros de negócios para os quais queremos enviar ou receber os IDocs. O TCODE para manter o perfil do parceiro é WE20.

Clicar duas vezes no parceiro mostrará a seguinte tela:

O perfil do parceiro contém parâmetros para o processamento de entrada e saída de IDocs. Para cada tipo de mensagem, podemos atualizar opções de entrada / saída, controle de mensagens, opções de pós-processamento e informações de contato nos parâmetros de entrada e saída.

OPÇÕES DE ENTRADA (PARÂMETROS DE ENTRADA)

Isso envolve porta emissor / receptor, modo de saída e relação ao tipo de IDoc, ou seja, tipo básico e extensão.

CONTROLO DA MENSAGEM (PARÂMETROS DE PARTIDA)

Contém o aplicativo para o qual o IDoc será criado, por exemplo, EF para pedido, o tipo de mensagem do aplicativo que acionará o IDoc e o código de processo que converterão o documento SAP em um IDoc. Por exemplo, se o pedido deve ser enviado ao fornecedor AXXXXZ, então, na opção de saída do parceiro AXXXXZ, precisamos atualizar o tipo de mensagem ZXX1 e vinculá-lo ao Código de processo ME10. Assim, quando o tipo de mensagem ZXX1 é acionado no pedido, um IDoc será criado para o fornecedor parceiro AXXXXZ.

O código de processo é vinculado ao módulo de função no SAP, que converte os dados do aplicativo em um IDoc. Módulos de função padrão são fornecidos pela SAP para essa conversão, mas também podem ser personalizados de acordo com as necessidades do negócio.

Change Message Indicator indica se o IDoc é enviado como uma notificação de mudança. Por exemplo, as mensagens de modificação Pedido de compra são enviadas ao fornecedor usando o tipo de mensagem padrão EDI 860. 

O tipo de mensagem separado deve ser acionado no pedido de compra para a modificação do pedido. Uma linha adicional com o tipo de mensagem de modificação deve ser adicionada na guia Controle de mensagem com o indicador de mudança de mensagem ativado.

OPÇÕES DE ENTRADA (PARÂMETROS DE ENTRADA)

O código do processo de opções de entrada é atualizado apenas na tela Entrada. O processamento de IDocs pode ser acionado pelo programa em segundo plano e acionado imediatamente.

PÓS-PROCESSAMENTO (PARÂMETROS DE ENTRADA / SAÍDA)

Na opção de pós-processamento, podemos manter os detalhes do fluxo de trabalho dos usuários ou das posições para os quais uma notificação de erro será enviada se um processamento do IDoc falhar.

TELEFONIA (PARÂMETROS DE ENTRADA / SAÍDA)

Também podemos manter os detalhes de contato na opção de telefonia.

EDI STANDARD (PARÂMETROS DE ENTRADA)

A tela padrão do EDI contém os detalhes da terminologia padrão do EDI usada para a transmissão do IDoc.

Por exemplo, o Tipo de mensagem 850 é um padrão EDI para o IDoc de pedido de compra e está vinculado a ordens de tipo de mensagem IDoc .

ESTRUTURA E REGISTROS DO IDOC

ESTRUTURA

A estrutura do IDoc é dividida em registros de controle, registros de dados e status.

Esses registros são armazenados nas tabelas transparentes no SAP.Estes são EDIDC, EDID4 e EDIDS.

CONTROLO DE REGISTO (EDIDC)

Ele contém informações como número do IDoc, direção, status do IDoc, tipo básico, tipo de mensagem, parceiro (remetente / destinatário), data e hora da criação / atualização, arquivo de troca ou número ISA, etc.

Registro de dados (EDID4)

Contém os detalhes dos segmentos do IDoc.

O segmento de IDoc possui campos que contêm os dados necessários para lançar os documentos.

REGISTROS DE STATUS (EDIDS)

O IDoc Status define o status de processamento do IDoc. Os status de IDoc são usados ​​para rastrear o IDoc e seus vários estados de processamento. Números de status representa o status do IDoc. O status atual do IDoc está presente no registro de controle.

Os números do status inicial são 64 para entrada e 03 para saída. O status de sucesso é 53 para entrada e 16 para IDocs de saída.

ENVIANDO E RECEBENDO IDOCS

ACIONANDO UM IDOC DE SAÍDA

Os IDocs de saída podem ser acionados a partir dos tipos de mensagem de saída de Pedidos, fornecimentos, Documentos do material, faturas, etc. A figura a seguir mostra que uma vez processada a saída ZXX1 do PO XXXXXXX1, um IDoc “000000XXXXXXXXX1” é adicionado / criado.

O relacionamento entre o IDoc e o documento do aplicativo pode ser encontrado de duas maneiras:

1. Guia Relacionamento do IDoc

2. Guia Relacionamento do Documento de Aplicação, por exemplo, PO, SO, Documento de Material, etc.

O status inicial deste IDoc será 30, que após o processamento bem-sucedido será convertido em status 16.

Um IDoc de saída bem-sucedido passará por todos os status acima na ordem inversa (01-03-18-06-12-16). Cada status representa uma etapa de validação de IDoc. Se um IDoc passar todas as validações, ele atingiria o status 16. Essas etapas de validação diferentes para IDocs de saída são explicadas abaixo:

01: Geração de IDoc bem sucedida

30: O IDoc está pronto para ser processado pelo trabalho de processamento de IDoc

03: Dados IDoc são passados ​​para a porta

18: IDoc acionou com êxito o subsistema EDI

06: Dados do IDoc traduzidos para o formato EDI

12: IDoc é despachado com sucesso para o parceiro

16: O parceiro recebeu o IDoc com sucesso

O IDoc pode falhar em qualquer uma das etapas acima durante a validação.

RECEBENDO UM IDOC DE ENTRADA

O status inicial de um IDoc de entrada é 64 e o status bem-sucedido é 53.

Diferentes etapas de validação para IDocs de entrada são explicadas abaixo:

50: IDoc recebido com sucesso no sistema

64: IDoc está pronto para ser processado pelo trabalho de processamento de IDoc

53: Documento de aplicação criado e salvo com sucesso. O número do documento pode ser encontrado expandindo o nó de status 53

Um IDoc de entrada passa por todos os status acima na ordem inversa (50-64-53).

PROCESSAMENTO DE IDOC

PROCESSAMENTO AUTOMÁTICO / IMEDIATO

Nesse caso, o IDoc é processado imediatamente conforme gerado ou adicionado ao sistema. O cheque “Transferir IDoc imediatamente” é selecionado em Opções de saída e “Ativar imediatamente” é selecionado em Opção de entrada. Essas verificações geralmente são usadas quando a troca de informações em tempo real é necessária entre dois sistemas.

PROCESSAMENTO MANUAL

Os IDocs também podem ser processados ​​manualmente usando o TCODE BD87 no SAP.

PROCESSAMENTO ATRAVÉS DO TRABALHO DE FUNDO

O processamento de IDoc por segundo plano é a maneira mais preferida de processar os IDocs. Os seguintes programas são usados ​​no processamento dos IDocs usando a tarefa em segundo plano:

RBDAPP01 - IDocs de entrada

RSEOUT00 - IDocs de saída

REPROCESSANDO IDOCS

Com base nos status do IDoc, diferentes programas podem ser usados ​​para o reprocessamento de IDocs com falha.Estes são dados abaixo:

TESTANDO E EDITANDO IDOCS

Se um IDoc contiver erros nos dados, esses IDocs poderão ser editados usando o TCode WE02 ou WE05. Quando um IDoc é editado, as informações do IDoc original (backup) são salvas em um Novo IDoc sob o status 70 (para entrada) / 33 (para saída). Esses IDocs permanecem no sistema apenas para referência e não podem ser processados. O status do IDoc editado se torna 69 (entrada) e 32 (saída). Esses IDocs podem então ser processados ​​usando transações BD87 ou trabalhos em lote.

A depuração de IDocs pode ser feita usando copiando os IDocs usando o TCode WE19. WE19 é uma ferramenta de teste para processamento de IDocs. O WE19 copia o IDoc existente e cria um novo IDoc que pode ser modificado de acordo com as necessidades de teste. O IDoc recém gerado também pode ser processado usando o BD87.

CONVERTENDO O STATUS DO IDOC

O relatório RC1_IDOC_SET_STATUS pode ser usado para alterar o status do IDoc. Mudanças de status são geralmente necessárias para mover um IDoc para o status 68 - sem processamento adicional

PESQUISANDO IDOCS NO SAP

TCODE WE02 / WE05: PESQUISA GERAL

Os IDocs podem ser exibidos no sistema via TCODE WE02 e WE05.Se o número do IDoc não for conhecido, a pesquisa poderá ser feita com base na Data, Direção, TIPO BÁSICO, TIPO DE MENSAGEM e NÚMERO DO PARCEIRO. O número do parceiro pode ser encontrado nas Mensagens de Saída dos documentos.

A pesquisa de IDocs também pode ser feita com base na referência do arquivo ISA ou Transfer.

TCODE WE09: PESQUISANDO DADOS EM SEGMENTOS DO IDOC

Se estivermos procurando informações específicas nos segmentos de IDocs, isso pode ser encontrado usando o TCODE WE09. Isso é útil se você estiver procurando por uma informação específica em um tipo similar de IDoc dentro de segmentos IDoc. Por exemplo, se você quiser pesquisar um determinado número de Pedido de compra, por exemplo, 100000001 em vários IDocs que se encontra no segmento E1EDK01 de um IDoc no campo BELNR. Em seguida, a pesquisa pode ser executada da seguinte maneira.

VALIDAÇÃO DE IDOC, ERROS IDOC COMUNS E SOLUÇÃO

Embora a falha do IDoc possa não estar relacionada a nenhum dos motivos mencionados acima, a melhor maneira de encontrar o erro do IDoc é comparar o IDoc existente com o bom exemplo. Um bom exemplo de IDoc pode ser facilmente pesquisado com qualquer um dos métodos de busca do IDoc, conforme descrito acima.

DOCUMENTAÇÃO PARA TIPOS IDOC

A documentação do IDoc pode ser encontrada usando o TCODE WE60 e pode ser útil para obter informações do Tipo de IDoc ou seu segmento específico. Também fornece informações como segmentos obrigatórios e opcionais, número mínimo e máximo de segmentos, etc.