Problemas ao consumir serviços JaxWs, WSDL

1 de abril de 2013 3 respostas

dudu795 1 de abril de 2013

Boa tarde pessoal,

Há dias que estamos com um problema na empresa, está sendo tentado consumir um serviço, sem sucesso, o mesmo lança uma exceção dizendo que os parâmetros passados estão diferentes do esperado, mas conferindo, a sequencia está correta, o erro abaixo é o retornado quando invoco o serviço:

<soap:Envelope xmlns:soap="http://schemas.xmlsoap.org/soap/envelope/">
   <soap:Body>
      <soap:Fault>
         <faultcode>soap:Client</faultcode>
         <faultstring><![CDATA[Unmarshalling Error: unexpected element (uri:"http://v1.order.erp.canonical.test.com.br", local:"destinationState"). Expected elements are <{}destinationState>,<{}originState>,<{}taxableOperation>,<{}product>,<{}specialMeasuresTo>,<{}CFOP>,<{}taxRulesFrom>,<{}specialMeasuresFrom>,<{}originSector>,<{}destinationSector>,<{}taxRulesTo>,<{}targetSessions>,<{}goodsSource>]]></faultstring>
      </soap:Fault>
   </soap:Body>
</soap:Envelope>

a sequencia que a mensagem diz estar errada, está correta conforme o envelope que está sendo tentado enviar, que é este:

<soapenv:Envelope xmlns:soapenv="http://schemas.xmlsoap.org/soap/envelope/"
	xmlns:v1="http://v1.order.erp.canonical.test.com.br">
	<soapenv:Header />
	<soapenv:Body>
		<v1:sendTax>
			<!--Optional: -->
			<v1:fiscalScenarioSummary>
				<v1:destinationState>ES</v1:destinationState>
				<v1:originState>ES</v1:originState>
				<v1:taxableOperation>96</v1:taxableOperation>
				<v1:product>
					<v1:internalCode>20029555</v1:internalCode>
					<v1:barCode />
					<v1:description>VI.MARCUS JAMES TANNAT 750ML</v1:description>
					<v1:NCM>22042100</v1:NCM>
					<v1:EXTIPI />
					<v1:ICMS>
						<v1:CST>00</v1:CST>
						<v1:taxRate>27.00</v1:taxRate>
						<v1:commencementDate>2002-12-01-02:00</v1:commencementDate>
						<v1:expiryDate>2999-12-31-02:00</v1:expiryDate>
						<v1:legalProvision>Art. 63, I e §1º do RICMS/ES . Art. 71 , IV,
							"d", e art. 71-A do RICMS/ES</v1:legalProvision>
						<v1:observations>Inexistente</v1:observations>
						<v1:additionalInformation>Inexistente</v1:additionalInformation>
					</v1:ICMS>
				</v1:product>
				<v1:specialMeasuresTo />
				<v1:CFOP>6401</v1:CFOP>
				<v1:taxRulesFrom>Lucro Real</v1:taxRulesFrom>
				<v1:specialMeasuresFrom />
				<v1:originSector>1</v1:originSector>
				<v1:destinationSector>1</v1:destinationSector>
				<v1:taxRulesTo>Inexistente</v1:taxRulesTo>
				<v1:targetSessions>
					<v1:customerId>1</v1:customerId>
				</v1:targetSessions>
				<v1:goodsSource />

			</v1:fiscalScenarioSummary>
		</v1:sendTax>
	</soapenv:Body>
</soapenv:Envelope>

o que pode estar ocasionando esta exceção?

3 Respostas

Alexandre_Saudate 1 de abr. de 2013

Observe a mensagem:

O que acontece é que existem maneiras de definir o XML Schema do serviço como qualificado ou não qualificado. Quando você decide que o schema é qualificado, você deve mandar os elementos com os prefixos, da maneira como você fez:

<v1:destinationState>ES</v1:destinationState>

No entanto, se o schema for não qualificado, você deve retirar os prefixos:

<destinationState>ES</destinationState>

