🚶 🦂 👩🏻‍🔧 Tutorial do DataPower 🥔 🧓🏿 🛒

Material co-escrito por wedmeed

Em 2017, quando nosso projeto começou no Vietnã, encontramos o novo IBM DataPower para nós. O IBM DataPower é um produto de gateway entre clientes e back-end projetado para filtragem, roteamento, enriquecimento ou outras transformações de mensagens que passam por ele (daqui em diante referidos como pedidos). Era necessário aprender rapidamente, não havia tempo para o acúmulo, por isso fomos convidados a nos familiarizar com ele, após o que houve muitas horas de conferência pelo Skype com nosso colega de Moscou, que nos transmitiu seu conhecimento e experiência com este produto.

O auto-estudo foi baseado no estudo da documentação e na exibição de vídeos de treinamento da Internet - e aqui eu estava esperando uma captura. Eu praticamente não consegui encontrar informações em russo. Aliás, meu conhecimento da língua inglesa naquela época não era do mais alto nível, além de ter sido meu primeiro projeto e, provavelmente, esses fatores complicaram minha vida. Isso me fez escrever um artigo de treinamento em russo e da maneira mais simples possível para desenvolvedores iniciantes que se depararam com este produto e estão tentando entender rapidamente seus conceitos básicos. O artigo não o livrará da leitura da documentação, mas facilitará a vida nos estágios iniciais do entendimento de "como funciona".

Também é importante notar que a estrutura dada na prática será próxima do projeto real, o que permitirá que você a use como base, expandindo e complementando seus requisitos. Em conclusão, algumas palavras sobre o projeto já implementado, bem como alguns recursos que merecem atenção, serão dados nas seções de Teoria.

Parte 1. Instalando o DataPower com a Docker Toolbox

Instale e execute o aplicativo Docker Toolbox. Imediatamente após a inicialização, você verá o endereço IP da máquina, através do qual o DataPower estará disponível no futuro:

Para iniciar a imagem, você precisa alterar algumas configurações da máquina virtual (relevante para a versão IDG.2018.4.1.0) e reiniciá-la:

Pare a máquina docker com o comando:
```
docker-machine stop 
```
Sistema -> Placa Mãe -> Memória principal: mínimo 4096Mb;
Sistema -> Processador: mínimo 2;
Exibir -> Tela -> Memória de vídeo: pelo menos 128 Mb;
Iniciamos a máquina docker com o comando:
```
 docker-machine start 
```
Nota Se solicitado a reiniciar o ambiente da máquina docker, execute:
```
 docker-machine env 
```
Em seguida, você precisa esvaziar a imagem do IBM DataPower:
```
 docker pull ibmcom/datapower 
```

Em seguida, inicie o contêiner do docker com o seguinte comando:

 docker run -it \ -v $PWD/config:/drouter/config \ -v $PWD/local:/drouter/local \ -e DATAPOWER_ACCEPT_LICENSE=true \ -e DATAPOWER_INTERACTIVE=true \ -p 9090:9090 \ -p 3630:3630 \ -p 9022:22 \ -p 7170:7170 \ --name idg \ ibmcom/datapower

Após concluir o comando, pressione Enter e digite admin / admin como o nome de usuário e a senha.
Para iniciar a Web Management Interface, use os comandos:
```
 co 
```
e
```
 web-mgmt 0 9090 
```
Após todas essas etapas, execute no navegador https://192.168.99.100:9090/

Parte 2. Domínios

2.1 Teoria

Os domínios no DataPower permitem separar ferramentas de administração e desenvolvimento, além de fornecer segurança.

Após a instalação, existe apenas um domínio padrão a partir do qual os domínios do aplicativo podem ser criados. Cada domínio possui sua própria configuração de parâmetros.

Alguns recursos e parâmetros comuns podem ser definidos apenas no domínio padrão, incluindo interfaces de rede, usuários e controle de acesso, domínios de aplicativos e outros.

