Guia de Integração SAP PI - energia cria energia - Galp · plataforma TIBCO, no documento PIARQD018 – Códigos de Erro Comum. Uma vez testadas, as interfaces/serviços deverão

Guia de Integração – SAP PI

DSI – Arquitetura Aplicacional COPYRIGHT 2010 Galp Energia, SA 1 de 19


Versão 3.2 / Maio-2013

DSI-Arquitetura Aplicacional

Guia de Integração SAP PI


Controlo de Versões

V1 Criação de documento 28-04-2011 Rui Miguel (DSI)

V2Actualização do PIGENT120 - Communication

Channels01-03-2012 Rui Ventura (DSI)

V3 Alteração da forma de obtenção od PIARQT012 29-08-2012 Rui Ventura (DSI)

V3.1Correção do português com o novo acordo

ortográfico11-01-2013 Rui Ventura (DSI)

V3.2 Alteração da designação do PIGENT005 08-05-2013 Rui Ventura (DSI)



Direitos Autorais

Documento inédito com todos os direitos reservados. A inscrição “COPYRIGHT © 2010 Galp Energia, SA”

foi atribuída a este documento para, em caso de publicação acidental, proteger os direitos da Galp Energia

SA. Nenhuma parte deste documento pode ser reproduzida sob qualquer forma, inclusive fotocópia ou

transmissão eletrónica para qualquer computador, sem o prévio consentimento escrito da Galp Energia SA.

Confidencialidade

As informações contidas neste documento são confidenciais e da propriedade exclusiva da Galp Energia

SA, não podendo ser utilizadas, divulgadas, ou cedidas a terceiras partes, sem o prévio consentimento

escrito da Galp Energia SA.



Índice

1. INTRODUÇÃO .......................................................................................................................................5

1.1. OBJETIVOS DO DOCUMENTO ..............................................................................................................5 1.2. DOCUMENTOS DE SUPORTE ...............................................................................................................5

2. CICLO DE VIDA DE PROJETO ............................................................................................................7

2.1. DEFINIÇÃO CONCEPTUAL ...................................................................................................................7 2.2. DESENHO DETALHADO .......................................................................................................................8 2.3. CONSTRUÇÃO DA SOLUÇÃO ...............................................................................................................8 2.4. TESTES E ACEITAÇÃO ........................................................................................................................8 2.5. PASSAGEM A PRODUÇÃO ...................................................................................................................9 2.6. EXPLORAÇÃO ....................................................................................................................................9

3. ARQUITECTURA TÉCNICA DOS AMBIENTES ............................................................................... 10

3.1. DESENVOLVIMENTO ........................................................................................................................ 10 3.2. QUALIDADE .................................................................................................................................... 11 3.3. PRODUÇÃO .................................................................................................................................... 11

4. NORMAS, STANDARDS E MELHORES PRÁTICAS ....................................................................... 12

4.1. ARQUITECTURA GLOBAL ................................................................................................................. 12 4.2. NORMAS ........................................................................................................................................ 12 4.3. STANDARDS ................................................................................................................................... 13 4.4. DEPLOYMENT ................................................................................................................................. 13

5. DOCUMENTOS DO PROJETO .......................................................................................................... 14

5.1. PIARQT011 – CHECKLIST DE PROJETO .......................................................................................... 15 5.2. PIARQT012 – MÉTRICAS DE PROJETO ........................................................................................... 15 5.3. PIGENT004 – ANÁLISE DE GAP’S ................................................................................................... 16 5.4. PIGENT005 – INVENTÁRIO DE REQUISITOS .................................................................................... 16 5.5. PIGENT010 – DEFINIÇÃO CONCEPTUAL DA SOLUÇÃO ..................................................................... 16 5.6. PIGENT011 – DEFINIÇÃO DESENHO FUNCIONAL DA SOLUÇÃO ........................................................ 17 5.7. PIGENT012 – DEFINIÇÃO DESENHO TÉCNICO DA SOLUÇÃO ............................................................ 17 5.8. PIGENT113 –DEPLOYMENT ........................................................................................................... 17 5.9. PIGENT115 – INVENTÁRIO DE ERROS E AVISOS ............................................................................. 18 5.10. PIGENT016 – MAPEAMENTO DE DADOS...................................................................................... 18 5.11. PIGENT119 – ESPECIFICAÇÃO DO SERVIÇO ............................................................................... 18 5.12. PIGENT120 – COMMUNICATION CHANNELS ................................................................................ 18 5.13. PIGENT022 – CHECKLIST DEPLOY ............................................................................................. 18 5.14. PIQAST001 – PLANO DE ABORDAGEM AO TESTE ........................................................................ 18 5.15. PIQAST003 – PLANO DE TESTES ............................................................................................... 19 5.16. CHANGE ORDER ......................................................................................................................... 19



