Hi,
The Lucee extension Axis 1 Webservices 1.4.0.27-RC is installed and I tried differents versions too.
I have a Service written in Java from a payment processor company that listen on a port on localhost. In Lucee, I call a method of the webservice like this :
<cfset ws = createObject("webservice", ARGUMENTS.WebServiceURL)>
<cfset ws.purchase(structPurchaseInput)>
structPurchaseInput is a simple structure with simple values in it.
I get the error Invalid formated request
My assumption is that my service is not compatible with Lucee. Maybe the java version or the way the data are returned by the service, etc…
Any idea of the origin of this error? I want to make sure it is not a bug from the extension or from Lucee.
Thank you!
I had look at the error logs of the service I try to use :
ERROR: ‘Namespace for prefix ‘xsi’ has not been declared.’
and
java.lang.RuntimeException: Namespace for prefix ‘xsi’ has not been declared.
at com.sun.org.apache.xml.internal.serializer.SerializerBase.getNamespaceURI(Unknown Source)
at com.sun.org.apache.xml.internal.serializer.SerializerBase.addAttribute(Unknown Source)
at com.sun.org.apache.xml.internal.serializer.ToUnknownStream.addAttribute(Unknown Source)
at com.sun.org.apache.xalan.internal.xsltc.trax.DOM2TO.parse(Unknown Source)
at com.sun.org.apache.xalan.internal.xsltc.trax.DOM2TO.parse(Unknown Source)
at com.sun.org.apache.xalan.internal.xsltc.trax.DOM2TO.parse(Unknown Source)
at com.sun.org.apache.xalan.internal.xsltc.trax.DOM2TO.parse(Unknown Source)
at com.sun.org.apache.xalan.internal.xsltc.trax.TransformerImpl.transformIdentity(Unknown Source)
at com.sun.org.apache.xalan.internal.xsltc.trax.TransformerImpl.transform(Unknown Source)
at com.sun.org.apache.xalan.internal.xsltc.trax.TransformerImpl.transform(Unknown Source)
at com.ctpayment.ws.WsFacadeImpl.getInputNode(WsFacadeImpl.java:165)
at com.ctpayment.ws.WsFacadeImpl.processRequest(WsFacadeImpl.java:231)
at com.ctpayment.service.RequestServiceActivator.handleRequest(RequestServiceActivator.java:62)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at sun.reflect.NativeMethodAccessorImpl.invoke(Unknown Source)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(Unknown Source)
at java.lang.reflect.Method.invoke(Unknown Source)
at org.springframework.expression.spel.support.ReflectiveMethodExecutor.execute(ReflectiveMethodExecutor.java:69)
at org.springframework.expression.spel.ast.MethodReference$MethodValueRef.getValue(MethodReference.java:73)
at org.springframework.expression.spel.ast.CompoundExpression.getValueInternal(CompoundExpression.java:81)
at org.springframework.expression.spel.ast.SpelNodeImpl.getTypedValue(SpelNodeImpl.java:102)
at org.springframework.expression.spel.standard.SpelExpression.getValue(SpelExpression.java:103)
at org.springframework.integration.util.AbstractExpressionEvaluator.evaluateExpression(AbstractExpressionEvaluator.java:126)
at org.springframework.integration.util.MessagingMethodInvokerHelper.processInternal(MessagingMethodInvokerHelper.java:227)
at org.springframework.integration.util.MessagingMethodInvokerHelper.process(MessagingMethodInvokerHelper.java:127)
at org.springframework.integration.handler.MethodInvokingMessageProcessor.processMessage(MethodInvokingMessageProcessor.java:73)
at org.springframework.integration.handler.ServiceActivatingHandler.handleRequestMessage(ServiceActivatingHandler.java:67)
at org.springframework.integration.handler.AbstractReplyProducingMessageHandler.handleMessageInternal(AbstractReplyProducingMessageHandler.java:134)
at org.springframework.integration.handler.AbstractMessageHandler.handleMessage(AbstractMessageHandler.java:73)
at org.springframework.integration.dispatcher.UnicastingDispatcher.doDispatch(UnicastingDispatcher.java:115)
at org.springframework.integration.dispatcher.UnicastingDispatcher.dispatch(UnicastingDispatcher.java:102)
at org.springframework.integration.channel.AbstractSubscribableChannel.doSend(AbstractSubscribableChannel.java:77)
at org.springframework.integration.channel.AbstractMessageChannel.send(AbstractMessageChannel.java:157)
at org.springframework.integration.channel.AbstractMessageChannel.send(AbstractMessageChannel.java:128)
at org.springframework.integration.core.MessagingTemplate.doSend(MessagingTemplate.java:288)
at org.springframework.integration.core.MessagingTemplate.send(MessagingTemplate.java:149)
at org.springframework.integration.handler.AbstractReplyProducingMessageHandler.sendMessage(AbstractReplyProducingMessageHandler.java:216)
at org.springframework.integration.handler.AbstractReplyProducingMessageHandler.sendReplyMessage(AbstractReplyProducingMessageHandler.java:200)
at org.springframework.integration.handler.AbstractReplyProducingMessageHandler.produceReply(AbstractReplyProducingMessageHandler.java:165)
at org.springframework.integration.handler.AbstractReplyProducingMessageHandler.handleResult(AbstractReplyProducingMessageHandler.java:159)
at org.springframework.integration.handler.AbstractReplyProducingMessageHandler.handleMessageInternal(AbstractReplyProducingMessageHandler.java:141)
at org.springframework.integration.handler.AbstractMessageHandler.handleMessage(AbstractMessageHandler.java:73)
at org.springframework.integration.dispatcher.UnicastingDispatcher.doDispatch(UnicastingDispatcher.java:115)
at org.springframework.integration.dispatcher.UnicastingDispatcher.dispatch(UnicastingDispatcher.java:102)
at org.springframework.integration.channel.AbstractSubscribableChannel.doSend(AbstractSubscribableChannel.java:77)
at org.springframework.integration.channel.AbstractMessageChannel.send(AbstractMessageChannel.java:157)
at org.springframework.integration.core.MessagingTemplate.doSend(MessagingTemplate.java:288)
at org.springframework.integration.core.MessagingTemplate.doSendAndReceive(MessagingTemplate.java:318)
at org.springframework.integration.core.MessagingTemplate.sendAndReceive(MessagingTemplate.java:239)
at org.springframework.integration.gateway.MessagingGatewaySupport.doSendAndReceive(MessagingGatewaySupport.java:233)
at org.springframework.integration.gateway.MessagingGatewaySupport.sendAndReceiveMessage(MessagingGatewaySupport.java:207)
at org.springframework.integration.ip.tcp.TcpInboundGateway.doOnMessage(TcpInboundGateway.java:92)
at org.springframework.integration.ip.tcp.TcpInboundGateway.onMessage(TcpInboundGateway.java:82)
at org.springframework.integration.ip.tcp.connection.TcpNetConnection.run(TcpNetConnection.java:144)
at java.util.concurrent.ThreadPoolExecutor.runWorker(Unknown Source)
at java.util.concurrent.ThreadPoolExecutor$Worker.run(Unknown Source)
at java.lang.Thread.run(Unknown Source)
The request cannot be processed because the formated request is null
Message output interceptors: start.
Message output interceptors: end.
The proxy returned a response.
I’ll do some research about it.
I tried different things without success.
The error message talk about xsi prefix :
ERROR: ‘Namespace for prefix ‘xsi’ has not been declared.’
I don’t know much about the xsi prefix so I googled it :
The prefix “xsi” is the namespace prefix used by convention for the XML Schema instance namespace. XML documents can contain elements that have an xsi:type attribute. This behavior provides an explicit data type for the element. The MRM XML parser in sensitive to xsi:type attributes in the XML document.
The wsdl for the service I use don’t have any xsi prefix. The prefix is xsd like this :
<xsd:element type="xsd:string" name="cardNumber"/>
Is that possible that’s the origin of the problem? Maybe the xml file is not compatible with the Lucee xml parser?
I changed the endpoint of the webservice to capture the data sent and here what I found. Don’t worry, it’s a fake credit card number :
Lucee
<?xml version="1.0" encoding="UTF-8"?>
<soapenv:Envelope xmlns:soapenv="http://schemas.xmlsoap.org/soap/envelope/" xmlns:xsd="http://www.w3.org/2001/XMLSchema" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance">
<soapenv:Body>
<PurchaseInput xmlns="http://ctpaiement.com/paiementV2200">
<UCAF xsi:type="xsd:string"></UCAF>
<XID xsi:type="xsd:string"></XID>
<amount xsi:type="xsd:string">00000000100</amount>
<billNumber xsi:type="xsd:string">00000123T144</billNumber>
<cardNumber xsi:type="xsd:string">4988438843884305 </cardNumber>
<cardType xsi:type="xsd:string">V</cardType>
<cardholderAVV xsi:type="xsd:string"></cardholderAVV>
<clientAddress xsi:type="xsd:string"></clientAddress>
<clientPostalCode xsi:type="xsd:string"></clientPostalCode>
<companyNumber xsi:type="xsd:string">00539</companyNumber>
<currencyCode xsi:type="xsd:string">CAD</currencyCode>
<customerNumber xsi:type="xsd:string">00000000</customerNumber>
<cvv2cvc2Number xsi:type="xsd:string">123</cvv2cvc2Number>
<expirationDate xsi:type="xsd:string">0930</expirationDate>
<inputType xsi:type="xsd:string">I</inputType>
<languageCode xsi:type="xsd:string">F</languageCode>
<merchantNumber xsi:type="xsd:string">00XXXXXX</merchantNumber>
<merchantTerminalNumber xsi:type="xsd:string"></merchantTerminalNumber>
<operatorID xsi:type="xsd:string">AXIS0000</operatorID>
<originalBillNumber xsi:type="xsd:string">00000123T144</originalBillNumber>
<trxOptions xsi:nil="true"/>
<userEchoData xsi:type="xsd:string" xsi:nil="true"/>
</PurchaseInput>
</soapenv:Body>
</soapenv:Envelope>
Coldfusion 8
<?xml version="1.0" encoding="UTF-8"?>
<soapenv:Envelope xmlns:soapenv="http://schemas.xmlsoap.org/soap/envelope/" xmlns:xsd="http://www.w3.org/2001/XMLSchema" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"><soapenv:Body>
<PurchaseInput xmlns="http://ctpaiement.com/paiementV2200">
<companyNumber xmlns="">00539</companyNumber>
<merchantNumber xmlns="">00XXXXXX</merchantNumber>
<customerNumber xmlns="">00000000</customerNumber>
<amount xmlns="">00000000100</amount>
<billNumber xmlns="">00000089T145</billNumber>
<originalBillNumber xmlns="">00000089T145</originalBillNumber>
<inputType xmlns="">I</inputType><cardType xmlns="">V</cardType>
<cardNumber xmlns="">4988438843884305 </cardNumber>
<expirationDate xmlns="">0929</expirationDate>
<cvv2cvc2Number xmlns="">123</cvv2cvc2Number>
<merchantTerminalNumber xmlns=""></merchantTerminalNumber>
<languageCode xmlns="">F</languageCode>
<currencyCode xmlns="">CAD</currencyCode>
<operatorID xmlns="">AXIS0000</operatorID>
<clientAddress xmlns=""></clientAddress>
<clientPostalCode xmlns=""></clientPostalCode>
<cardholderAVV xmlns=""></cardholderAVV>
<xID xmlns=""></xID>
<uCAF xmlns=""></uCAF>
</PurchaseInput></soapenv:Body>
</soapenv:Envelope>
Lucee (or the extension for webservice) add the xsi attribute. Maybe the service I use don’t like to see this attribute! I’ll take a look at that tomorrow.
Hi,
Apparently I can’t use CreateObject("webservice") on Lucee for this particular soap webservice. Lucee (or the webservice extension) add the attribute xsi:type="xsd:string to each xml element and the webservice I’m using don’t appreciate it.
I decided to build the xml myself and send it with a basic http request (cfhttp) with the required headers (SOAPAction) and body. While searching how to do it, I found this blog post from Holy Ben Nadel the Great : Making SOAP Web Service Requests With ColdFusion And CFHTTP
The request was accepted by the webservice and I received the result in XML. So I found a way to make it works on Lucee.
I wonder if we can configure Lucee or the extension to stop the xsi addition, because it’s easier and cleaner to use the CreateObject("webservice") wrapper… I’ll try to contact the author of the Lucee Webservice extension just in case.
Well, I thought the author of Axis 1 Webservices was a particular person, but it’s the Lucee Association Switzerland. Adding the xsi:type look like a feature and not a bug. I suppose it follow a particular standard for XML. Not sure what can I do now… Asking for a feature request? I feel like my case is isolated…
I’ll take a look at the source code of the extension to find out what is happening behind the scene
Hi,
I just received the reply from the company of the payment gateway I’m trying to use on Lucee. They won’t change anything on their (old) webservice to support the presence of the xsi:type attribute in the xml soap message. So here my options :
-
Stop using CreateObject(“webservice”) on Lucee and build my own xml to communicate via cfhttp with their webservice and parse their response. That will required some code rewriting.
-
Stop using their old webservice and start to use their new API. That’s their suggestion and it’s required more code rewriting.
-
Find a way to make Lucee stop adding the attribute xsi:type in the xml. Is that possible?
Thank you
If I don’t find a very short term solution to remove the attribute added by Lucee in the XML data, I will turn to the new API as the company of the payment gateway suggested me. In addition to fixing the problem with Lucee, it allows me to modernize the payment gateway. It will be more future proof.
There is a sendXsiTypes Axis global configuration for the wsdd config files. I don’t know how to change it off hand in Lucee. Since you can do setproperty() I guess you would have to make/change the wsdd. I see the client and server in the org.lucee.axis jar file.
Thank you @kabutotx for your answer.
Although their old webservice is still working, they no longer want to maintain it. They also don’t want to investigate why the attribute doesn’t pass. It is clear to me that it is preferable that I start using their new payment API. Not only will it solve the situation with Lucee, but I will also reap more benefits in the medium and long term and avoid unpleasant surprises in the future.