Um domínio de aplicativo é uma seção de desenvolvimento para serviços de processamento de solicitações. Os serviços definidos nele não podem ser compartilhados com outro domínio de aplicativo. Os domínios de aplicativos podem ser reiniciados separadamente e independentemente, sem a necessidade de uma reinicialização completa do DataPower.

Você pode criar, reiniciar, redefinir, pausar, renovar ou excluir domínios. Você pode encontrar informações mais detalhadas sobre todos os recursos de administração na documentação oficial.

Um pouco sobre o projeto concluído. Foram utilizados três domínios:

padrão - o domínio padrão que contém recursos e parâmetros compartilhados;
tronco - o domínio principal que contém tudo o necessário para processar solicitações;
configurações - configurações e domínio de segurança, os arquivos locais contêm informações sobre regras de roteamento de serviço e configurações de segurança.

A necessidade de transferir todas as configurações para um domínio separado surgiu em conexão com a busca de um caminho de implantação mais simples. Como em muitos projetos, os ambientes dev, test e prod foram separados, e a transferência para um domínio de configurações separado nos permitiu instalar todos os principais domínios do ambiente dev em outros ambientes por meio de exportação / importação, sem o risco de perder as configurações do ambiente.

2.2 Prática

No campo de pesquisa, digite "domínio", selecione "Domínio do aplicativo" e clique em "Adicionar"
Aqui você precisa especificar o nome do domínio, comentar (se desejar) e ativar a auditoria e o log. Preencha os campos e aplique as alterações
Da mesma forma, adicione outro domínio "tronco"
Vá para Revisar alterações
e salve a configuração do domínio
Você pode verificar o status dos objetos criados, indo para o domínio padrão na árvore de navegação em Status -> Principal -> Status do Objeto
Escolha Visualizar por: tipos
Encontre o domínio do aplicativo na lista e verifique o status dos objetos: cada um deles deve ser salvo, ligado e no estado ativo. Nesse caso, continue no próximo capítulo.

Parte 3. Gerenciadores de Filas

O gerenciador de filas não é um componente obrigatório do IBM DataPower, mas é através do exemplo do MQ que você pode mostrar a potência total deste produto. Usaremos o MQ da IBM. Durante o teste descrito no Capítulo 6, precisaremos enviar uma mensagem para o gerenciador de filas local. Neste artigo, farei isso usando o utilitário rfhutil, mas você pode usar qualquer método disponível para você. Para testar, você precisará criar uma conexão do DP com o gerenciador de filas local usando o MQ Queue Manager.

3.1 Teoria

O gerenciador de filas fornece troca de dados entre o gateway e os gerenciadores de filas remotas.

Você também pode configurar o MQ Queue Manager Group, o que aumentará a tolerância a falhas do sistema. Isso pode ser útil, por exemplo, se você deseja conectar o cliente a qualquer um dos conjuntos de gerenciadores de filas de trabalho e, em alguns casos, que podem ser encontrados na documentação oficial.

Pela experiência do projeto, apenas um recurso deve ser observado: ao mesmo tempo, queríamos tentar implementar o balanceamento de carga usando o DataPower, em particular usando grupos de gerenciadores de filas, mas, na prática, não encontramos essa oportunidade. Uma solução alternativa é criar um cluster de gerenciadores de filas.

3.2 Prática

3.2.1 Preparação

Instale o WebSphere MQ;
Crie um gerenciador de filas LOCAL_DP_QM local, acessível na porta 3630;

Configurar canal DP.SVRCONN;

