Compilação de tutoriais blog MulePE

MulePe – Agosto de 2016
Compilação de tutoriais blogs MulePE
Segue uma compilação dos tutoriais do nosso blog até o momento, apesar de algo altamente amador espero que seja
útil, a novos Mule Developers de língua Portuguesa, que muitas vezes tem dificuldades de começar a aprender
mulesoft, por não encontrar uma boa quantidade de conteúdo na sua língua, apesar dos poucos acessos atuais do blog
espero que o mesmo prospere e atinja o público que espero para ele, sempre tentando melhorar os conteúdos e com o
tempo nos tornarmos menos amadores, e entregar aos leitores artigos mais organizados e com maior alcance.

Mulesoft no Brasil - Entrevista Edgar – Primeiro funcionário Mulesoft
Brasileiro
O que é a Mulesoft, quais são os principais projetos e produtos da
empresa?
A MuleSoft é a empresa por trás de vários projetos open source focados em
Integração/SOA e APIs. O mais famoso deles é o MuleESB, um dos primeiros
softwares de Enterprise Service Bus do mercado. A empresa também investe
no padrão RAML (http://raml.org/) usado para especificação, desenho e
implementação de APIs baseadas em REST. O objetivo do RAML é apoiar a
criação de um mundo de APIs conectadas, permitindo a interação de sites,
empresas, comércio eletrônico e até máquinas da chamada "Internet das
Coisas".
Para clientes corporativos, a MuleSoft oferece o suporte de produtos via
assinaturas. A empresa também disponibiliza seus produtos de forma
Community/Open Source. Nesse caso, o suporte vem da comunidade de
desenvolvedores que já soma mais de 150 mil mundialmente.
Fale-nos um pouco mais sobre integração e ESBs...
Integração é a peça chave no mundo conectado. Muitas empresas têm a
necessidade de fazer um sistema conversar com outro ou com vários. É aí que
surge a necessidade de usar um barramento de serviços e orquestração (ESB
ou Enterprise Service Bus). O ESB funciona essencialmente como mediador.
Imagine um serviço em um site de compras, que mostra o catálogo de produtos
mas que precisa se integrar com o meio de pagamentos rodando num
mainframe ou web service. É um exemplo de de necessidade comum hoje.
Além da mediação, um ESB oferece serviços como transformação de dados,
envio e roteamento de mensagens e várias outras funções.
Outro fator determinante para evolução deste tipo de tecnologia é o consumo
de serviços externos através de APIs, que vem chamando atenção do
mercado. Existem empresas hoje que fazem mais negócios com suas APIs que
com seus sites originais. É uma tendência apontada pela Gartner, Forrester e
outros institutos de pesquisa. E com a explosão do mobile e da Internet das
Coisas, as demandas por APIs, colaboração e agilidade nunca foram tão
grandes.
Poderia citar alguns exemplos de APIs que podem ajudar alavancar
negócios?

Claro. APIs para Dados Abertos, e-commerce, serviços de pagamento e de
viagens, entre outros. Estas são sérias candidatas a terem parte do seus
negócios, criados usando modelos baseados em REST/URIs e
implementações que podem ser camadas sobre sistemas que já existem e
funcionam.
O que fez a MuleSoft aportar no Brasil?
O Brasil respira open source, inovação e desafios! Então a MuleSoft tinha que
estar estabelecida aqui. Temos certeza de que o Brasil em muito pouco tempo
terá representatividade marcante para a empresa e para o mercado de
integração como um todo.
Qual o seu papel na MuleSoft Brasil e os planos para a empresa no país?
Sou o primeiro funcionário no Brasil e fui contratado para ser o responsável em
trazer a operação para o país. Desde o início de dezembro já temos escritório
em São Paulo, e o primeiro grupo de funcionários deve estar todo contratado
até o final do ano. Está em nossos planos ir muito em breve para Brasília;
também haverá atendimento ao Rio, BH, Porto Alegre, Salvador, Recife e
outras capitais, através de parceiros locais.
A demanda por soluções de integração passou por certa estagnação no
início nos anos 2000, mas agora está voltando com toda a força. O que
você acha que explica isso?
Em 2000 vivíamos o início das aplicações na web de forma efetiva, as
primeiras ASPs(Application Services Providers), que evoluíram e hoje são
chamadas de SaaS. Como exemplos temos a SalesForce.com se tornou uma
empresa gigante, e nem precisamos comentar do Google, Amazon Web
Services e outras.
Nessa linha, as integrações deixaram de ser apenas ponto a ponto, indo muito
além de (por exemplo) receber arquivos XML via Web Service ou FTP,
transformar esses arquivos, publicar num CICS e gravar num banco de dados.
Apesar de esses cenários ainda existirem, torna-se cada vez mais importante
conectar o mundo externo (a nuvem) com o interno (às vezes chamado "on-
premises software"). As empresas estão buscando uma visão global de seus
consumidores e clientes, e continuam na busca de fornecer maior agilidade e
de integrar seus sistemas antigos ou legados com soluções novas.
Mulesoft - Salesforce Analytics Cloud Connector
Por ser relativamente novo, atualmente temos pouco conteúdo em
português sobre o conector Salesforce Analytics Cloud para Mulesoft. Bom tive
a oportunidade de trabalhar com ambas as tecnologias Salesforce e Mulesoft, e
fiz algumas integrações utilizando esse conector que tem algumas diferenças
interessantes em relação a outros, que podem dar um pouco de dor de cabeça,
e fazer perder algum tempo, então vamos a um tutorial separado em algumas
partes com algumas observações:

Configuração: Temos algumas opções de autenticação, Basic e três
variedades de OAuth 2.0, como até agora nunca tive a necessidade de usar o
OAuth, vamos de Basic mesmo. É bem simples configurar a autenticação
Basic, ele pede :
1. Username e password: que são o login e senha da Org Salesforce que
você deseja acessar via mule.
2. Securitytoken: que é gerado pela Org Salesforce caso a mesma não possua
faixa de IP fixa, já que no caso de Orgs com faixas de IP controladas, não é
necessário o token para acessar o salesforce com sucesso, mas como o
campo do conector é obrigatório, se não tiver valor ele fica dando erro, então
podemos substituir o token por uma $variavel contendo um Space, ou Space
direto no campo.
3. Authorization Url seria um endpoint, basicamente seria seu Url de login +
“/services/Soap/u/31.0”, essa Url geralmente muda entre “login.salesforce.com”
para Org Production e “test.salesforce.com” para Org Sandbox, mas esses Urls
vão depender do domínio definido na org, apesar de funcionar esses dois
citados mesmo se a Org tiver um domínio próprio.
4. Metadata File Name, que seria o mapeamento das variáveis recebidas na
Entrada, esse metadata é um arquivo .Json que contém todas as variáveis que
serão recebidas por inbound, para que o conector encontre o arquivo de
metadata ele deve estar na pasta “src/main/resources”, alguns detalhes em
relação ao metadata são importantes, por exemplo após definidos os campos a
serem integrados, executado o fluxo e criado com sucesso um dataset no
Wave analytics, o Metadata não poderá ser modificado pra esse mesmo
dataset, no caso pra mudar o metadata tem que sobrescrever o dataset criado,
perdendo os dashboards criados a partir dele.
Abaixo segue um exemplo da configuração do conector:

Aqui um exemplo de Metadata.Json que será usado pra mapear os campos
que serão recebidos via .Csv e inseridos em um dataset no Wave Analytics:
{
"fileFormat":{
"charsetName":"UTF-8",
"fieldsEnclosedBy":",",
"fieldsDelimitedBy":",",
"linesTerminatedBy":"n",
"numberOfLinesToIgnore":1
},
"objects": [{
"connector": "Salesforce connector",
"fullyQualifiedName": "OrderInvoice_Teste_Performance_csv",
"label": "OrderInvoice_Teste_Performance.csv",
"name": "OrderInvoice_Teste_Performance_csv",
"fields": [{
"fullyQualifiedName": "cdOrder",
"name": "cdOrder",
"type": "Text",
"label": "cdOrder",
},
{
"fullyQualifiedName": "cdInvoice",

"name": "cdInvoice",
"type": "Text",
"label": "cdInvoice"
},
{
"fullyQualifiedName": "dtInvoice",
"name": "dtInvoice",
"type": "Date",
"label": "dtInvoice",
"format": "yyyy-MM-dd"
},
{
"fullyQualifiedName": "vlTotalInvoice",
"name": "vlTotalInvoice",
"type": "Numeric",
"label": "vlTotalInvoice",
"precision": 18,
"defaultValue": "0",
"scale": 4
},
{
"fullyQualifiedName": "cdStatusInvoice",
"name": "cdStatusInvoice",
"type": "Text",
"label": "cdStatusInvoice"
},
{
"fullyQualifiedName": "dsDistributorCountry",
"name": "dsDistributorCountry",
"type": "Text",
"label": "dsDistributorCountry"
},
{
"fullyQualifiedName": "cdDistributorCode",
"name": "cdDistributorCode",
"type": "Text",
"label": "cdDistributorCode"
},
{
"fullyQualifiedName": "dsDistributorName",
"name": "dsDistributorName",
"type": "Text",
"label": "dsDistributorName"
},
{
"fullyQualifiedName": "cdStore",
"name": "cdStore",

"type": "Text",
"label": "cdStore"
},
{
"fullyQualifiedName": "cdStatus",
"name": "cdStatus",
"type": "Text",
"label": "cdStatus"
},
{
"fullyQualifiedName": "dsStoreName",
"name": "dsStoreName",
"type": "Text",
"label": "dsStoreName"
},
{
"fullyQualifiedName": "cdSalesChannel",
"name": "cdSalesChannel",
"type": "Text",
"label": "cdSalesChannel"
},
{
"fullyQualifiedName": "dsSalesRep",
"name": "dsSalesRep",
"type": "Text",
"label": "dsSalesRep"
},
{
"fullyQualifiedName": "cdSalesRep",
"name": "cdSalesRep",
"type": "Text",
"label": "cdSalesRep"
},
{
"fullyQualifiedName": "cdSubChannel",
"name": "cdSubChannel",
"type": "Text",
"label": "cdSubChannel"
},
{
"fullyQualifiedName": "cdInternalID",
"name": "cdInternalID",
"type": "Text",
"label": "cdInternalID"
}]
}]

}
Agora mais um exemplo da configuração de execução do conector, nesse caso
usaremos o Upload external data into new data set Start processing, que serve
para atualizar e criar um novo dataset no Wave analytics, posteriormente vou
explicar cada campo a ser configurado:
Mulesoft - Salesforce Analytics Cloud Connector - Part 2
Bom continuando o tutorial anterior, já que configuramos a conexão com o
Salesforce, vamos a nosso fluxo, que será um batch utilizando um Database
Jdbc o Postgres nesse caso, pra realizar um insert de registros em um Dataset
do Wave analytics, o fluxo final deverá parecer com esse abaixo:
Para criar esse fluxo vamos seguir as seguintes etapas:
1 - Configurarando o Salesforce Analytcs Cloud Connector: Bom já que no
exemplo anterior conectamos o conector com a org salesforce, agora vamos
continuar a configuração dos três conectores Salesforce do exemplo acima
começando com o que está no INPUT do nosso fluxo, pra facilitar segue o
exemplo abaixo e logo depois a explicação:
Input

Bom nessa primeira parte usamos um conector de banco de dados genérico do
postgres que para funcionar precisamos criar um novo datasource do postgres
para isso devemos seguir a imagem abaixo:
Depois devemos ir em conector configuration e selecionar o conector Database
como na imagem abaixo:
Logo após inserir o conector de database devemos importar o drive JDBC do
Postgres para isso devemos ir na pasta do projeto e selecionar a opção build

path e Add External Archives, selecionando o arquivo Jdbc do postgres que
deve ser baixado no site do fabricante, abaixo segue a imagem do caminho:
Depois de inserir o arquivo Jdbc do Postgres devemos usar uma configuração
genérica, passando os dados de acesso do banco por uma string, e setando o
arquivo JDBC inserido anteriormente, já que o banco de dados usado não tem
um conector especifico pra ele como na imagem abaixo:
Bom já que nosso conector database está com a conexão configurada, vamos
inserir ele no nosso fluxo mule, mas antes devemos inserir um POOL com um
time para executar outra leitura no nosso banco e o processor chain, o nosso
conector database deve ser colocado dentro desses dois. Após a configuração

do nosso banco de dados deveremos definir uma query Sql para extrairmos os
dados necessários para inserirmos no nosso novo dataset, para nosso exemplo
já que é uma tabela bem pequena apenas com os campos usados no nosso
exemplo usei um Select all, mas a função suporta diversos comando Sql mais
complexos, como inner joins de várias tabelas, abaixo segue a imagem da
configuração:
Configuração conector Salesforce do Input:
No Input deveremos utilizar a conexão com o salesforce e setar nas configurações
do conector a operation Create data set, para criarmos um dataset Wave
analytics e armazenarmos sua configuração em uma variável, usando o
Messenger Enricher com o Target Marcado com a seguinte expressão
#[variable:dataSetId] como na imagem abaixo:

Devemos também definir a Operation do DatasetInfo como Overwrite que é um
comando para sobrescrever o dataset, e setar o nome, descrição e label que
você deseja que seu dataset tenha.
Process
No process records devemos inserir um Batch Step e dentro dele um Batch
commit com a seguinte configuração:

O tamanho do Commit size pode variar de acordo com a necessidade do usuário,
mas não recomento valores acima de 5000, pelo menos em testes que muitos
dados ficou um pouco mais lento o processamento.
Ainda no batch step devemos configurar o nosso Transformer, bom devemos
configurar o Setmetadata criando um map de List<Element> com os campos
que estiverem no seu banco de dados, como no exemplo a seguir:
E a saída deve ter uma List<Record> configurada o resultado esperado é algo
parecido com o que está na imagem abaixo:

Agora continuando na configuração de Process conector, nesse caso
usaremos o Upload external data into new data set Start processing, que
serve para dar upsert e criar um novo dataset no Wave analytics, logo abaixo
iremos detalhar melhor os campos presentes nessa parte da configuração.
Observação: Algo interessante sobre esse conector, é que para fazer update
de um registro, todos os campos precisam estar preenchidos, se por exemplo
no meu dataset existe uma linha de registro com vinte campos, e se quisermos
atualizar apenas um dos campos, se todos não estiverem preenchidos com os
dados anteriores, esses dados serão sobrescritos por espaços, então cuidado
quando for atualizar dados, se for o caso aconselho fazer isso usando a Rest
API do Salesforce Analytics Cloud.
O resultado esperado pelo Salesforce Analytics Cloud é uma List<Map> como na
imagem abaixo:
On complete:

Finalmente chegando no final do nosso fluxo, aqui inseri um logger só pra
acompanhar o que tava chegando no Payload mas essa parte é opcional, o
conector do salesforce analytics cloud, nessa parte inicia o processamento e
insere os dados armazenados na variável criada no inicio do fluxo no
Salesforce Wave Analytics, a configuração dele é basicamente o Start data
processing no operation e a variável no DatasetId como na imagem abaixo:
SALESFORCE MULE SECURITY
Salesforce Mule Security
•Introdução
•Conceitos
•HTTP basic authentication
•HTTPs e certificados
•Criptografia
•Dicas
Agenda
Intranet X Cloud
•Ambientecompletamentegerenciadopelocliente.
•Blindadodomundoexternoporfirewallseoutrasmedidasdesegurança.
•Comunicaçãodeaplicaçõesdedentrodaredecomoutrasaplicações/serviçosnapró
priarede(segurançanãonecessária)ouinternet(segurançanecessária)
Intranet:

Cloud:
•Ambientecompartilhadogerenciadoporempresasqueoferencemserviçosparanos
soclientes.
•Acessívelpelainternetcomsegurançaparafuncionalidadesoferecidaspelasaplica
çõesnativasdoCloud.
•Comunicaçãodeaplicaçõescomoutrasaplicações/serviçospelainternet(seguranç
anecessária).
Conceitos
•Autenticação (ex: login + senha)
•Autorização (perfil ou papel)
•Tipos de Segurança:
•Do canal (ex: HTTPS)
•Da mensagem (ex: criptografia AES [128, 192, 256 bits])
•Encode X Hash X Encriptação
•Interceptação de pacotes com programas Sniffer.
HTTP basic authentication (1)
•Cabeçalho HTTP/HTTPS com o seguinte formato:
•Nome: Authorization
•Valor: “Basic ” + (<usuario> + “:” + <senha>)
OBS: o trecho entre parênteses deve estar representado em base
64http://www.w3.org/Protocols/rfc2616/rfc2616-sec14.html
•No Salesforce (cliente):
request.setHeader('Authorization', 'Basic ' + EncodingUtil.base64Encode(
Blob.valueOf(‘user'+ ':' + ‘pass')));
•No Mule (servidor):
<http:basic-security-filter realm="mule-realm" />
<mule-ss:security-manager>
<ss:authentication-manager alias="basicAuth">
HTTP basic authentication (2)

HTTPS
•Http + certificado para identificar o serviço (basic authetication funciona igual).
•Adiciona segurança à comunicação.
•Segurança a nível de canal
•Cerificados:
•Keystore (jks): guarda um conjunto de dados de identificação da organização
com respectiva chave privada
•Certificate (crt): dados do certificado da organização extraídos do Keystore.
•Truststore (ts): lista de certificados considerados confiáveis.
•Tipos:
•Self-Signed
•Validados por uma entidade do ramo (ex: Verisign)
HTTPS (geração de arquivos com java)
•Ferramenta keytool disponível na pasta bin da JDK.
•Comandos:
•Gerar keystore:
keytool -genkey -alias <mule> -keyalg RSA -keystore <keystore.jks> -keysize
2048
OBS: o campo CN deve ser preenchi do com a URL do servidor que expõe o
HTTPS
•Extrair certificado do keystore:
keytool -export -alias <mule> -file mule.cer -keystore <keystore.jks>
•Importar certificado no truststore (existente ou novo):
keytool -import -v -trustcacerts -alias <mule> -file <mule.cer> -keystore
<truststore>
OBS: para testes HTTPS em javacom certificados self-signed importar o
certificado no arquivo “cacerts” em jdk/lib/security
HTTPS (mule)

Criptografia
•Transformação 1:1 reversível
•Algorítmos: AES, RSA, etc…
•Tamanhos de chave: 128 a 2048 BITS
•Não enviar a chave privada nas mensagens com o destino.
Criptografia (Salesforce side)
•Apex Crypto class ( https://developer.salesforce.com/docs/atlas.en-
us.apexcode.meta/apexcode/apex_classes_restful_crypto.htm)
•Usuário e senhas de acesso e criptografia salvos em Custom Settings.

Criptografia (Mule side)
•Biblioteca Java de criptografia
OBS: não suporta chave de 256 bits nativamente
Importante
•Não enviar senhas sem criptografia.

•Atenção ao tamanho da chave usada para criptografar.
•Verificar suporte ao algoritmo escolhido pelas tecnologias das aplicações em
comunicação.
•Para testes locais de HTTPS com java, certificados self-signed precisam ser
adicionados ao arquivo “cacerts”.
•Com SSL one-wayé preciso apenas o keystore,para o two-way é preciso o
truststoretambém e configurações no cliente que acessa o endpoint.
Referências Adicionais
•http://adambard.com/blog/3-wrong-ways-to-store-a-password/
•http://stackoverflow.com/questions/4948322/fundamental-difference-between-
hashing-and-encryption-algorithms
•http://www.w3.org/Protocols/rfc2616/rfc2616-sec14.html
RESTFUL - PART 1
Definição
O termo REST significa "Transferência de Estado de representação." A
definição formal possível de que poderia ser como segue.
estilo API arquitetônico baseado em transferência de uma representação do
estado (documentos) entre cliente e servidor, a fim de avançar o estado de um
aplicativo.
Restrições
Para considerar os pedidos como RESTful, os aplicativos precisam estar em
conformidade com as seguintes restrições REST. Cumprindo com as restrições
permite que um sistema hipermídia distribuído para ter as seguintes
propriedades desejáveis não-funcionais: desempenho, escalabilidade,
simplicidade, extensibilidade, visibilidade, portabilidade e confiabilidade.
Servidor cliente
Um modelo cliente-servidor favorece a separação de interesses para que os
clientes não estão preocupados com o armazenamento de dados. Assim, a
portabilidade de código clientes é melhorada. Por outro lado, o servidor não
está preocupado com a interface de utilizador ou estado do utilizador, para que
o servidor possa ser mais simples e mais escalável. Servidores e clientes
podem ser desenvolvidos de forma independente, desde que estejam em
conformidade com o contrato definido.
Stateless
contexto de cliente nunca é armazenado no servidor entre as solicitações.
Cada pedido tem de conter todas as informações necessárias. Um servidor
sem estado melhora a escalabilidade, permitindo que o servidor para recursos
rapidamente livres e simplifica a implementação. Confiabilidade facilita a
recuperação de falhas parciais. Visibilidade, sistema de monitorização não tem
que olhar para além de um único pedido para determinar a natureza do pedido.

Uma das desvantagens de ter um servidor é diminuída sem estado de
desempenho da rede, como todos os dados necessários tem de ser enviado
em cada pedido.
Interface uniforme
Usando uma interface uniforme simplifica e desacopla a arquitetura e favorece
a evolução independente de partes diferentes. Como explicado mais adiante
neste post, URIs, recursos e ajuda hipermídia para produzir uma interface
padrão que melhora a visibilidade das interações, simplifica a arquitetura geral
do sistema e incentivar a evolução independente. O trade-off é que ele degrada
a eficiência já que a informação é transferida em um formato padrão, em vez
de um que é especial às necessidades de um aplicativo.
Sistema de camadas
Usando um sistema em camadas reduz a complexidade, restringir o seu
comportamento componente de tal forma que cada elemento não pode acessar
além de sua camada de imediato. Favorece a independência substrato,
restringindo o conhecimento de outras partes do sistema. As camadas podem
encapsular componentes legados e proteger novos serviços de clientes
legados. Intermediários podem ser usados para melhorar a escalabilidade,
permitindo que o balanceamento de carga através das redes. A principal
desvantagem é que os sistemas em camadas adicionar uma sobrecarga e
latência para o processamento de dados, portanto, reduzindo o desempenho
percebido pelo usuário.
Code-On-Demand (Opcional)
REST permite que os clientes para estender sua funcionalidade fazendo o
download e execução de scripts de código. Isto simplifica e melhora a
extensibilidade clientes. Por outro lado, reduz a visibilidade, o que é por isso
que ele é apenas uma restrição opcional.
elementos
DESCANSO tem vários elementos na sua caixa de ferramentas para construir
apátridas, escaláveis e simples APIs web.
HTTP
- recursos
- URIs
- hipermídia
- HTTP - Documento de Protocolo de Transferência de Aplicação
- REST é normalmente usado junto com HTTP como seu protocolo de
transferência, uma vez que oferece várias vantagens. Entre eles estão os
verbos de HTTP, códigos de status e cabeçalhos.
Verbos

Em vez de definir novos verbos para cada comportamento possível em nosso
serviço web, o HTTP introduz um conjunto padrão de verbos para lidar com
situações semelhantes, da mesma forma, a remoção de variação
desnecessária e criando uma API mais intuitiva. Cada verbo tem uma
combinação diferente de duas propriedades que as tornam adequadas para
diferentes cenários.
Idempotente: A operação pode ser repetida em caso de falhas.
Seguro: A operação não tem efeitos colaterais para o qual o cliente é
responsável.
GET
Usado para ler o estado do servidor. Sendo uma operação segura, ele pode
ser executado várias vezes, sem risco de modificação de dados ou corrupção -
chamando-o de uma vez tem o mesmo efeito que chamá-lo dez vezes. Como
uma operação idempotente,
fazendo vários pedidos idênticos tem o mesmo resultado como um único
pedido.
POST
Normalmente usado para criar algum estado no servidor. É seguro nem
idempotente. Portanto várias solicitações irá criar vários recursos no servidor.
Como uma operação não-idempotent, POST não deve ser utilizado para
operações que lidam com dinheiro,
como no caso de um pedido não é feito várias vezes, que poderia
potencialmente ser a transferência de dinheiro ou pagar várias vezes.
PUT
É principalmente utilizado para atualizar estado no servidor, embora também
possa ser utilizado para criar estado. É idempotent mas não segura como ela
muda o estado do servidor.
Sendo um idempotent fez colocar um bom candidato, por exemplo, para as
operações relacionadas com dinheiro.
DELETE
É usado para eliminar estado no servidor. É idempotent mas não seguro, uma
vez que remove o estado do servidor. É idempotentes como apagar estado que
foi excluído anteriormente não deve ter outras implicações.
RESPONSE STATUS CODE
Os códigos de estado de HTTP fornecer metadados na resposta ao estado
dos recursos solicitados. Eles são parte do que torna a web uma plataforma
para a construção de sistemas distribuídos.
Eles estão divididos nas seguintes categorias:

1xx - Metadados.
2xx - Está tudo bem.
3xx - Redirecionamento.
4xx - Cliente fez algo errado.
5xx - Servidor fez algo errado.
HEADER
Os cabeçalhos HTTP são componentes para passar informações adicionais
em pedidos e respostas. Cabeçalhos consistem de um nome de maiúsculas e
minúsculas seguido por dois pontos e seu valor. Cabeçalhos poderiam ser
agrupadas como: cabeçalhos gerais: aplicam-se tanto solicitações e respostas,
mas não há relação aos dados transmitidos no corpo. Cabeçalhos de
solicitação: contêm mais informações sobre o recurso a ser obtido ou sobre o
cliente que fez o pedido. cabeçalhos de resposta: contêm informações
adicionais sobre a resposta. cabeçalhos de entidade: Adicionar informações
sobre o corpo da entidade, como o índice de comprimento ou do tipo MIME.
RestFul - Part 2
Restful – Part 2
Recursos
Um recurso é nada exposta pelo sistema que tem uma identidade.
Recursos oferecem uma maneira de adaptar o domínio de aplicação aos
clientes web. Uma imagem, uma planilha, um serviço ou uma coleção de outros
recursos são alguns exemplos de recursos. Os recursos são obtidos ou enviar
usando uma certa representação (XML, JSON, etc.). Nós lidamos com
representações de recursos, e não com os próprios recursos, seguindo a ideia
de "Pass-by-value". Após a definição REST anterior, os recursos representam
os documentos que estão sendo transferidos através da rede para começar o
trabalho feito. estado de recursos é uma preocupação do lado do servidor, uma
vez que representa o estado de domínio, clientes só buscar ou enviar
representações de recursos para o progresso do estado do aplicativo. Por outro
lado, o estado da aplicação é uma preocupação do lado do cliente, uma vez
que representa o progresso para um objectivo particular aplicação. Os recursos
devem ser nomeados como substantivos, pois representam conceitos no
domínio de um sistema particular e são identificados usando URIs.
URIs (Uniform Resource Identifier)
URIs diferenciar um recurso de outro. Para acessar e manipular um recurso,
ele precisa ter pelo menos um endereço. Eles são compostos por uma série
protocolo + + caminho. Os clientes não devem ser acoplados a URIs
específicos de recursos como eles podem ser alterados a critério do servidor.
Este é o lugar onde hipermídia tem as maiores vantagens, uma vez que
oferece uma maneira de separar clientes de URIs específicos e adicionar
semântica para o protocolo de aplicação.

Hipermídia
Hipermídia informa o cliente sobre o que ele pode fazer em seguida, através do
uso de controles de hipermídia (links e formas) nas respostas, eo URI
específica para fazê-lo. O formato hipermídia concreto para uma determinada
aplicação é definida no tipo de aplicativo Media. elos hipermídia são compostas
por um atributo href que especifica o URI para acessar o recurso vinculado e
um atributo rel que define o significado da relação, portanto, acrescentando
semântica para as transições de estado na aplicação. O uso de links permite
que o servidor para anunciar novos recursos, incluindo novas ligações nas
respostas sem quebrar os clientes existentes. Enquanto o servidor manter
ligações previamente definidas nas respostas, os clientes seriam capazes de
segui-los assim como eles eram antes do novo estado foi adicionado. Os
clientes que só necessitam de ser atualizadas se eles precisam acessar o novo
estado. Outra vantagem hipermídia é que ele introduz descoberta, fornecendo
uma maneira de fazer um protocolo de descoberta e autodocumentado.
Os clientes começam a interagir com o aplicativo por meio de uma URL fixa, e
a partir daí todas as outras ações acontecem pelo cliente seguindo os links ,
formatado com o tipo de mídia e fornecido pelo servidor em cada resposta.
tipos de mídia e links definir o contrato entre o servidor de aplicativos eo
cliente. O cliente interage com o sistema , navegando o estado do aplicativo
utilizando as ligações . Isto é o que HATEOAS ( Hipermídia como motor do
estado do aplicativo ) realmente significa.
Hipermedia ( para além dos elementos já definidos ) é o que significa REST
realmente .
Abaixo um exemplo de um requisição Rest para retornar uma validação Aoath
do salesforce:
<?xml version="1.0" encoding="UTF-8"?>
<mule xmlns:http="http://www.mulesoft.org/schema/mule/http"
xmlns:tracking="http://www.mulesoft.org/schema/mule/ee/tracking"
xmlns="http://www.mulesoft.org/schema/mule/core"
xmlns:doc="http://www.mulesoft.org/schema/mule/documentation"
xmlns:spring="http://www.springframework.org/schema/beans"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xsi:schemaLocation="http://www.mulesoft.org/schema/mule/http
http://www.mulesoft.org/schema/mule/http/current/mule-http.xsd
http://www.springframework.org/schema/beans
http://www.springframework.org/schema/beans/spring-beans-current.xsd
http://www.mulesoft.org/schema/mule/core
http://www.mulesoft.org/schema/mule/core/current/mule.xsd
http://www.mulesoft.org/schema/mule/ee/tracking
http://www.mulesoft.org/schema/mule/ee/tracking/current/mule-tracking-
ee.xsd">
<sub-flow name="getAuthorizationToken">

<http:request config-ref="HTTP_Request_Configuration"
path="/services/oauth2/token" method="POST"
doc:name="RequestAuthorization">
<http:request-builder>
<http:query-param paramName="grant_type" value="password"/>
<http:query-param paramName="client_id"
value="3MVG9Nc1qcZ7BbZ0.lrUdTc6imEmpmeMblw6fJZ_TySlFWN3AFZ.Wbr
e4W01j_RkzLlqlGTqjRZLwMuMOL.qZ"/>
<http:query-param paramName="client_secret"
value="7205123458111539520"/>
<http:query-param paramName="username"
value="teste@teste.com.br"/>
<http:query-param paramName="password" value="Salesforce2!"/>
</http:request-builder>
<http:success-status-code-validator values="0..599"/>
</http:request>
<set-payload value="#[json:access_token]"
doc:name="extractTokenFromResponse"/>
</sub-flow>
<flow name="executeWaveQuery" processingStrategy="synchronous">
<enricher target="#[flowVars.authorizationToken]" doc:name="Message
Enricher">
<processor-chain doc:name="Processor Chain">
<flow-ref name="getAuthorizationToken"
doc:name="getAuthorizationToken"/>
</processor-chain>
</enricher>
<http:request config-ref="HTTP_Request_Unilever"
path="/services/data/v36.0/wave/query" method="POST"
doc:name="QueryWave">
<http:request-builder>
<http:header headerName="Authorization" value="OAuth
#[flowVars.authorizationToken]"/>
<http:header headerName="Content-Type" value="application/json"/>
</http:request-builder>
</http:request>
<logger level="INFO" doc:name="Logger"/>
</flow>
<flow name="getSalesChannel" processingStrategy="synchronous">
<set-payload value="${query.get_sales_channel}"
doc:name="setQueryGetSalesChannel"/>
<flow-ref name="executeWaveQuery" doc:name="executeWaveQuery"/>
<logger message="#[message.payloadAs(java.lang.String)]" level="INFO"
doc:name="Logger"/>
</flow>
<flow name="getImpactedStore" processingStrategy="synchronous">

<set-payload value="${query.get_impacted_store}"
doc:name="setQueryGetImpactedStore"/>
<logger level="INFO" doc:name="Get Impacted Store SAQL"/>
</flow>
<flow name="getECOTarget" processingStrategy="synchronous">
<set-payload value="${query.get_eco}"
doc:name="setQueryGetOrderInvoiceECO"/>
<logger message="SAQL ------->
#[message.payloadAs(java.lang.String)]" level="INFO" doc:name="Get ECO
SAQL"/>
</flow>
<flow name="get_orderInvoice_dataSet">
<set-payload value="${query.purge_orderInvoice}" doc:name="Set
Payload"/>
<logger message="SAQL ------->
#[message.payloadAs(java.lang.String)]" level="INFO" doc:name="Logger"/>
<flow-ref name="dms_purge_orderInvoice_Flow"
doc:name="dms_purge_orderInvoice_Flow"/>
</flow>
</mule>
Integração Salesforce com Mulesoft usando o Salesforce Conector
Este post irá explorar como a integração com o Salesforce usando o conector
Salesforce MuleSoft.
Setup / Instalação - Supondo que você tenha conhecimento de conectores
MuleSoft e estúdio AnyPoint, eu vou dar os passos para a instalação do
conector Salesforce.
Neste how-to, usamos:
AnyPoint Studio - 5.4.2 com Mule ESB Runtime 3.7.3
conta de desenvolvedor Salesforce - Assine um no Salesforce. Em seguida,
obter a sua segurança seguindo estes passos: Entre para força de vendas, em
seguida, clique em Configurar> Minhas informações pessoais> Redefinir Token
de Segurança. Em seguida, clique em Redefinir meu Token de Segurança
Maven - versão 3.x.x
Passo 1: Faça o download e instale o mais recente conector de encaixe
Salesforce.
Abrir AnyPoint Estúdio menu do botão Ajuda> Instalar Novo Software
No trabalho com: selecione o site de atualização do conector AnyPoint.

Selecione a versão mais recente Salesforce. A versão atual é 7.0.1
Passo 2: Namespace e SchemaLocation
<mule xmlns="http://www.mulesoft.org/schema/mule/core"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xmlns:sfdc="http://www.mulesoft.org/schema/mule/sfdc"
xsi:schemaLocation="
http://www.mulesoft.org/schema/mule/core
http://www.mulesoft.org/schema/mule/core/current/mule.xsd
http://www.mulesoft.org/schema/mule/sfdc
http://www.mulesoft.org/schema/mule/sfdc/current/mule-sfdc.xsd">

</mule>
Passo 3: Maven Dependencies
1. Adicionar à pom.xml file.
<repositories>
<repository>
<id>mule-ee-releases</id>
<name>MuleEE Releases Repository</name>
<url>https://repository-master.mulesoft.org/nexus/content/repositories/rele
ases-ee/</url>
<repository>
<id>mule-ee-snapshots</id>
<name>MuleEE Snapshots Repository</name>

<url>https://repository-master.mulesoft.org/nexus/content/repositories/ci-sn
apshots/</url>
</repository>
</repositories>
2. Adicionar o modulo como uma dependência.
<dependency>
<groupId>org.mule.modules</groupId>
<artifactId>mule-module-sfdc</artifactId>
<version>RELEASE</version>
</dependency>
3. Incluir no packaging process.
<plugin>
<groupId>org.mule.tools.maven</groupId>
<artifactId>mule-app-maven-plugin</artifactId>
<version>${mule.tools.version}</version>
<extensions>true</extensions>
<configuration>
<copyToAppsDirectory>true</copyToAppsDirectory>
<applications>
<application>src/main/app/subfolder/</application>
</applications>
<inclusions>
<inclusion>
<artifactId>mule-module-sfdc</artifactId>
</inclusion>
<inclusion>
<artifactId>mule-module-objectstore</artifactId>
</inclusion>
</inclusions>
</configuration>
</plugin>

Agora que terminar de instalar o conector de força de vendas em MuleSoft
AnyPoint Studio, podemos
avançar para as próximas etapas , criando fluxos de integração.
Integração segurança
A segurança é um requisito básico para todas as aplicações empresariais ,
impede o acesso não autorizado , uso e destruição de recursos e informações
sensíveis.
Parte I: Conectar-se a Salesforce com autenticação básica .
Nosso principal objetivo é conectar com Salesforce usando autenticação
básica.
1. Criar um fluxo simples com ouvinte HTTP, em seguida, chamar timestamp
servidor Salesforce.
How do you use Gist in
DZone?? https://gist.github.com/vinzonwsl/aebe066593bf00ff378a
2. Configure Salesforce connector com basic authentication. fornecendo
O username, password, and security token. O security token é enviado por
email quando, você clica em reset security token na sua conta de developer
Salesforce.

3 Após a validação bem sucedida da configuração , avance para testar o
aplicativo invocando o endpoint
HTTP utilizando carteiro ou qualquer cliente que você está acostumado , como
SoapUI ou browsers simples.
Como resultado , podemos ver uma integração simples entre MuleSoft e
Salesforce com autenticação básica . Na segunda parte , vamos ter o mesmo
fluxo , usando a autorização OAuth 2.0 JWT portador .
Usando seu codigo Java no Mule - Part 1
Mule oferece um conjunto incrível de ferramentas prontas para usar que torna a
sua experiência no desenvolvimento de tão suave quanto possível. Enquanto
na maioria dos cenários, você terá mais do que suficiente, o que acontece se
você precisa dar um passo específico e você quiser personalizá-lo? Sou capaz
de adicionar o meu próprio código Java em meu fluxo mule? Enquanto ele é
altamente recomendável usar os componentes fornecidos pelo Mule
(componentes já testados), você é livre para incorporar suas operações Java /
POJOs / bibliotecas em mule! Abaixo descrevo uma lista de abordagens que eu

espero responder a maioria das suas perguntas! Para estes exemplos que
vamos usar uma classe POJO "Animal”.
public class Animal {
private String name;
public Animal(){
name="maxMule";
}
public Animal(String name){
this.name=name;
}
public String getName() {
return name;
}
public void setName(String name) {
this.name = name;

}
@Override
public String toString() {
return "Animal [name=" + name + "]";
}
}
Implementing Callable Interface
Uma abordagem comum é fazer com que a nossa classe Java implementa a
interface org.mule.api.lifecycle.Callable . Nós apenas precisamos de substituir
as OnCall método que recebe como parâmetro o MuleEventContext . Usando
thisMuleEventContext objeto podemos acessar os nossos componentes de
mula . Por exemplo, " eventContext.getMessage ()" irá retornar a mensagem da
aplicação Mule .
No exemplo abaixo, estamos adicionando uma nova propriedade de sessão e
retornar um objeto "Animal" no Payload :
public class OnCallClass implements Callable {
@Override
public Object onCall(MuleEventContext eventContext) throws Exception {
eventContext.getMessage().setProperty("surname", "Martinez",PropertySco
System.out.println("Session Variable updated n");
System.out.println("Returning Animal Object in the payload");

return new Animal();
}
}
view rawOnCallClass.java hosted with by GitHub
Agora vamos usar o <component class=””> para chamar nossa nova class no
mule app:
<flow name="usingCallable">
<http:listener config-
ref="HTTP_Listener_Configuration" path="/onCall"doc:name="HTTP" allowedMethods="GE
<component class="javacall.OnCallClass" doc:name="Java" />
<object-to-string-transformer doc:name="Object to String" />
</flow>
Usando uma Custom Message Processor
Podemos descrever um aplicativo Mule como uma mensagem de Mula,
desencadeada por qualquer forma, que passa por diferentes processadores
(passos).
A segunda abordagem define uma dessas etapas usando Java!
A nossa nova classe deve implementar
org.mule.api.processor.MessageProcessor . Essa classe tem o processo de
operação que recebe o MuleEvent semelhante à nossa primeira abordagem .
No exemplo abaixo , vamos receber este evento, definir uma carga diferente e
retornar o evento com o nosso novo Payload .
public class MessageProcessorCall implements MessageProcessor{
@Override
public MuleEvent process(MuleEvent event) throws MuleException {
System.out.println("n-------Process Executing, updating payload-------");
event.getMessage().setPayload("Payload Modified from Message processor

System.out.println("n-------Process executed, payload updated-------");
return event;
}
}
Agora, vamos adicionar no nosso mule app usando <custom-processor
class=””> component:
<flow name="usingCustomMessageProcessor">
ref="HTTP_Listener_Configuration" path="/customMessage"doc:name="HTTP" allowedMet
<custom-processor class="javacall.MessageProcessorCall" doc:name="Custom Process
<object-to-string-transformer doc:name="Object to String"/>
</flow>
Usando seu codigo Java no mule - Part 2
Message Transformer
Vamos configurar a nossa classe de transformação que irá devolver o POJO
"Animal" . Neste caso , temos que se estendem "
org.mule.transformer.AbstractMessageTransformer " , utilizando a operação
transformMessage que recebe o MuleMessage como um parâmetro .
No exemplo abaixo temos o nome de uma variável de fluxo e retornar um novo
animal com este nome :
public class AnimalTransformer extends AbstractMessageTransformer{
public Object transformMessage(MuleMessage message, String outputEncoding) throws
String flowVarName = message.getProperty("flowVarName", PropertyScope.INVOC
Animal animal=new Animal(flowVarName);

return animal;
}
}
Vamos fazê-lo funcionar ! usando o <custom-transformer> nos podemos
especificar quais tipos de objetos que irá receber e a classe que irá lidar com a
transformação.
<flow name="usingTransformer">
ref="HTTP_Listener_Configuration" path="/transformer"allowedMethods="GET" doc:name=
<set-variable variableName="flowVarName" value="#['Max the Mule']" doc:name="Variab
<custom-
transformer returnClass="model.Animal" class="javacall.AnimalTransformer"doc:name="Ja
</flow>
Transforming via Annotation
Temos a opção de usar Anotações ao implementar nossa solução de
transformação. Para atingir este objetivo , primeiro anotar a classe com
@ContainsTransformerMethods ( "
org.mule.api.annotations.ContainsTransformerMethods ") que marca a classe
como um recipiente de um transformador Mule . O método deve ser anotado
com @Transformer ( " org.mule.api.annotations.Transformer " ) , o que significa
que serão disponibilizados na mula Container.
No exemplo abaixo , estamos usando o @Payload anotação ( "
org.mule.api.annotations.param.Payload " ) para injetar nossa carga útil em
nosso parâmetro String nome e devolver um animal com este nome.
@ContainsTransformerMethods
public class AnimalTransformerAnnotation {

@Transformer
public Animal returnAnimal(@Payload String name){
return new Animal(name);
}
}
Nosso teste do fluxo Mule:
<flow name="usingTransformerAnnotation">
ref="HTTP_Listener_Configuration" path="/transformerAnnotation"doc:name="HTTP" allowedMethods="GET"/
<set-payload value="#['Annotated Max!']" doc:name="Set Payload"/>
<component class="javacall.AnimalTransformerAnnotation" doc:name="Java"/>
</flow>
Importando livrarias Java no Dataweave e MEL
Por último, mas não menos importante, vamos definir uma função global que
importa diferentes bibliotecas e pode ser usado via DataWeave , isso não é
legal!
Primeiro de tudo, precisamos definir nossa função global. Neste exemplo ,
vamos calcular o número de dias de um mês previsto como um parâmetro.
Vamos fazer uso do Calendário e SimpleDateFormat bibliotecas.
<configuration doc:name="Configuration">
<expression-language>
<global-functions>
def dayOfTheMonth(date){

import java.util.Calendar;
import java.text.SimpleDateFormat;
cal = Calendar.getInstance();
sdf = new SimpleDateFormat('yyyyMMdd');
cal.setTime(sdf.parse(date));
return cal.getActualMaximum(Calendar.DAY_OF_MONTH).toString();
}
</global-functions>
</expression-language>
</configuration>
Nossa nova função está pronto para ser usado! Podemos agora usar uma
expressão MEL ou incluir nossa função no Dataweave !
MEL: #[dayOfTheMonth(‘20151027’)]
DataWeave: day: dayOfTheMonth(‘20140302’)
Espero que estas várias opções de ajudar a melhorar a sua flexibilidade
durante a utilização da mula!

Compilação de tutoriais blog MulePE

Mais conteúdo relacionado

Mais procurados

Semelhante a Compilação de tutoriais blog MulePE

Mais de Jeison Barros

Compilação de tutoriais blog MulePE