Packs SAP (PP, QM, PM)

Um pack é um conjunto de interfaces prontas para um cenário de negócio. Em vez de descobrir qual BAPI chamar, quais campos ela exige e como interpretar o retorno, você escolhe “Apontamento de produção por tempo” e o CMS cria a Interface, a Entrega e os Erros de Negócio já configurados.

São três packs, todos incluídos no CMS — não há módulo adicional a contratar:

O mesmo assistente oferece a biblioteca de Transformadores ISA-95 / B2MML. Os packs de abertura de chamado não aparecem nele: quem os instala é a ativação da ferramenta em Help Desk.

Pré-requisito

O pack é instalado sobre uma Aplicação que já tenha uma Conexão Externa do tipo SAP RFC vinculada. Se a Aplicação não tiver, o botão de instalar nem aparece.

Antes de começar, portanto:

1. Cadastre a Conexão Externa SAP RFC e teste a conexão (ver SAP RFC / BAPI).
2. Cadastre a Aplicação que representa o sistema que vai conversar com o SAP (o MES, por exemplo), com Keep Alive do tipo SAP RFC apontando para essa conexão.

Instalando

Na tela Aplicações, na linha da Aplicação, clique no ícone de caixas. O assistente tem quatro passos.

1. Pack

Escolha entre PP, QM e PM. O topo da tela mostra o que já está instalado nessa Aplicação — útil para não reinstalar por engano.

2. Receitas

Cada receita é um cenário de negócio: uma Coleta ou uma Entrega, com tudo que ela precisa. Estão agrupadas por categoria e marcadas com a direção:

• Coleta — o SAP alimenta o seu sistema (ler ordem, ler características de inspeção).
• Entrega — o seu sistema escreve no SAP (apontar produção, gravar resultado, abrir notificação).

Três presets no topo:

3. Parâmetros

Os valores da sua planta, preenchidos uma vez e aplicados a todas as receitas escolhidas. Variam por pack, mas os mais comuns são:

4. Revisão

Nada é gravado antes deste passo. Você vê:

• Quantos objetos serão criados, atualizados ou estão customizados.
• A verificação de compatibilidade contra o seu SAP: para cada receita escolhida, o CMS pergunta ao SAP se a função existe e se os campos usados existem naquele release.
• A lista objeto a objeto, com o nome exato de cada Interface, Coleta, Entrega e Erro de Negócio.

O botão Instalar só fica disponível depois disso.

A verificação de compatibilidade

É o passo que evita o pior modo de falha: interfaces que parecem certas e falham só na primeira mensagem.

Como efeito colateral, a verificação preenche o cache de metadados: o popup “Parâmetros Função SAP” das telas de Coleta e Entrega passa a abrir instantâneo, mesmo sem o SAP acessível.

Depois de instalar

As Interfaces aparecem normalmente nas telas de Interfaces, Coletas e Entregas — não há nada de especial nelas. Podem ser editadas, desativadas ou excluídas como qualquer outra.

Uma Interface do pack é sempre de uma direção só. As de leitura levam o sufixo _C; quando o mesmo assunto tem os dois lados, a de escrita ganha _E — é o caso de ..._PM_ATIVO_C e ..._PM_ATIVO_E. As demais são de Entrega.

Isso não é organização estética: uma Entrega dentro de uma Interface de Coleta faria o agendador processá-la pelo caminho errado (ver Cadastros), e por isso o catálogo dos packs tem teste automático que recusa a combinação.

O que o seu sistema precisa fazer

Cada Entrega criada tem uma URL de recebimento no formato /{{Interface}}/{{Definição}}, e um contrato de campos com nomes de negócio. Exemplo do apontamento de produção por tempo:

{
  "ordem": "000060003285",
  "operacao": "0010",
  "quantidadeBoa": 480,
  "quantidadeRefugo": 12,
  "unidade": "ST",
  "apontamentoFinal": "X"
}

O pack traduz esses nomes para os campos do SAP (AUFNR, VORNR, YIELD, SCRAP…). Os campos obrigatórios são validados antes de a mensagem chegar ao SAP: faltando ordem, a mensagem é recusada na hora, com erro claro, em vez de virar uma falha de RFC.

Para as Coletas vale o inverso: as que têm parâmetro de entrada expõem uma URL que o seu sistema chama passando, por exemplo, o número da ordem, e recebe o detalhe pronto.

Erros de negócio já mapeados

Cada Entrega vem com os erros mais comuns daquele cenário traduzidos para uma frase que o operador entende, em vez do código do SAP:

Reinstalar e atualizar

O assistente pode ser executado quantas vezes for preciso na mesma Aplicação. O passo de revisão classifica cada objeto:

• A criar — não existe ainda.
• A atualizar — existe, foi criado por este pack e continua igual ao que o pack gravou.
• Customizado — existe, foi criado por este pack e foi alterado desde então.

Quando uma versão nova do CMS trouxer uma versão nova de um pack, a lista de packs instalados mostra “atualização disponível”.

Desinstalar

O botão de desinstalar fica ao lado de cada pack instalado, no primeiro passo do assistente. Ele não é um “desfazer” cego: remove o que o pack criou e que continua exatamente como ele deixou, e preserva o resto, dizendo por quê.

Se algo foi preservado, o pack continua listado como instalado — assim você pode desinstalar de novo depois de resolver o que ficou para trás.

Permissão

O assistente é controlado pela Ferramenta /applications/packs, separada de /applications:

• Incluir — instalar um pack.
• Excluir — desinstalar.

Toda instalação é registrada no log de auditoria com o pack, a versão, a Aplicação, as receitas escolhidas e os parâmetros informados.

O que o pack não faz

• Não cria a Aplicação nem a Conexão. Essas são suas, e o pack apenas as referencia.
• Não cobre campo Z nem BAPI customizada. O pack entrega a base; a adaptação ao que a sua empresa tem de específico é trabalho de projeto.
• Não adivinha a regra da sua planta. Que centro, que tipo de movimento, que tipo de notificação — isso é o que você informa no passo 3.