Ao criar um canal, os seguintes comandos podem ser úteis:

 strmqm LOCAL_DP_QM /*  mq*/ runmqsc LOCAL_DP_QM /*   mq*/ DEFINE CHANNEL (DP.SVRCONN) CHLTYPE(SVRCONN) MCAUSER('evlasenko') /* */ SET CHLAUTH('DP.SVRCONN') TYPE(USERMAP) CLNTUSER('evlasenko') USERSRC(channel) ADDRESS('*') ACTION(ADD) /*      */ SET CHLAUTH(DP.SVRCONN) TYPE(BLOCKUSER) USERLIST('nobody') /*   */ ALTER LISTENER (SYSTEM.DEFAULT.LISTENER.TCP) TRPTYPE(TCP) PORT(3630) control(QMGR) /*    3630*/ ALTER AUTHINFO (SYSTEM.DEFAULT.AUTHINFO.IDPWOS) AUTHTYPE(IDPWOS) CHCKCLNT(OPTIONAL) /* */ REFRESH SECURITY TYPE(CONNAUTH) /*  */ endmqm LOCAL_DP_QM /*  mq*/ strmqm LOCAL_DP_QM /*  mq*/ END

Crie as filas DP.IIB.REQIN e DP.IIB.RESIN
Execute rfhutil com o nome do usuário para quem o canal foi criado. Na linha Nome do gerenciador de filas (à qual se conectar), escreva:
```
 DP.SVRCONN/TCT/127.0.0.1(3630) 
```
Tente carregar a lista de nomes de filas; não deve haver erros na janela de mensagem. A conexão com o canal foi verificada.

3.2.2 Criar IBM MQ Queue Manager

Vá para o domínio do tronco.
Na pesquisa, digite MQ, selecione IBM MQ Queue Manager e clique em Incluir.
Você precisa especificar o nome (TEST_QM), o nome do host do gerenciador de filas, o nome do gerenciador de filas e o nome do canal, bem como o tempo limite. Configure e salve as alterações.

Verifique o status do objeto do gerenciador de filas da mesma maneira que verifica o status dos domínios. Para fazer isso, selecione Status do objeto e o filtro Exibir por: tipos do domínio de tronco. Na seção "IBM MQ Queue Manager", localize o objeto apropriado e verifique seu status.

Parte 4. Gateways Multiprotocolo

4.1 Teoria

O Multi-Protocol Gateway (MPG) é um gateway de multiprotocolo que permite receber solicitações de clientes usando vários protocolos e depois transferi-los para diferentes servidores usando vários protocolos. O protocolo usado pelo cliente pode não corresponder ao protocolo usado pelo servidor de acesso remoto.

Nas configurações principais do MPG, você pode definir os seguintes componentes:

XML Manager - controla a compilação e o cache de folhas de estilo (xsl, xslt), cache de documentos.
Política - consiste em regras, cada uma das quais define um conjunto de ações aplicadas à mensagem que passa pelo gateway.
Configurações das partes frontal e traseira (URL de configuração, tipos de mensagens recebidas e enviadas, tempos limite e muito mais).

Algumas palavras sobre o projeto:

O projeto usa 4 gateways de multiprotocolo (roteamento, 2 transformacionais para diferentes sistemas finais e outro projetado para receber arquivos do domínio de configurações). O diagrama abaixo mostra o esquema de interação geral:

A quantidade de MPG pode variar dependendo da arquitetura da solução como um todo. No nosso caso, o DataPower enfrenta um barramento de integração (IIB) e microsserviços, que apresentam diferenças significativas nas interfaces (json / http versus xml / mq), por isso foi decidido fazer MPGs transformacionais para cada back-end específico e nomeá-lo de acordo. Para todos os clientes, trabalhamos em json / http; portanto, o roteamento MPG é um deles. Os principais MPGs consistem em três regras para o processamento de mensagens - solicitação, resposta e erros. Cada regra consiste nas ações necessárias, como transformação, log, roteamento e outras.

Dos recursos - se na política você usar a ação ConvertQueryParamToXML, esteja atento ao InputConversion. Se você definir a Codificação padrão como JSON e tentar enviar uma solicitação GET, ficará surpreso ao descobrir que a mensagem não passou por nenhuma transformação especificada e não encontrou nenhum rastro. Esse recurso ajudará a superar a criação de uma regra separada para solicitações GET.

4.2 Prática

4.2.1 Preparação

Você pode encontrar todos os arquivos necessários para o trabalho no link https://github.com/EvgenyaVlasenko/IBM_DataPower.git

4.2.1.1 Tronco de domínio

