Árvore de páginas

Documento de API

Produto:

Datasul

Ocorrência:

Documentação de API

Nome Físicosfc/sfapi010

 

Objetivo

Efetuar o Reporte (Apontamento) das Paradas do Centro de Trabalho.

 

Principais Características

Esta API pode ser utilizada de duas formas diferentes:

  • A primeira forma (forma padrão) é a execução direta (“não-persistente”) da API, passando-se por parâmetro - através de uma tabela temporária de comunicação da API - os dados a reportar. Neste caso, algumas opções referentes à integração com Manutenção Industrial não estão disponíveis.
  • A segunda forma de utilização da API é a execução “persistente”. Neste caso, estarão disponíveis algumas opções adicionais referentes à integração com Manutenção Industrial. Observação: Esta forma de execução da API está disponível para os clientes que possuem o EMS a partir da versão 2.07, e também para os clientes com versões inferiores do produto (a partir da versão 2.04) que possuírem a função “Automação” implantada. Como as funções adicionais dizem respeito à integração com Manutenção Industrial, é necessário também que o cliente possua este módulo para utilizar as opções adicionais disponibilizadas.

 

Funcionamento

 

  • Execução Direta

A sintaxe para a execução na modalidade Direta (“não-persistente”) da API é a seguinte:

run sfc/sfapi009.p (input <versao-integracao>,

                    input table tt-import-rep-parada,

                    output table tt-erro).

Parâmetros

Descrição

<versao-integracao>

Para os clientes que possuem o EMS 2.04, deve ser informado o valor 204. Para os clientes com EMS 2.05 ou superior, deve ser informado o valor 205.

tt-import-rep-parada

Temp-table com os dados a reportar. Pode ser passada para a API contendo um ou mais registros, sendo que cada registro representa uma Parada a reportar. Mais detalhes sobre a definição da temp-table, obrigatoriedade de campos, etc., estão descritos adiante.

tt-erro

Temp-table de retorno de erros gerados na execução.

 

  • Execução Persistente

A sintaxe para a execução na modalidade Persistente da API é a seguinte:

run sfc/sfapi009.p persistent set h-handle (input <versao-integracao>,

                                            input table tt-import-rep-parada,

                                            output table tt-erro).

Parâmetros

Descrição

<versao-integracao>

Para os clientes que possuem o EMS 2.04, deve ser informado o valor 204. Para os clientes com EMS 2.05 ou superior, deve ser informado o valor 205.

tt-import-rep-parada

Deverá ser passada como parâmetro vazia na inicialização.

tt-erro

Temp-table de retorno de erros gerados na execução.

Os parâmetros de entrada e saída são idênticos nas duas formas de execução (persistente e não-persistente). A diferença básica é que, na execução persistente, a efetivação do Reporte de Parada se dará mediante a execução do método pi-inicializa, o qual permite informar alguns parâmetros adicionais referentes à integração da Parada do Chão de Fábrica com o módulo de Manutenção Industrial. O método pi-inicializa é explicado adiante.

Importante: Na execução persistente, após a utilização dos métodos da API, é necessário e obrigatório efetuar a execução do método finalizaAPI, que é descrito mais adiante.

 

  • Características Gerais

A API pode executar quatro diferentes tipos de transações básicas relacionadas ao Reporte de Paradas:

-                                  Inclusão de reporte de parada;

-                      Iniciação de reporte de parada;

-                      Eliminação de reporte de parada;

-                      Finalização de reporte de parada já iniciado.

Quando é feita a inclusão de reporte de parada, a API necessita das seguintes informações:

-                      Tipo do reporte (deve ser igual a 1);

-                      Código do Centro de Trabalho;

-                      Código da Parada;

-                      Data de início da parada;

-                      Hora de início da parada;

-                      Data fim da parada;

-                      Hora fim da parada;

-                      Código da equipe, caso o centro de trabalho reporte pela equipe;

-                      Código do operador, caso o centro de trabalho reporte pelo operador.

