Arquivo da tag: SOA

soapUI (ou xml string): como enviar valor nulo?

Acrescente no seu cabeçalho:

xmlns:xsi=”http://www.w3.org/2001/XMLSchema-instance” xmlns:xsd=”http://www.w3.org/2001/XMLSchema”

e na sua tag:

xsi:nil=”true”

E está prontim prontim.

<soapenv:Envelope xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xmlns:xsd="http://www.w3.org/2001/XMLSchema" xmlns:soapenv="http://schemas.xmlsoap.org/soap/envelope/" xmlns:tem="http://tempuri.org/" xmlns:privado="http://schemas.datacontract.org/2004/07/PRIVADA">
   <soapenv:Header xsi:nil="true"/>
   <soapenv:Body>
      <tem:Churros>
         <tem:Recheio>
            <privado:Cor xsi:nil="true"/>
         </tem:Recheio>
      </tem:Churros>
   </soapenv:Body>
</soapenv:Envelope>

WCF – Propriedade Specified e serialização

Eu não sou expert em WCF, mas já mexi até que bastante com ele.
Tem uns negocio de serialização dele que se você deixar default o capeta incorpora e você perde o controle.

Eu utilizo o DataContract nos contratos dos serviços para a serialização por simplesmente a lista de tipos suportados ser maior que a do XmlSerializerFormat.

Aí o problema (?) que eu sempre tenho consumindo o serviço de terceiros é: eu adiciono a service reference e vem aqueles mil campos specified para eu setar se eu alterei uma propriedade ou não. Desagradável demais.
Isso acontece porque tem alguns tipos de dados que tem o valor default e coisa e tal, daí para a serialização saber que não é um valor default e que foi setado, é baseado nessa propriedade specified. Corrijam-me se eu estiver falando caquinha.
Setando o DataMember como IsRequired obrigatoriamente o valor sempre tem que vir, então não tem mais a opção de não ter valor setado e o specified morre. Não vejo nenhum problema, inicialmente, em utiliza-lo já que você ainda pode usar o System.Nullable.

[DataContract]
public class Cachorro
{
	[DataMember]
	public string Nome { get; set; }
 
	[DataMember(IsRequired = true)]
	public int? QuantidadeDeFilhotes { get; set; }
}

Usem-o! E facilite a vida do carinha que tá integrando no seu bendito serviço!

AutoMapper – mapeamento chato de objetos

Sabe quando voce tem aquelas quase replicas de classes? Aquele contratinho semi igual a uma classe sua de dominio? Nao deixe de cria-lo por preguica de mapea-los, expor seu objeto de negocio é coisa do capeta.

Ou quando temos um objeto de um legado que muda apenas uma propriedade. Olha esse codigo:

public class ClasseVelha
{
	public decimal Valor { get; set; }
}
 
public class ClasseJuvenil
{
	public int Id { get; set; }
	public decimal Valor { get; set; }
}
 
public ClasseJuvenil Mapear(ClasseVelha velhaco)
{
	AutoMapper.CreateMap<ClasseVelha, ClasseJuvenil>()
			.ForMember(dest => dest.Id, opt => opt.Ignore());
 
	return Mapper.Map<ClasseVelha, ClasseJuvenil>(velhaco);
}

Obs. O codigo acima foi criado no notepad++ e pode conter erros, rs.

O AutoMapper faz todo o trabalho sujo pra gente, e ainda com essa sintaxe lindona. Tem bastante exemplo no GitHub.

Sejam felizes! 🙂

Consumindo webservice com basic autenthication – WCF

Nunca tinha feito isso na minha vida, WCF tem mais configuração do que há dados no Google, potaqueparola.
Estou consumindo um webservice externo onde foi descrito que precisavamos enviar a cada chamada o header de autenticação básica com usuario e senha em Base 64, e esses dados deveriam ser concatenados separados por :.
Ou seja:

Usuario: teste
Senha: 123123

Concatenado: teste:123123
Criptografado: dGVzdGU6MTIzMTIz (by http://ostermiller.org/calc/encode.html)

E o header: Authorization: Basic dGVzdGU6MTIzMTIz

Acontece que isso é autenticação padrão em serviços, ou sejammmm, para usar isso no WCF precisamos apenas configurar o binding do client para o modo de segurança necessaria (varia de acordo com o serviço, claro), no meu caso , Transport e o tipo de credencial básica (Basic authentication, hãm hãm):

<basicHttpBinding>
	<binding name="meuBindingLindao">
	  <security mode="Transport">
		<transport clientCredentialType="Basic" />
	  </security>
	</binding>
</basicHttpBinding>

E setar o usuario e senha na chamada:

WebServiceClient cliente= new WebServiceClient();
cliente.ClientCredentials.UserName.UserName = "usuario";
cliente.ClientCredentials.UserName.Password = "senha";

Mais moleza que isso só .. sei la. Away!

SOA: Second firsts steps ..

Hahaha second firts steps porque já fiz bastante coisa em SOA, mas sou juvenil, sabe quando você nao ENTENDE de verdade o motivo de toda aquela abstração, interfaces e códigos desacoplados bagarai?

Dessa vez eu startei um projeto, no trampo mesmo (meu trampo agora é lindeza! um dia falo sobre ..), que é um refactor de um projeto que fazia consultas em N serviços terceiros e deveria ter possibilidade de integrar mais e mais, e escalar, e ser robusto (isso eu ainda nao entendo, rs), enfim .. projeto de grande porte, que depende de muita coisa que não temos acesso irrestrito, que fosse muito performatico e bem rastreavel. Resolvemos entao modularizar em serviços!

E vou falar uma coisa meio porca, pra definir como funciona a arquitetura de serviço para o pessoal do .NET eu tenho usado o “é um macro da separação de responsabilidade que você faz em class librarys na sua solution” .. e ao meu ver, não é nada mais que isso mesmo (se você fizer direito, claro!).

Interfaces, para não termos contato direto com os serviços: manutenibilidade moleza. Como se comunicam via algum protocolo, podem estar em maquinas diferentes ou em N maquinas o que da uma escalabilidade horizontal motherfucker além da possibilidade de colocar os serviços mais trashs em lugares mais parrudos ou em mais lugares, fazer um load balance, quem sabe. Enfim .. desacoplamento é uma coisa linda, todos deveriam experimentar!

SOA é conteúdo pra caralho! Mas eu queria dar essa review rápida .. mudou minha pog-life. 🙂