1. INTRODUÇÃO

1.1. OBJETIVOS DO DOCUMENTO

Este documento tem por objetivo realizar o enquadramento às várias áreas interessadas que diretas ou

indiretamente estejam envolvidas em projetos de SI em que exista componente de integração via SAP PI.

Nesse sentido o documento aborda as seguintes vertentes:

Ciclo de Vida de Projetos

Apresentação de uma visão geral das várias fases que compõem um projeto de SI na Galp Energia.

Ambiente de trabalho

Identificação dos ambientes utilizados e respetivas responsabilidades.

Modelo de Referência da Galp Energia – Integração de dados

Especificação do modelo conceptual de integração definido.

Normas, Standards e Melhores Práticas

Identificação das normas, standards e melhores práticas a seguir durante o Ciclo de Vida de Projetos

Documentação do Projeto

Apresentados os documentos que deverão ser entregues em cada fase do projeto

Só com o cumprimento das regras definidas é que projetos ou ações de manutenção poderão ser aceites

no que respeita a passagem das respetivas capacidades pelos vários ambientes (desenvolvimento,

qualidade e produção).

1.2. DOCUMENTOS DE SUPORTE

Os documentos associados são os seguintes (a validar):

Logging;

PIARQD018 – Códigos de Erros Comuns

PIARQD103 – Normas Funcionais e Técnicas de Integração

PIQASD001 – Metodologia de Testes;

PIQASD002 – Gestão da Configuração

PIGENT004 – Análise de Gap’s;

PIGENT005 – Requisitos Técnicos;



PIGENT010 – Desenho Conceptual da Solução;

PIGENT011 – Desenho Funcional da Solução;

PIGENT012 – Definição Desenho Técnico da Solução;

PIGENT113 – Galp Deployment;

PIGENT115 – Inventário de Erros e Avisos;

PIGENT016 – Mapeamento de Dados;

PIQAST001 – Plano de Abordagem ao Teste;

PIQAST003 – Plano de Testes;

PIARQD018 – Códigos de Erros Comuns

PIARQD020_A - Cockpit de Integração – Manual de Utilizador

PIARQD021 – Galp – Regras de Promoção entre Ambientes

PIARQD022 – Galp – Regras de utilização do TFS

PIARQD023 – Galp – Regras de Roteamento

PIARQD024 – Galp – Regras Cálculo de consumo espaço EH

PIARQT011 – Checklist de Projeto

PIARQT012 – Métricas de Projeto

PIGENT120 – Communication Channels



2. CICLO DE VIDA DE PROJETO

Apesar de este documento estar relacionado com Projetos de SI, conforme definido atrás, em muitos

casos os SI são apenas uma das componentes da solução global. As fases apresentadas neste documento

têm exclusivamente a haver com a realização do Projeto (estão fora do âmbito as fases que vão desde a

“Definição de Requisitos” até ao “Procurement”) até à passagem a produção e acompanhamento inicial.

As fases para realização de um projeto de SI na Galp Energia são as apresentadas na figura seguinte:

2.1. DEFINIÇÃO CONCEPTUAL

Esta fase consiste essencialmente em definir, de forma conceptual, qual será a situação após a

realização do projeto, e quais as necessidades de intervenção, nas seguintes vertentes:

Recursos Humanos;

Competências;

Estrutura Organizacional;

Processos de Negócio;

Métricas (Modelo de avaliação / Gestão de Performance);

Arquitectura Tecnológica;

Instalações Físicas;

Definir plano de testes de aceitação dos utilizadores (através da aplicação da metodologia

selecionada pela Galp Energia, o V-Model);

Plano de Comunicação.



2.2. DESENHO DETALHADO

A Fase de Desenho Detalhado consiste em:

Definir a nova estrutura organizacional e os novos perfis de funções;

Definir as novas competências e identificar as necessidades de formação para o seu

