ESPECIFICAÇÃO FUNCIONAL

IDENTIFICAÇÃO DO PROJETO
Nome do Projeto Código
Projeto Conecta 20210525
Cliente Módulo / Processo
MRS PM
Gerente de Projetos Gerente de Serviços
Rodolfo Zampieri / Mario Falcheti Adriano Rosa

IDENTIFICAÇÃO DO DOCUMENTO
Autor
Felipe Tozzi
Versão Status Data Criação
1.0 Em Analise 22/07/2021

HISTÓRICO DE REVISÕES
//Versã Data Revisor Descrição
o
1.0 27/07/2021 Ricardo Rissi Adição de informações referente a integração
1.1 14/09/2021 Ricardo Rissi Inclusão de novos campos nas integrações
1.2 15/09/2021 Felipe Tozzi Inclusão grupo de autorização

FUNCIONALIDADES ATENDIDAS
CÓDIGO DO GAP FUNCIONALIDADE
MAN_ITF0047_001 ITF - AVISAR VISITA ABERTA PARA O SISLOG

Índice
 ESPECIFICAÇÃO FUNCIONAL

1. INTRODUÇÃO............................................................................................................................................................3
1.1. OBJETIVO...................................................................................................................................................................3
2. DESENVOLVIMENTO..............................................................................................................................................3

Página 2
 ESPECIFICAÇÃO FUNCIONAL

1. Introdução
O sistema SISLOG irá receber do S4H se há Visita (Revisão) ou Ordem de serviço com manutenção em
andamento, para impedir que um equipamento seja liberado no SISLOG para operação com a Revisão de
manutenção em aberto ou Ordem de Serviço liberada.

1.1. Objetivo
O S4H deverá informar ao Sislog sempre que um equipamento inicie ou finalize uma manutenção. Para
tal, quando a primeira ordem de serviço estiver em execução para um equipamento o S4H irá informar
que o equipamento está em manutenção (VisitaAberta = true). Da mesma forma, quando não houver
mais ordens de serviço em execução para o equipamento o S4H irá informar que o equipamento não está
mais em manutenção (VisitaAberta = false).

2. Desenvolvimento
Ao criar uma ordem de manutenção no S4, o sistema deverá enviar para o SISLOG o código da ordem de
manutenção, status e número de equipamento.
Para tal deverá ser utilizado a USER-EXIT WORKORDER_UPDATE utilizando método
REORG_STATUS_ACT_CHECK para verificar o status da ordem, serão enviadas as ordens com status
“ABER”.
Criar uma RFC chamando BAPI_ALM_ORDER_GET_DETAIL preenchendo campo NUMBER= numero da
ordem de manutenção;
Buscando os campos:
FUNCT_LOC – Local de instalação
EQUIPMENT – Equipamento
SYS_STATUS – Status da ordem

Página 3
 ESPECIFICAÇÃO FUNCIONAL

Página 4
 ESPECIFICAÇÃO FUNCIONAL

Quando status= ENCE o SAP deverá comunicar o SISLOG que a visita foi encerrada, porem podem existir
uma visita com mais de uma ordem de manutenção, o sistema deverá ser capaz de validar a ultima
ordem com Status= ENCE.

Chamar a RFC BAPI_ALM_ORDER_GET_DETAIL preenchendo o campo NUMBER= número da ordem de

manutenção;
Buscando os campos:
FUNCT_LOC – Local de instalação
EQUIPMENT – Equipamento
SYS_STATUS – Status da ordem

Página 5
 ESPECIFICAÇÃO FUNCIONAL

Para verificação da última ordem encerrada utilizar a USER-EXIT IWO10004 para verificação das datas de
encerramento.

Para o campo lista OS, acessar a função BAPI_ALM_ORDERHEAD_GET_LIST com EQUNR;

ListaOS= ORDERIDs

Campo dataVencimentoManutencao
Com resultado de ListaOS passar todos os ORDERID pela função STATUS_READ e buscar o ORDERID=
STAT= I0001 e STAT# I0045;
Com resultado acessar a função BAPI_ALM_ORDER_GET_DETAIL com ORDERID e buscar o valor no campo
START_DATE;

Página 6
 ESPECIFICAÇÃO FUNCIONAL

2.1. PI / API
Será disparado uma Interface assíncrona de informações de Visitas Abertas originados no SAP S4H
e enviados ao Sislog para cadastro do catálogo através de API REST.
Para o retorno do processamento, será disponibilizado um serviço de retorno de logs também em REST.