Vá para o domínio do tronco.
No painel de controle, selecione Gerenciamento de arquivos.
No diretório local, crie a seguinte estrutura de diretórios e coloque os arquivos correspondentes (cada arquivo contém uma breve descrição de quais funções ele executa, além de uma discussão mais detalhada sobre isso posteriormente no artigo).

4.2.1.2 Configurações de domínio

Vá para o domínio de configurações.
No painel de controle, selecione Gerenciamento de arquivos.
No diretório local, crie a seguinte estrutura de diretórios e coloque os arquivos apropriados (os arquivos também contêm uma breve descrição deles).

4.2.2 Criar GetFileMPG

Primeiro, crie um MPG auxiliar simples que retorne arquivos do domínio de configurações.

Vá para o domínio de configurações.
No painel de controle, selecione Gateway de protocolo múltiplo e clique em Criar.
Especifique o nome (GetFileMPG), descrição (opcional) e tipo de back-end (dinâmico). De fato, como não haverá chamada para o back-end e apenas o arquivo será retornado do sistema local, neste exemplo, você pode especificar qualquer tipo de back-end.
Especifique os tipos de solicitação e resposta. A especificação explícita de tipos reduzirá o número de verificações em linha. A especificação do tipo de passagem permite que você não crie uma regra (nesse caso, para transformar a resposta). Se especificarmos o Tipo de solicitação também como Passagem, não poderemos processar a mensagem de nenhuma maneira. Esta opção não nos convém, portanto, restringimos o tipo de solicitação usando Não XML.
Clique em + e selecione o manipulador de HTTP para criar um novo protocolo do lado da frente.
Aqui você deve especificar um nome, endereço IP, porta e uma lista de métodos permitidos. Preste atenção ao endereço IP. Se você especificar 0.0.0.0, todos poderão acessar esse gateway. Se 127.0.0.1 - apenas outros gateways dentro do mesmo DataPower. Como existem parâmetros de segurança entre as configurações, usamos a segunda opção. Preencha os campos e clique em "Aplicar", o protocolo será adicionado automaticamente ao gateway.
Clique em + para adicionar uma nova política.
Preencha o nome da política "GetFilePolicy".
Crie uma nova regra, preencha o nome e a direção da regra. Como realmente não há back-end e apenas o arquivo desejado é retornado, haverá apenas uma regra (cliente para servidor).
Clique duas vezes na ação Corresponder para configurá-la, selecione uma regra existente e aplique as alterações. Seria ideologicamente correto definir um limite para a capacidade de receber apenas solicitações Get, mas dentro da estrutura da tarefa de treinamento, você pode escolher uma existente.
Adicione outra ação - GatewayScript, arrastando-o para a regra e configure-o. Como transformação, usaremos o arquivo preparado, que no sistema de arquivos local: /// encontrará o arquivo por nome no URI da solicitação de entrada e o colocará no corpo da mensagem. O resultado da operação será transferido diretamente para o buffer de saída da regra. Salve as alterações.
O resultado final da política deve ficar assim:
A criação do MPG está concluída, salve as alterações.
Você pode verificar o sucesso de sua criação usando o Status do objeto, semelhante à verificação do status dos domínios e do gerenciador de filas. Para fazer isso, selecione Status do objeto e o filtro Exibir por: serviços no domínio de configurações. Na seção "Gateway de protocolo múltiplo", procure o objeto correspondente e verifique seu status.
Você não pode chamar esse MPG de fora, pois você o protegeu com ip. Altere temporariamente o ip de 127.0.0.1 para 0.0.0.0 e a porta de 7171 para 7170 e execute a seguinte consulta:
```
 curl -vv -k "http://192.168.99.100:7170/trunk/route/routeRules.xml" 
```
Você deve obter a seguinte resposta:
Novamente, altere o ip e a porta para o 127.0.0.1:7171 original.

4.2.3 Criando RoutingMPG

Agora crie RoutingMPG. Com base na solicitação de entrada e nas regras de roteamento, ele determinará onde e com quais parâmetros a solicitação deve ser enviada.