desenvolvimento;

Definir detalhadamente os novos processos de negócio;

Definir o novo modelo de avaliação de performance;

Definir e selecionar, se necessário, a infraestrutura tecnológica necessária para os ambientes de

desenvolvimento, teste e exploração;

Identificação dos objetos/serviços a implementar/reutilizar e respetiva distribuição física

(Arquitectura);

Desenhar a aplicação;

Complementar o plano de testes com os testes técnicos, de integração e de carga;

Desenhar o layout das instalações físicas que é necessário criar ou transformar;

Desenhar o plano de comunicação interno e externo.

2.3. CONSTRUÇÃO DA SOLUÇÃO

Nesta fase são implementados os diversos componentes da solução: os novos processos e os

procedimentos associados, a nova organização, as arquiteturas de desenvolvimento, teste e produção, os

módulos da aplicação, as parametrizações, os interfaces, a base de dados, os módulos de conversão, os

materiais para as ações de formação, as instalações físicas e os materiais de comunicação. São também

realizados os testes unitários dos módulos desenvolvidos à medida.

Todo este conjunto de ações deve ser efetuado no denominado “Ambiente de Desenvolvimento”.

2.4. TESTES E ACEITAÇÃO

Na fase de testes e aceitação são realizados os testes de integração entre os módulos desenvolvidos,

dos interfaces com outras aplicações e o teste global da solução por forma a validar se a mesma

corresponde aos requisitos (funcionais, técnicos, performance e segurança) anteriormente identificados.

Os testes e Aceitação nesta fase deverão ser executados nos ambientes de qualidade de forma a

simular o mais possível o ambiente real em que a solução vai ser colocada.



2.5. PASSAGEM A PRODUÇÃO

A Passagem a Produção inclui as tarefas preparatórias e a própria Passagem a Produção.

Nesta fase deverá ser definido e executado o plano detalhado das catividades (quer de SI ou não)

necessárias para que a solução desenvolvida possa entrar em funcionamento pleno.

2.6. EXPLORAÇÃO

Embora a fase de exploração seja da competência das entidades responsáveis pelo on-going da

solução, a mesma deverá ser inicialmente efetuada com o apoio das entidades que estiveram envolvidas

nas fases anteriores no sentido de garantir a passagem do know-how.

Este apoio deverá ocorrer normalmente durante o período designado como “Apoio pós-entrada em

Exploração”, e é por norma, da responsabilidade da equipa do fornecedor da implementação. Neste

período, é fundamental ainda existir a passagem de conhecimento necessário e suficiente, de forma a que a

aplicação possa a partir de uma determinada data, passar a estar sobre a responsabilidade do fornecedor

de Manutenção Aplicacional.



3. ARQUITECTURA TÉCNICA DOS AMBIENTES

Os ambientes disponíveis no âmbito da componente de integração SAP PI são os seguintes:

Desenvolvimento;

Qualidade;

Produção.

3.1. DESENVOLVIMENTO

Ao nível do ambiente de desenvolvimento, existem duas máquinas sendo que:

X04 – Projeto que são realizados por outras consultoras;

X05 – Projetos que são realizados por equipas da HP. É também nesta máquina que são

efetuadas manutenções evolutivas e corretivas (validar)?

No início do projeto serão atribuídos os acessos necessários sendo da responsabilidade do projeto

identificar as respetivas necessidades.

Qualquer software, patch, adicional ao disponibilizado, que seja necessário ao projeto, deverá ser

identificado e solicitado à Galp Energia com a devida antecedência, de forma a possibilitar a avaliação do

pedido. A instalação do mesmo é da responsabilidade da Galp Energia.

Necessidades de alterações às parametrizações base do software deverão ser solicitadas à Galp

Energia que avaliará os impactos da solicitação e respetiva alteração.

Todas as sources e bibliotecas serão disponibilizadas via ferramenta TFS (Team Foundation Server) da

Microsoft. Para maiores detalhes sobre a sua utilização ver documento TFS.ppt disponível no site

“Programa de Integração”, na pasta “Guia de Integração”. (Ainda não ativo)

Quando exista a necessidade de desenvolver um conjunto de interface entre duas aplicações, e estas se

encontrem sob a responsabilidade de equipas de implementação distintas, cada equipa deverá desenvolver