Para checar isso, basta ir no XML Schema que define a mensagem e localizar o atributo elementFormDefault.

[]'s

dudu795 3 de abr. de 2013

Isto mesmo Alexandre, a questão era bem essa, sobre os tipos qualificados e não qualificados. (Comprei seu livro sobre SOA, ainda não chegou, enquanto isto tenho que tirar as dúvidas por aqui heheh) Foi resolvido o problema mas na minha opinião não da melhor maneira possível, no que diz respeito aos tipos qualificados, pois o envelope criado para consumir meu serviço era qualificado e o meu serviço não era qualificado i[/i], ai está a divergência, na minha opinião, quem quiser consumir um serviço, tem que se adaptar a ele, e não o serviço se adaptar ao consumidor, mas como a ordem veio de cima, tive que alterar o meu serviço para se adaptar ao envelope destinado a meu serviço, com base em sistemas orientados a serviço você concorda minha opinião?

Sobre a qualificação de serviços, eu defino um namespace, este namespace geralmente é uma URL, no nosso exemplo http://canonical.emp.com.br/financials/v1, me corrija se estiver errado, esta namespace pode ser qualquer texto, não necessariamente um link? por exemplo, poderia anotar um atributos de uma classe com um namespace qualquer como no exemplo abaixo “qualquerTexto”, que funcionaria sem problemas?

outra dúvida sobre tipos qualificados, quais são os prós e os contras de ser ter serviço com tipos qualificados ou não qualificados?

Alexandre_Saudate 3 de abr. de 2013

dudu795:
Isto mesmo Alexandre, a questão era bem essa, sobre os tipos qualificados e não qualificados. (Comprei seu livro sobre SOA, ainda não chegou, enquanto isto tenho que tirar as dúvidas por aqui heheh) Foi resolvido o problema mas na minha opinião não da melhor maneira possível, no que diz respeito aos tipos qualificados, pois o envelope criado para consumir meu serviço era qualificado e o meu serviço não era qualificado i[/i], ai está a divergência, na minha opinião, quem quiser consumir um serviço, tem que se adaptar a ele, e não o serviço se adaptar ao consumidor, mas como a ordem veio de cima, tive que alterar o meu serviço para se adaptar ao envelope destinado a meu serviço, com base em sistemas orientados a serviço você concorda minha opinião?

Então… na verdade, não concordo. SOA, como um todo, é orientado ao cliente (ou seja, você adapta os serviços da maneira que seja mais flexível pro seu cliente), o que acaba promovendo as técnicas de contract-first e modelo canônico (para citar duas).

Além disso, é sempre preferível que seus contratos sejam qualificados, já que você teria problemas, por exemplo, para referenciar elementos com o namespace padrão (sem prefixo).

dudu795:

Sobre a qualificação de serviços, eu defino um namespace, este namespace geralmente é uma URL, no nosso exemplo http://canonical.emp.com.br/financials/v1, me corrija se estiver errado, esta namespace pode ser qualquer texto, não necessariamente um link? por exemplo, poderia anotar um atributos de uma classe com um namespace qualquer como no exemplo abaixo “qualquerTexto”, que funcionaria sem problemas?

Exatamente, o namespace pode ser qualquer coisa (respeitadas as regras de definições de URI’s, que são mais abrangentes que URL’s). No entanto, é uma prática comum de mercado utilizar os namespaces dessa forma que você citou. É mais “elegante”.

dudu795:

outra dúvida sobre tipos qualificados, quais são os prós e os contras de ser ter serviço com tipos qualificados ou não qualificados?

Pró tipos qualificados: você tem menos problemas para referenciar outros namespaces (por exemplo, um namespace definido sem prefixo). Elimina ambiguidades.
Contra tipo qualificado: o XML fica menos legível e com mais caracteres.

Prós e contras dos tipos não qualificados: o oposto do acima

[]'s

Criado 1 de abril de 2013

Ultima resposta 3 de abr. de 2013

Respostas 3

Participantes 2

3 Respostas

Topicos relacionados