Documenti di Didattica
Documenti di Professioni
Documenti di Cultura
HUB DE SERVIÇOS
TREINAMENTO
HUB DE SERVIÇOS
APRESENTAÇÃO DO PROJETO SANTANDER
APRESENTAÇÃO DO PROJETO SANTANDER
ARQUITETURA DE PROJETOS ÁGEIS
APRESENTAÇÃO DO PROJETO SANTANDER
ESTRUTURA DE EQUIPES ÁGEIS
APRESENTAÇÃO DO PROJETO SANTANDER
EQUIPE DE INFRAESTRUTURA
RTE – Release Train Engineer. Responsável por manter os processos de vários times
ágeis, os planos, as features, os prazos numa visão ampla do programa, escalar
impedimentos, resolver os riscos e todas as responsabilidades relacionadas ao projeto
para que ele seja disponibilizado com qualidade ao cliente.
SM – O Scrum Master é responsável por garantir que o Scrum seja entendido e aplicado
no time ágil, escalar e remover impedimentos. O Scrum Master faz isso para garantir que
o Time Scrum adere à teoria, práticas e regras do Scrum.
APRESENTAÇÃO DO PROJETO SANTANDER
EQUIPE DE DESENVOLVIMENTO
Multiplicador – Elegido pelo próprio squad, tem como objetivo apoiar o time quanto aos
processos do Hub de serviços, assim como também validar propostas e contratos e
conceder acessos / criar APIs.
APRESENTAÇÃO DO PROJETO SANTANDER
AMBIENTES DE SISTEMAS SANTANDER
Desenvolvimento – DEV
• Ambiente com dados mock, primeiros testes e versões, pouco parecido com o ambiente real
Homologação – HK
• Ambiente mais próximo do real, com dados tirados de produção e strings ofuscadas
Produção
• Ambiente produtivo, com as bases de dados reais
TREINAMENTO
HUB DE SERVIÇOS
FUNDAMENTOS DE SOA
FUNDAMENTOS DE SOA
FUNDAMENTOS TÉCNICOS DE SERVIÇOS
Captive
API Manager
Serviços
Serviços Portais
Parceiros
Microservices Layer
Backend
MX OSG LM
CB Profiling ...
EXERCÍCIO
</Criando XSD>
Criar estrutura xsd que comtemple os dados abaixo:
• Código do cliente
• Cidade
• Cnpj
• Endereço
• Estado
• Nome do cliente
• País
</Criando SOAP/XML>
Criar contrato WSDL com request e response
utilizando como base o XSD criado, request com o
codigo do cliente e response com o restante dos
dados
EXERCÍCIO
</Criando Rest/Json>
Criar estrutura Rest com base no WSDL criado
TREINAMENTO
HUB DE SERVIÇOS
CONCEITO DE SERVIÇOS E MICROSERVIÇOS
CONCEITO DE SERVIÇOS E MICROSERVIÇOS
DIFERENÇAS ENTRE WEB SERVICE /
MICROSERVICE
• Maquina virtual
• Acesso administrativo à VM
• Acesso ao Gitlab
• Acesso ao Jenkins
• Acesso ao ZUP
• Acesso ao WSRR
Falar com o multiplicador para que possa orientar no processo, caso não seja possível,
falar com seu Scrum Master.
TREINAMENTO
HUB DE SERVIÇOS
IMPLEMENTAÇÃO HUB - SANTANDER
IMPLEMENTAÇÃO HUB – SANTANDER
CONFLUENCE HUB
O GitLab, interface web por meio da qual os repositórios do Git são administrados, é um
componente fundamental dentro do processo de DevOps, uma vez que, possibilita que o código-
fonte dos projetos seja acessado de forma centralizada. Link: https://gitlab.produbanbr.corp/
IMPLEMENTAÇÃO HUB – SANTANDER
JENKINS
Jenkins
Jenkins é um servidor de Integração Contínua open-source feito em Java, pode ser rodado de
forma standalone ou como uma web aplicação dentro de um servidor web.
Link: http://jenkins.produbanbr.corp/
IMPLEMENTAÇÃO HUB – SANTANDER
SOAPUI
Jenkins
Soapui é uma ferramenta de teste de serviços web, codigo fonte aberto, para SOA e
REST. Abrange desde teste de inspeção, chamadas, simulação, mock, teste funcional, de
carga e tesde de compliance.
Link para download: https://www.soapui.org/downloads/soapui.html
IMPLEMENTAÇÃO HUB – SANTANDER
POSTMAN
Jenkins
Postman é uma ferramenta de teste de serviços web, codigo fonte aberto, para SOA e
REST. Abrange desde teste de inspeção, chamadas, simulação, mock, teste funcional, de
carga e tesde de compliance.
Link para Download: https://www.getpostman.com/apps
IMPLEMENTAÇÃO HUB – SANTANDER
PROCESSO DEPLOY - DEVOPS
IMPLEMENTAÇÃO HUB – SANTANDER
ACELERADOR WSDL HUB SANTANDER
Observações:
Link: https://developer.ibm.com/integration/docs/ibm-integration-bus/get-started/get-
started-with-ibm-integration-bus-for-developers/
DESENVOLVIMENTO IIB
OVERVIEW DA FERRAMENTA
• Baseada no Eclipse
• Não devem ser utilizados caracteres especiais como espaço. ('.', '$', '%', '#', []) e o uso de
algarismos deve ser evitado.
• Algumas abreviações referentes às tecnologias podem ser utilizadas como sufixo dos nomes.
Esta abordagem visa reduzir a ambigüidade entre os artefatos gerados em uma solução SOA.
Outras abreviações podem ser ambíguas. Os nomes utilizados devem ser precisos. Não abrevie
a não ser que o nome do objeto seja muito longo.
• Recomenda-se o uso do nome em singular. Os nomes no plural devem ser usados para
elementos que representem estruturas de listas e coleções para destacar que essas estruturas
podem armazenar mais que um elemento.
DESENVOLVIMENTO IIB
COMPONENTES MAIS UTILIZADOS
• Baseada em SQL
DESENVOLVIMENTO IIB
CRIANDO WSDL
</Criação de WSDL>
EXERCÍCIO
</Criação de WSDL>
Criar contrato WSDL com request e response
utilizando como base o XSD criado, request com o
codigo do cliente e response com o restante dos
dados no IBM Integration BUS
DESENVOLVIMENTO IIB
CONFIGURAÇÃO DE NODE REMOTO
Request Response
Response
Request
Verbo URI
• WS-Security
• HTTPS
• Certificados Digitais
• Autenticação e autorização
• Token
Mais informações no Link: https://confluence.ci.gsnet.corp/pages/viewpage.action?pageId=31179866
DESENVOLVIMENTO IIB
CRIPTOGRAFIA DE INFORMAÇÕES
• Utilize somente substantivos na URI. Verbos indicam ação, e não devem fazer parte da
identificação do recurso;
• Utilize substantivos no plural para coleções. Por exemplo, /products , e não /product ;
• Associações entre recursos devem ser refletidas nas URIs que os identificam, utilizando-se
aninhamento de URI. Por exemplo: /dentists/jsilva/slots ;
• Nomes compostos devem ser dash-case nas URLs, por exemplo: /user-details ;
• Para cenários muito comuns, podem ser utilizados aliases. Por exemplo:
/dentists/jsilva/slots/open;
• Caso o recurso tenha ordenação, utilize a query parameter sort . Por exemplo: /dentists/?&sort=-
date ;
• Com verbos que criam ou alteram recursos, o recurso atualizado deve ser retornado, para evitar
uma chamada extra para ler os dados atualizados;
DESENVOLVIMENTO ZUP
ESTRUTURAÇÃO DOS RECURSOS
CONFORME CDG
GET
Solicita a representação de um determinado recurso. É
definido como um método seguro e não deve ser usado para
disparar uma ação (remover um usuário, por exemplo). PUT
Atualiza um recurso na URI especificada. Caso o recurso
não exista, ele pode criar um. A principal diferença entre
POST POST e PUT é que o primeiro pode lidar não somente com
As informações enviadas no corpo (body) da requisição são recursos, mas pode fazer processamento de informações,
utilizadas para criar um novo recurso. Também é por exemplo.
responsável por fazer processamentos que não são
diretamente relacionados a um recurso. HEAD
Retorna informações sobre um recurso. Na prática, funciona
semelhante ao método GET, mas sem retornar o recurso no
DELETE corpo da requisição. Também é considerado um método
Remove um recurso. Deve retornar o status 204 caso não seguro.
exista nenhum recurso para a URI especificada.
DEMONSTRAÇÃO