As informações referentes às Datas e Horas da parada podem ser omitidas. Neste caso, a API irá completá-las automaticamente, da seguinte forma: se for omitida a data de início da parada, a API irá atribuir a ela a data de hoje e a hora atual. Caso não seja informada a data final, a API irá calculá-la baseando-se na data e hora de início, considerando a duração fixa de 1 (uma) hora.

 

Quando é feita a inicialização de uma parada no centro de trabalho a API necessita das seguintes informações:

-                      Tipo do reporte (deve ser igual a 2);

-                      Código do Centro de Trabalho;

-                      Código da Parada;

-                      Data de início da parada;

-                      Hora de início da parada;

-                      Código da equipe, caso o centro de trabalho reporte pela equipe;

-                      Código do operador, caso o centro de trabalho reporte pelo operador.

Da mesma forma que na inclusão da parada, é possível omitir a data e hora de início. Neste caso, a API irá atribuir a data de hoje e a hora atual.

 

Quando for feita a finalização de uma parada no centro de trabalho, a API irá procurar a primeiro reporte de parada iniciado do centro de trabalho e então irá finalizá-lo. Para isso a API necessita das seguintes informações:

-                      Tipo do reporte (deve ser igual a 3);

-                      Código do Centro de Trabalho;

-                      Data de término parada

-                      Hora de término da parada

Caso não seja informada a data e a hora de término do reporte, o programa irá calculá-la baseado na data e hora inicial considerando a duração fixa de 1 (uma) hora.

 

Quando é feita a eliminação de um reporte de parada para o centro de trabalho, a API necessita das seguintes informações:

-           Tipo de reporte (deve ser igual a 4);

-           Código do Centro de Trabalho;

-           Código da parada;

-           Data de início da parada;

-           Hora de inicio da parada.

Caso não seja informada a data e hora de início da parada, a API irá eliminar a última parada do Centro de Trabalho informado.

 

Adicionalmente, caso o usuário possua a função “Automação” implantada, a API disponibiliza a função de Re-análise do Motivo de Parada. Esta função está disponível através do método pi-re-analise-motivo-parada, que é explicado adiante.

 

Tabelas Temporárias

Para comunicação com os métodos da API, as seguintes temp-tables são utilizadas:

Tabela Temporária

Descrição

Entrada/Saída

tt-import-rep-parada

Utilizada para a entrada dos dados a reportar. Cada registro passado por esta temp-table corresponde a uma transação que será efetuada, sendo que podem ser passados um ou mais registros. Sua definição está na include sfc/sfapi010.i

Entrada

Atributo

Tipo

Descrição

tipo-rep

integer

Tipo de transação: 1– Incluir; 2 – Iniciar; 3 – Finalizar; 4 – Eliminar.

cod-ctrab

character

Código do Centro de Trabalho

cod-parada

character

Código do Motivo de Parada

num-om-progda

integer

Número da Parada Programada, deve ser informado caso o reporte de parada que está sendo efetuado seja a concretização de uma parada programada previamente.

dat-inic-parada

date

Data de Início da Parada

hr-inic-parada

decimal

Hora de Início da Parada, em segundos.

dat-fim-parada

date

Data de Término da Parada

hr-fim-parada

decimal

Hora de Término da Parada, em segundos.

val-refer-inic-parada

decimal

Valor de referência do início da parada. Campo calculado internamente, não deve ser informado.

val-refer-fim-parada

decimal

Valor de referência do término da parada. Campo calculado internamente, não deve ser informado.

cod-equipe

character

Código da Equipe. Deve ser informado quando o Centro de Trabalho estiver parametrizado para reportar equipe

cod-operador

character

Código do Operador. Deve ser informado quando o Centro de Trabalho estiver parametrizado para reportar operador

linha

integer

Número que identifica o registro na temp-table. Utilizado para atribuir os erros gerados na tt-erro aos respectivos Reportes. Útil para quando se usa a API em um programa de importação de Reportes via arquivo de texto, neste caso a linha corresponderia à linha do registro no texto. (Informação não obrigatória)

erro

logical

Campo utilizado internamente pela API

    