internamente cada um dos processos e proceder ao teste end-to-end ao nível do ambiente de qualidade

(testes integrados e de carga).

Caso seja considerado que os interfaces/serviços a implementar sobre a plataforma devem efectuar o

respetivo logging para o sistema de logging transversal, os códigos de erro retornados por cada

serviço/interface deverão obedecer à lista de códigos de erro comuns definida pela GALP Energia. A

necessidade de novos códigos deverá ser acordada previamente com a equipe de Arquitectura de

integração. Os códigos que podem ser usados encontram-se disponíveis da documentação específica da

plataforma TIBCO, no documento PIARQD018 – Códigos de Erro Comum.

Uma vez testadas, as interfaces/serviços deverão ficar disponíveis para todas as equipas, passando a

constar da lista de interfaces/serviços existentes para (re) utilização.



3.2. QUALIDADE

O ambiente de qualidade disponibilizado tenta refletir, tanto quanto possível, a Arquitectura técnica e

respetiva infraestrutura de servidores de produção.

A máquina associada a este ambiente é a máquina X03.

É o primeiro ambiente onde as questões de cariz de infraestrutura (rede, clusters, switches,

balanceamento de carga, etc.) se encontram pela primeira vez disponíveis às equipas de desenvolvimento,

permitindo a estas conduzirem ciclos e condições de teste específicos (por exemplo testes de performance

aplicacional ou testes de exceção/falha de um dos servidores em balanceamento de carga) que no

ambiente de desenvolvimento tipicamente não são controladas.

Adicionalmente, é o ambiente onde as soluções desenvolvidas são testadas de forma integrada com

uma garantia mínima de controlo sobre as alterações a componentes que, tipicamente, num ambiente de

desenvolvimento, se encontram sujeitos a um maior número de atualizações.

A colocação das componentes desenvolvidas no âmbito do projeto neste ambiente é da

responsabilidade da equipa de projeto, com a supervisão da equipa de manutenção.

O acompanhamento por parte da equipa de manutenção, tem como objetivo validar o plano de

instalação fornecido, previamente, pela equipa de projeto.

Após a instalação do “projeto” neste ambiente, a garantia de funcionamento (levantar e baixar

serviços/interfaces) dos serviços/interfaces é da responsabilidade da equipa de manutenção com o apoio da

equipa de projeto.

3.3. PRODUÇÃO

A máquina associada a este ambiente é a máquina X02.

A colocação das componentes desenvolvidas no âmbito do projeto neste ambiente é da

responsabilidade da equipa de manutenção com o apoio da equipa de projeto.

O acompanhamento por parte da equipa de projeto, tem como objetivo garantir a correta instalação das

componentes desenvolvidas e assegurar a passagem do know-how para a equipa de manutenção.

Após o período de transição, a equipa de manutenção será, ao nível aplicacional, a entidade responsável

pela operacionalidade das componentes que foram desenvolvidas no âmbito do projeto.

No entanto, qualquer situação em que se verifique a existência de erros decorrentes de uma falha de

implementação e caso esteja a decorrer o período de garantia, a responsabilidade pela correção do erro é

da responsabilidade da equipa de projeto.



4. NORMAS, STANDARDS E MELHORES PRÁTICAS

No sentido de garantir a eficiência e a rentabilização dos recursos utilizados estão definidas normas,

standards e melhores práticas a serem aplicadas às implementações no SAP PI.

4.1. ARQUITECTURA GLOBAL

<……..> - SAP PI Global Architecture (Documento em Elaboração)

Este documento contém a Arquitectura base da Galp assim como todas as regras que

deverão ser seguidas, tendo como objetivo normalizar o desenvolvimento e permitir uma maior

reutilização das várias componentes.

<……..> - SAP PI Monitorization (Documento em Elaboração)

Este documento contém a Arquitectura de monitorização a usar.

4.2. NORMAS

PIARQD103 - SAP PI Normas Funcionais e Técnicas de Integração (Documento em Elaboração)

Este documento define um conjunto de normas funcionais e técnicas que pretendem

assegurar uma correta implementação das funcionalidades sobre a plataforma SAP PI.

PIQASD001 – Metodologia de Testes

Em face da importância que a componente de testes tem para o sucesso dos projetos, no

sentido de reduzir os riscos de inconformidade da solução desenvolvido face aos requisitos do