Vá para o domínio do tronco.
Crie um novo gateway multiprotocolo de acordo com as cláusulas 2-10 da seção 4.2.2 usando os seguintes valores:
- 3 - nome: RoutingMPG, tipo de back-end: Dinâmico (para a capacidade de rotear solicitações para diferentes MPGs, se necessário).
- 4 - Rq: não xml, Rs: não xml.
- 6 - nome: RoutingHTTP_FSH, ip: 0.0.0.0, porta: 7170, + Método Get.
- 8 - nome: RoutingPolicy.
- 9 - nome: RoutingPolicy_rule_req, direção: cliente para servidor.
Adicione mais uma ação para rotear a solicitação: para fazer isso, arraste a ação “Rota” para a regra, clique duas vezes nela para configurá-la, preencha os campos e aplique as alterações. O arquivo route.xsl recebe o arquivo de configurações de roteamento do domínio de configurações por meio do GetFileMPG criado anteriormente. Depois disso, com base no URI, as configurações necessárias para esta operação já estão selecionadas no arquivo. Alguns deles são usados para roteamento e outros são adicionados aos cabeçalhos para uso em outros MPGs. Os parâmetros de entrada e saída determinam a maneira de trabalhar apenas com o corpo da mensagem e de forma alguma afetam cabeçalhos e variáveis. Portanto: input from null - já que as informações do corpo da mensagem não são usadas para roteamento. A saída é nula - pois o resultado da transformação é apenas uma alteração nas informações de serviço.
Da mesma forma, crie mais 2 regras e salve todas as alterações:
- Direção: Servidor-Cliente, nome: RoutingPolicy_rule_resp;
  Transformação: Entrada INPUT, Saída NULL, local do arquivo de transformação: ///RoutingMPG/transform/resp.xslt. O arquivo resp.xslt recebe o status http da resposta MPG de transformação e o define explicitamente como a resposta RoutingMPG. Se isso não for feito, o código padrão será definido como 200, mesmo se ocorrer um erro na transformação MPG.
- Direção: Erro, nome: RoutingPolicy_rule_error;
  Transformação: INPUT de Entrada, PIPE de Saída (de acordo com a documentação, usar PIPE entre dois nós de ação adjacentes como INPUT e OUTPUT pode eliminar processamento adicional e reduzir a quantidade de memória usada), o arquivo de transformação é local: ///RoutingMPG/transform/errors.xsl. O arquivo errors.xsl recebe o código e o texto do erro da resposta do MPG de transformação e gera uma mensagem de erro JSON no formato esperado pelo cliente.
O resultado final da política deve ficar assim:
A criação do MPG está concluída, salve as alterações.

Usando, por exemplo, o utilitário curl, execute a seguinte consulta:

 curl -vv -k "http://192.168.99.100:7170/dp/test/transformMessage"

Se você receber o seguinte erro, tudo será feito corretamente. Esse erro significa que a mensagem foi recebida e processada com êxito, mas a tentativa de chamar o back-end (neste caso, IIBMPG) não teve êxito. Vá para o próximo passo.

4.2.4 Criação do IIBMPG

O próximo passo é criar um MPG transformacional. Suponha que o sistema externo esteja no formato de solicitação JSON e o interno seja XML. Precisamos transformar a mensagem de entrada para que o sistema interno possa entendê-la. Vale ressaltar que isso nem sempre é uma simples conversão de toda a mensagem. Geralmente, é necessário transmitir uma mensagem truncada ou aumentada, às vezes com uma estrutura completamente redesenhada.