Tabela Temporária

Descrição

Entrada/Saída

tt-erro

Utilizada como saída padrão dos erros gerados na execução da API. Sua definição está na include cdp/cd0666.i

Saída

Atributo

Tipo

Descrição

i-sequen

integer

Seqüência do erro

cd-erro

integer

Número do erro

mensagem

character

Texto da mensagem de erro

    

Tabela Temporária

Descrição

Entrada/Saída

rowErrors

Utilizada como saída alternativa dos erros gerados na execução da API. Sua definição encontra-se na include method/dbotterr.i. Obs.: Somente pode ser utilizada a rowErrors para saída dos erros da API quando fazendo a execução no modo persistente, e mediante o ajuste de um parâmetro específico. Mais detalhes estão descritos no detalhamento do método setaGeraRowErrors.

Saída

Atributo

Tipo

Descrição

ErrorSequence

integer

Seqüência do erro

ErrorNumber

integer

Número do erro

ErrorDescription

char

Descrição do erro

ErrorParameters

char

Parâmetros passados para criar mensagem

ErrorType

char

Tipo do erro. WARNING: Aviso; ERROR: Erro

ErrorHelp

char

Texto de ajuda do erro

ErrorSubType

char

Sub Tipo da mensagem de erro

 

Métodos

Para os clientes que possuem o EMS a partir da versão 2.07 (ou versões inferiores (a partir da versão 2.04), com a função “Automação” implantada), é possível a execução da API de Reporte de Paradas na modalidade “Persistente”, disponibilizando, assim, alguns parâmetros adicionais de integração com Manutenção Industrial.

Desta forma, seguem as instruções para utilização dos métodos disponíveis.

pi-inicializa

Requisito

Nenhum

Sintaxe

run pi-inicializa in h-handle (input  <logical-on-line>,

                               input  <logical-usa-param>,

                               input  <logical-emite-ss>,

                               input  <logical-envia-email>,

                               input  <logical-cria-pend>,

                               input  <integer-nr-ord-produ>,

                               input  table tt-import-rep-parada,

                               output table tt-erro).

Descrição

Efetua a transação (inclusão, exclusão, início ou término) de um ou mais reportes de parada. Obs.: Os cinco primeiros parâmetros da API somente têm efeito caso o cliente possua o módulo de Manutenção Industrial implantado.

 

Parâmetros

Descrição

 

<logical-on-line>

Quando marcado como Yes, este parâmetro indica que a API poderá chamar, conforme outros parâmetros explicados a seguir, telas para a geração de Solicitação de Serviço ou envio de E-mail para o planejador.

 

<logical-usa-param>

Indica, quando marcado igual Yes, que irá utilizar os parâmetros <logical-envia-email> e <logical-emite-ss> para definir se irá ou não enviar e-mail para o planejador e emitir SS na Inclusão de um Reporte de Parada. Caso o parâmetro seja igual No, então serão consideradas os parâmetros de envio de e-mail e emissão de SS presentes no motivo de Parada informado.

 

<logical-emite-ss>

Indica que, na inclusão ou início de um Reporte de Parada, a API irá emitir uma Solicitação de Serviço no módulo de Manutenção Industrial. Este parâmetro somente terá efeito caso o parâmetro <logical-usa-param> esteja marcado igual à Yes. Caso contrário, será utilizado o parâmetro de emissão de SS presente no motivo de Parada.

 

<logical-envia-email>

Indica que, na inclusão ou início de um Reporte de Parada, a API irá enviar um e-mail para o planejador do Equipamento, cadastrado na Manutenção Industrial. Este parâmetro somente terá efeito caso o parâmetro <logical-usa-param> esteja marcado igual à Yes. Caso contrário, será utilizado o parâmetro de emissão de e-mail presente no motivo de Parada.

 

<logical-cria-pend>

Indica que, na ocorrência de erros na execução da API, será também gerada pendência de Importação. Observação: este parâmetro somente é utilizado para clientes que possuem o EMS na versão 2.05 ou superior.

 

<integer-nr-ord-produ>