negócio, foi definida uma metodologia de abordagem ao teste, baseado no modelo V-Model.

O documento apresenta o modelo e a forma como as diferentes fases de teste se encontram

associadas às diferentes catividades do ciclo de vida de desenvolvimento de aplicações.

Para cada fase de teste são identificados os aspetos que deverão ser validados e

monitorizados, em que ambientes é que os testes devem ser efetuados, em que fases devem

ser efetuados os planeamentos dos testes e quando é que estes devem ser executados.

PIQASD002 - Gestão da Configuração (Documento em Elaboração)

Estabelece as regras a serem seguidas no que respeita à gestão de configuração de

Software aplicacional, no âmbito da equipa de qualidade. No entanto, estas regras deverão ser

do conhecimento da equipa de projeto no sentido de facilitar o trabalho entre todos os

intervenientes.

< ….> - Error Handling

Estabelece as regras a serem seguidas no que respeita ao registo e tratamento de erros, de

forma transversal aos vários sistemas, bem como as guidelines para a correta utilização deste

serviço. Este documento é aplicável sempre que seja definido que o serviço/interface a

implementar deverá efetuar logging para o logging transversal

PIARQD018 – Códigos de Erro Comuns



Identifica os códigos de erros que podem ser usados e respetivo contexto

<…> – Galp – Regras de Promoção entre Ambientes (Documento em Elaboração)

Explica o processo de promoção dos objetos de ambientes.

<…> – Galp – Regras de utilização do TFS (Documento em Elaboração)

Explica a estrutura definida ao nível do TFS e como o mesmo é utilizado.

<…> – Regras de Filtragem (Documento em Elaboração)

Define as regras de utilização das regras de roteamento e como é que as mesmas devem ser

implementadas.

<…> – Regras Cálculo consumo de espaço (Documento em Elaboração)

Define um método para o cálculo do espaço adicional na plataforma.

<…> – Cockpit de Monitorização SAP PI (Documento em Elaboração)

Nesta pasta estão disponíveis os documentos que explicam:

o Xxxxx

o Yyyy

o Zzzz

4.3. STANDARDS

<…..> (Documento em Elaboração)

4.4. DEPLOYMENT

<……..> - Deployment Rules (Documento em Elaboração)

Contém as regras, variáveis e nomenclaturas que deverão ser seguidas em todos os

deployments no SAP PI.


DSI – Arqutiectura Aplicacional COPYRIGHT 2010 Galp Energia, SA 14 de 19

5. DOCUMENTOS DO PROJETO

De acordo com as fases definidas para a realização de um projeto de SI na Galp Energia apresenta-se de seguida a documentação que deverá ser

elaborada em cada fase:

Fase Documento

Definição Conceptual

Desenho Detalhado

Construção da Solução

Teste e Aceitação

Passagem a Produção Exploração

PIARQT011 – Checklist Projecto C A A A

PIGENT004 - Análise de Gap's C A A

PIGENT005 - Requisitos Técnicos C/A A A A

PIGENT010 - Definição Conceptual da Solução C A

PIGENT011- Definição Desenho Funcional da Solução C A A A

PIGENT012 - Definição Desenho Técnico da Solução C A A

PIGENT119 – Especificação de Serviço/Interface C A

PIGENT120 – Communication Channels C A A A A

PIGENT113 - Deployment C A A

PIGENT022 - Checklist Deploy C A A

PIGENT115 - Inventário de Erros_Avisos_Monitorização A A A

PIGENT016 - Mapeamento de dados - Projeto C A

PIQAST001 - Plano de abordagem ao teste C A A A

PIQAST003 - Plano de testes C A A A

PIARQT012 – Métricas de Projeto C A A A

Change Order C A A A

(C)riar; (A)ctualizar.

De notar que a entrega desta documentação, por parte da Equipa de Projeto, é fundamental para se assegurar a total aceitação do

sistema por parte do fornecedor de manutenção aplicacional, e que servirá de base ao bom cumprimento das suas funções


PROPRIETÁRIO E CONFIDENCIAL PÁG. 15 DE 19

5.1. PIARQT011 – CHECKLIST DE PROJETO

Este documento tem como objetivo:

Identificar os serviços/interfaces a serem utilizados pelo projeto;

Possibilitar a verificação de eventuais conflitos com outros projetos;