2.1.1. Restrições, URL’s e segurança

A API está na forma de REST com JSON utilizando protocolo HTTPS e validação da autenticação através de
token informado no cabeçalho da requisição.
Para obtenção do token há uma api específica a qual faz a geração e outra api, caso necessário, para
validação conforme abaixo:

API Gera Token

Método POST
DEV <host:port>/api/token/generate-token/v1
HOM <host:port>/api/token/generate-token/v1
PROD <host:port>/api/token/generate-token/v1

Página 7
 ESPECIFICAÇÃO FUNCIONAL

2.1.2.Usuário de acesso
Ambient Usuário
e
DEV U_WS_TCP_DESE
HOM U_WS_TCP_DESE
PROD U_WS_TCP_PROD

2.1.3. Envio ao Sislog

API Visita Aberta
Método POST
DEV <host:port>/api/manutencao/visita-aberta/v1
HOM <host:port>/api/manutencao/visita-aberta/v1
PROD <host:port>/api/manutencao/visita-aberta/v1

2.1.3.1. Exemplos de payload

Request:
{
[
{
"numeroEquipamento": "7294131",
"visitaAberta": true,
"numeroRevisao": "N032",
"listaOS": [
"OS0001",
"OS0002"
],
"dataVencimentoManutencao": "2022-08-11T11:00:00.000-03:00"
},
{
"numeroEquipamento": "7294132",
"visitaAberta": true,
"numeroRevisao": "N031",
"listaOS": [
"OS0001",
"OS0002"
],
"dataVencimentoManutencao": ""
},
{
"numeroEquipamento": "7294133",
"visitaAberta": false,
"numeroRevisao": "",
"listaOS": [
],
"dataVencimentoManutencao": "2022-08-11T11:00:00.000-03:00"
}
]
}
Response:
** HTTP code ** (simple acknowledge)

Página 8
 ESPECIFICAÇÃO FUNCIONAL

2.1.4.Retorno ao S4

API Retorno Visita Aberta

Método POST
DEV <host:port>/ RESTAdapter/api/manutencao/visita-aberta/v1
HOM <host:port>/ RESTAdapter/api/manutencao/visita-aberta/v1
PROD <host:port>/ RESTAdapter/api/manutencao/visita-aberta/v1
2.1.4.1. Exemplos de payload
Request:
{
[
{
"numeroEquipamento": "7294131",
"statusEnvio": "OK",
"mensagemErro": ""
},
{
"numeroEquipamento": "7294132",
"statusEnvio": "OK",
"mensagemErro": ""
},
{
"numeroEquipamento": "7294133",
"statusEnvio": "OK",
"mensagemErro": ""
}
]
}
Response:
** HTTP code ** (simple acknowledge)
2.1.5. Usuário de acesso
Usuário de autenticação para aquisição do token:
Ambient Usuário
e
DEV U_WS_TCP_DESE
HOM U_WS_TCP_DESE
PROD U_WS_TCP_PROD
Grupo de autorização para validação do acesso:
Ambient Grupo
e
DEV G_WS_M_VSTA_ABER_DESE
HOM G_WS_M_VSTA_ABER_DESE
PROD G_WS_M_VSTA_ABER_PROD

2.1.6. Tratamento de erros

Deve ser implementado tratamento de erro padrão conforme arquitetura proposta para integração
no Projeto Conecta SAP.

Página 9
 ESPECIFICAÇÃO FUNCIONAL

2.1.7. Regras de negócio/transformações

Não será feito nenhuma regra de negócio nem transformações na camada de integração, estas
ficando a cargo dos sistemas origem/destino envolvidos.

2.1.8. SLA’s fornecidos

Descrição Valor
Tempo máximo de resposta por requisição 5,0 segundos
Tempo médio de resposta por requisição 3,0 segundos
Número máximo de requisições simultâneas 20,0 requisições
Solicitações máximas por unidade de tempo 10,0 requisições por segundo
Regularidade de execução Sob demanda
Possui Picos de Processamento? Qual
N/A
dia/hora?
Executa em janela de processamento? Qual
N/A
período?
Pode ser modelado como processo batch? Não
Tipo de Operação 24 x 7
Disponibilidade do Serviço (% de uptime por
24 x 7
ano)
Disponibilidade (horário e de calendário) 99%
Tamanho médio de mensagem (Kbytes) ? Kbites
Cláusulas N/A
Validar a interface (request)? Sim
Validar o response? Sim
Número de equipamento: por demanda
Volumetria
(média)

Página 10