Vá para o domínio do tronco.
Crie um novo gateway multiprotocolo de acordo com as cláusulas 2-10 da seção 4.2.2 usando os seguintes valores:
- 3 - nome: IIBMPG, tipo de back-end: Dinâmico
- 4 - Rq: JSON, Rs: XML
- 6 - nome: IIBHTTP_FSH, ip: 127.0.0.1 (apenas solicitações do mesmo DataPower), porta: 7172, + Método Get
- 8 - Nome: IIBPolicy
- 9 - nome: IIBPolicy_rule_req, direção: cliente para servidor
Adicione uma descrição. Com base no X-DP-Transform-Name nos cabeçalhos da solicitação, o arquivo IIBRuleRoute.xsl recebe do arquivo local: ///IIB/route/IIBRouteRules.xml os nomes dos arquivos de transformação da solicitação, resposta e erro desse serviço e define seus valores para as variáveis de contexto correspondentes var: // contexto / IIB / reqTransform, var: // contexto / IIB / ansTransform, var: // contexto / IIB / errTransform. Outros valores dos cabeçalhos (url, uri, expirar, timeout) também são colocados em variáveis de contexto.
Adicione outra ação arrastando Avançado à sua regra e selecionando Converter Parâmetros de Consulta em XML na lista, configure. Você precisa adicionar um novo mapa de conversão de entrada, fornecendo um nome (cmnJSONParseCNVM) e o tipo necessário (JSON).
Adicione a transformação após a conversão padrão e configure-a. Nesse caso, a variável definida na transformação anterior é usada para indicar o arquivo de transformação. Isso é feito para que a transformação seja universal e o próprio arquivo seja substituído "on the fly", dependendo da mensagem de entrada. O corpo da mensagem está pronto. O próximo passo é rotear a mensagem, e o corpo da mensagem não será alterado. Por isso, criamos a variável dpvar_1 e salvamos o resultado nela. É essa variável que apontamos para a entrada da ação Results. Salve as alterações.
Adicione uma ação de roteamento e defina os seguintes parâmetros. O arquivo IIBURLRoute.xsl recebe os valores das variáveis de contexto, algumas delas são definidas como variáveis de solicitação de serviço e, do resto, forma um URI para a solicitação ao sistema de destino, que também armazena na variável de serviço.
Da mesma forma, crie mais 2 regras e salve todas as alterações:
- Direção: Servidor-Cliente, nome: IIBPolicy_rule_resp;
  Transformação: INPUT de entrada, PIPE de saída, arquivo de transformação var: // context / IIB / ansTransform (variável de contexto para substituir a transformação da resposta "on the fly").
- Direção: Erro, nome: IIBPolicy_rule_error;
  Transformação: Entrada NULL, PIPE de Saída, arquivo de transformação var: // context / IIB / errTransform (variável de contexto para substituir a transformação de erro em tempo real).
O resultado final da política deve ficar assim:
A criação do MPG está concluída, salve as alterações.

Parte 5. Teste

5.1 Preparação

Faça o download, por exemplo, do utilitário rfhutil para ler e gravar mensagens na fila;
Os arquivos de teste estão localizados na pasta de testes do mesmo diretório que os arquivos do projeto.

5.2 Verificação de integridade

Envie a solicitação usando o utilitário curl (para a solicitação abaixo, o diretório atual deve ser o mesmo que exemplo.json).

 curl -vv -k "http://192.168.99.100:7170/dp/test/transformMessage" -H "Content-Type: application/json" --data-binary @example.json

Abra 2 instâncias do utilitário rfhutil e subtraia a mensagem da fila DP.IIB.REQIN com a primeira instância;
Vá para a guia MQMD e copie o MessageID;
Na segunda instância, abra o arquivo rs.xml, na guia MQMD, insira o identificador da mensagem no CorrelID e coloque a mensagem na fila DP.IIB.RESIN;
Você deve obter uma resposta semelhante:
Repita as etapas 1 a 3;
rs_error.xml correllId;

6.

6.1 Teoria

Log Targets , .

Log Targets . , 4 1000Kb, . 2-4 . , . , DataPower, , , , , , - MPG, .

6.2.

trunk;
Log Target ;
:
- (IIB_LOG);
- (File);
- (Text);
- timestamp(zulu);
- (logtemp:///IIB.log — IIBMPG);
- (1000).
. MPG IIBMPG.
, , ( , ).
;
;
.
Log Targets MPG.
:
- , , .
- .