Controlo dos serviços/interfaces a serem disponibilizados pela equipa de manutenção ao projeto

Controlo dos serviços/interfaces que o projeto está autorizado a solicitar pedidos de promoção

de ambiente

Controlo sobre o estado de aprovação da documentação do projeto

Do mesmo consta:

o Documentos a serem produzidos;

o Os serviços/interfaces/ações a criar, alterar e/ou usar, com a respetiva caracterização;

o Relações de conectividade – diretas - entre os serviços/interfaces

No início do projeto este documento é preenchido pela equipa de projeto com os serviços que

pretende criar, alterar ou utilizar. Após a entrega deste documento o mesmo será mantido pela equipa de

Arquitectura Aplicacional numa pasta, em que o projeto só terá acesso em modo de consulta. Após

entrega inicial por parte do projeto o documento será a base para:

Aprovação dos nomes dos serviços/interfaces/ações a serem usados pelo projeto;

Identificação de eventuais conflitos com outros projetos em termos da utilização dos mesmos

recursos. Caso tal aconteça haverá que definir um processo de mitigação.

Disponibilização por parte da equipa de manutenção dos objetos ao projeto;

Controlo por parte da equipa de manutenção dos objetos para os quais o projeto tem

autorização para solicitar pedidos de promoção de ambiente;

Verificação do status de aprovação da documentação do projeto.

5.2. PIARQT012 – MÉTRICAS DE PROJETO

Este documento tem como objetivo dar visibilidade sobre os resultados dos testes efetuados em cada

um dos ambientes.

Este documento é obrigatório para a autorização de passagem de ambiente, sendo que sempre que é

efetuado um ciclo de testes os resultados dos mesmos devem ser incluídos no documento.

Os dados recolhidos irão permitir efetuar avaliação a:

Serviços/interfaces executados;

Todos os serviços/interfaces deverão ter sido executados antes de ser solicitada a

passagem de ambiente.



Nº de execuções dos serviços/interfaces;

Os serviços/interfaces deverão ser executados garantindo a passagem por todas as

condições de teste.

Tipo e Nº de erros ocorridos

Os códigos de erros diferentes de sucesso, em caso de ocorrência terão que ser

devidamente justificados.

Tempos de execução

Tempos de execução que fujam do previamente definido, terão que ser devidamente

justificados.

Serviços/interfaces com Código de erro diferente dos códigos definidos;

Os códigos de erro possíveis de usar são os que se encontram publicados. Caso os projetos

necessitem de novos códigos os mesmos têm que ser previamente discutidos com a área de

Arquitectura Aplicacional.

Este documento será gerado pela Arquitetura após o preenchimento por parte do projeto da

folha de Integração-Métricas (PIARQT012) disponível no PIARQT011 – Checklist de Projeto.

5.3. PIGENT004 – ANÁLISE DE GAP’S

Este documento sistematiza os Gap´s entre a situação atual e a situação desejada com a

implementação do projeto, identificando as ações a executar para colmatar os mesmos.

O documento encontra-se dividido em Gap’s do tipo:

Funcionais;

Técnicos;

Segurança;

Outros (Adicionais).

Os Gap’s identificados deverão estar claramente associados aos requisitos do projeto, os quais

deverão estar sistematizados no documento “PIGENT005 – Requisitos Técnicos”.

5.4. PIGENT005 – REQUISITOS TÉCNICOS

Sistematiza os requisitos do projeto (funcionais, técnicos, de segurança e outros) definindo, entre

outros aspetos, a respetiva importância (prioridade), dependência com outros requisitos, e a versão da

release em que o mesmo será disponibilizado (caso exista faseamento).

5.5. PIGENT010 – DEFINIÇÃO CONCEPTUAL DA SOLUÇÃO

Este documento tem como objetivo definir a alto nível (conceptual) a solução futura e o respetivo



plano de implementação (faseamento dos trabalhos).

5.6. PIGENT011 – DEFINIÇÃO DESENHO FUNCIONAL DA SOLUÇÃO

Com base no documento “PIGENT010 – Definição Conceptual da Solução” é efetuada especificação

funcional da solução a implementar em termos de:

Processos de Negócio;

Diagrama de estados de entidades;

Arquitectura técnica de alto nível.

5.7. PIGENT012 – DEFINIÇÃO DESENHO TÉCNICO DA SOLUÇÃO