Recebe o número da Ordem de Manutenção que deu origem à Parada que está sendo Incluída, Iniciada ou Finalizada. Caso não haja ordem de manutenção, deve ser passado o valor 0 (zero) neste parâmetro.

 

tt-import-rep-parada

Recebe a temp-table populada com os registros relativos aos reportes de parada que serão efetivados. Quando executando persistente e on-line, é indicado enviar apenas um registro por vez, já que poderão ser apresentadas ao usuário telas para manipular as SSs e e-mails enviados em função da parada. É importante observar também que, caso seja informada uma ordem de manutenção no parâmetro <integer-nr-ord-produ>, a mesma será atribuída a todos os registros de Parada, caso haja mais de um na temp-table.

 

tt-erro

Temp-table que retorna eventuais erros ocorridos na gravação das informações.

Retorno

Não há.

setaGeraRowErrors

Requisito

Nenhum

Sintaxe

run setaGeraRowErrors in h-handle.

Descrição

Quando executada antes da chamada de qualquer outro método, indica que a API deverá gerar os erros na temp-table rowErrors, em paralelo à temp-table de erros padrão (tt-erro).

Esta opção é útil quando se está chamando a API a partir de uma interface escrita com thinTemplates, a qual tem como temp-table padrão de erros a rowErrors.

Retorno

Não há.

retornaRowErrors

Requisito

Ter executado outro método que possa ter gerado erros em sua execução. Ter executado o método setaGeraRowErrors no início da execução da API.

Sintaxe

run retornaRowErrors in h-handle (output table rowErrors).

Descrição

Retorna a temp-table rowErrors populada com os erros gerados na execução.

 

Parâmetros

Descrição

 

rowErrors

Retorna esta temp-table populada com os erros.

Retorno

Não há.

pi-re-analise-parada

Requisito

Possuir uma parada Iniciada ou Incluída (Iniciada e finalizada) que se necessite reanalisar.

Sintaxe

run pi-re-analise-parada in h-handle(input <rowid-rep-parada-ctrab>,

                                     input <character-cod-parada>,

                                     input <date-data-fim-prevista>,

                                     input <integer-hra-fim-prevista>,

                                     input <integer-nr-ord-produ>).

Descrição

A função Re-análise de Parada tem como objetivo permitir que uma parada tenha seu motivo e ordem de manutenção modificados após sua Inclusão ou Início. No caso de paradas Iniciadas, também é possível, através desta função, a alteração da data/hora prevista de término. Essa reclassificação da parada impacta nas estatísticas de parada e no processo de alocação de atividades do módulo Chão de Fábrica.

 

Parâmetros

Descrição

 

<rowid-rep-parada-ctrab>

Rowid do registro da tabela rep-parada-ctrab cuja parada se deseja Reanalisar.

 

<character-cod-parada>

Código do novo motivo de parada que se deseja informar.

 

<date-data-fim-prevista>

Indica a nova data de fim prevista para a parada. Somente será considerado este parâmetro quando se tratar de Parada Iniciada (não finalizada).

 

<integer-hra-fim-prevista>

Indica a nova hora de fim prevista para a parada, devendo ser informadoem segundos. Somenteserá considerado este parâmetro quando se tratar de Parada Iniciada (não finalizada).

 

<integer-nr-ord-produ>

Permite informar a Ordem de Manutenção que deu origem a Parada, ou modificar uma ordem informada anteriormente. Caso não haja ordem de manutenção, deve ser passado o valor 0 (zero) neste parâmetro.

Retorno

Quando ocorrem erros durante as validações das informações, a API retorna o valor NOK. Por este motivo, o programa chamador deverá ter tratamento para, após a execução deste método, retornar os erros caso haja return-value = “NOK” através do método retornaRowErrors

finalizaAPI

Requisito

Nenhum

Sintaxe

run finalizaAPI in h-handle.

Descrição

Método que efetua a finalização da API, eliminando da memória todos os componentes por ela utilizada. Sua execução é obrigatória, devendo, ser executado após a utilização da API.

Retorno

Não há.