Neste documento é efetuado a especificação da Arquitectura técnica nas suas várias componentes

de uma forma detalhada, é efetuado o desenho dos vários processos e das suas componentes.

Este documento deverá ser complementado com o preenchimento dos documentos:

PIGENT115 – Inventário de Erros e Avisos;

PIGENT016 – Mapeamento de Dados.

Atualmente o template disponível está orientada a dar uma visão mais focada na componente TIBCO.

No entanto, o detalhe a disponibilizar ao nível do SAP PI deverá ser semelhante ao TIBCO.

5.8. PIGENT113 –DEPLOYMENT

Deverá ser preenchido sempre que um projeto passe de ambiente (Qualidade e Produção). Este

documento conterá regras, variáveis e nomenclaturas adicionais que não se encontrem já definidas no

documento de Deployment Global PIARQD114, nomeadamente:

Arquitectura;

Pré-requisitos de instalação;

Identificação das componentes a instalar e respetiva localização;

Variáveis globais utilizadas;

Valores específicos utilizados;

Distribuição dos objetos/serviços pelas máquinas;

Instruções de instalação;

Instruções de verificação da instalação;

Análise de carga.

Sempre que existir um conflito entre as regras globais PIARQD014 e o PIGENT013, este ultima

prevalecerá já que deverá ser entendido como uma necessidade do projeto.



5.9. PIGENT115 – INVENTÁRIO DE ERROS E AVISOS

Documento Único com a sistematização dos erros que podem ocorrer, das causas, impactos,

criticidade e respetivas ações a desencadear.

Este documento é Único e deverá ser atualizado aquando a conclusão de desenho de um novo

projeto

5.10. PIGENT016 – MAPEAMENTO DE DADOS

Documento por objeto/Fluxo que estabelece a interligação entre interfaces/objetos ao nível de regras

de validação e regras de conversão.

Este documento será o ponto principal de contacto entre as equipes de projeto e a sua versão final

será utilizada para atualizar o PIARQT103 – Cadastro de Interfaces Unificado

5.11. PIGENT119 – ESPECIFICAÇÃO DO SERVIÇO

Cada Documento conterá o desenho funcional e regras específicas do Serviço indicando:

Os projetos onde o serviço é utilizado

A Lógica (workflow) do serviço/Interface

Os Serviços Funcionais que serão invocados no caso de ser um serviço corporativo

Os Sistemas destino e seus objetos que serão invocados no caso de ser um serviço Funcional

Regras específicas do serviço

A criação deste documento só é necessária caso o interface necessite de ser atualizado ou é novo na

GALP.

5.12. PIGENT120 – COMMUNICATION CHANNELS

Este documento deve ser criado e atualizado pelos projetos sempre que existir a criação/alteração de

Communication Channels.

5.13. PIGENT022 – CHECKLIST DEPLOY

Deverá ser criado com as ações de todas as equipas para que se possa assegurar que nenhum

ponto seja esquecido aquando a passagem a qualidade/produção.

5.14. PIQAST001 – PLANO DE ABORDAGEM AO TESTE

Definição da estratégia de abordagem ao teste nos vários ambientes e para os vários tipos de teste

ao nível de:



Ambiente de teste (Arquitectura);

Pré-requisitos;

Responsabilidades na execução dos testes;

Identificação (inventário) dos casos de testes a executar.

Este documento deverá ser complementado com a elaboração do documento “PIQAST003 – Plano

de Testes”.

A elaboração destes documentos terá que estar de acordo com a metodologia de testes definida pela

Galp Energia a qual tem por base o “V-Model”.

5.15. PIQAST003 – PLANO DE TESTES

Documento com a especificação dos testes a serem executados:

Condições de Teste;

Ciclos de Teste;

Cenários de Teste;

Script de Teste;

Gestão de erros – Controlo da resolução das anomalias identificadas.

5.16. CHANGE ORDER

Sempre que se pretenda a passagem de ambiente é necessário o preenchimento deste documento

com pelo menos 15 dias de antecedência à execução da operação. No entanto, este tempo deverá ser

previamente acordado entre o projeto e o Outsourcer.

Documents

Guia de Integração SAP PI - energia cria energia - Galp · plataforma TIBCO, no documento PIARQD018 – Códigos de Erro Comum. Uma vez testadas, as interfaces/serviços deverão