I am creating some services using JAX-RS that need to take in arbitrarily complex objects as arguments, not just primitives like integers and strings. A discussion on the CXF mailing list says to just use a wrapper object as a single parameter in this case.
My concern is how to document the input format to the service? If creating a service that looks something like the following:
#POST
#Produces("application/json")
#Consumes("application/json")
#Path("oneParam")
public ComplexObject2 myServiceMethod(ComplexObject1 obj) {
Foo f = obj.foo
Bar b = obj.bar
...
}
the auto-generated WADL that CXF produces will only produce the following:
<resource path="/oneParam">
<method name="POST">
<request>
<representation mediaType="application/json"/>
</request>
<response>
<representation mediaType="application/json"/>
</response>
</method>
</resource>
This contains no information on what the request or response actually contains. Sergey on the CXF mailing list said it was possible to link a schema to the representation, but how am I supposed to do that? And how do I create the XSD?
(P.S. Using POST for idempotent resources might not be RESTful, but it's not important here as we are in essence doing RPC using Json. This is more or less a 1:1 clone of an existing SOAP based api.)
It is possible to link an XSD file into a WADL file and then to reference an XML element in the representation for requests and responses. However, as it is XML schema it doesn't apply to JSON representations.
To link an XSD into a WADL file, create a grammars element at the top of the file before the main resources element.
<grammars>
<include href="myapp.xsd"/>
</grammars>
Then add a reference to an XML element as follows (using a modified version of your example):
<resource path="/oneParam">
<method name="POST">
<request>
<representation mediaType="application/xml" element="myapp:oneParamRequest" />
</request>
<response>
<representation mediaType="application/xml" element="myapp:oneParamResponse" />
</response>
</method>
</resource>
The prefix myapp is defined in the XSD and can be used in the WADL file as well.
I don't know to to configure CXF to do this automatically. My experience with Jersey is similar and we use the generated WADL as a starting point for hand-editing later.
Related
I am trying to apply the data mapper mediator to the output of the XML data service defined within WSO2EI. Documentation indicates, that to use the data mapper you need to have a fully qualified names in the XML input files.
The data service I am creating does not include qualified prefixes within the XML it generates.
I tried to export the XSLT data mapping from the CAR file and run it along the sample XML generated by the data service through the external XML transformer - it did not work. However, if I added qualified prefixes in the input XML manually, everything works fine.
It seems that the reason for my data mapper not working is the default, and not qualified, namespace in the input XML. Unfortunately, I cannot get the data service including namespace prexifes in its output. Any ideas?
To illustrate the nature of the problem let us consider two slightly different inputs; first XML input file uses the default names, second one qualified names:
<soapenv:Envelope xmlns:soapenv="http://schemas.xmlsoap.org/soap/envelope/">
<soapenv:Body>
<users xmlns="http://ws.wso2.org/dataservice">
<user>
<last>Waelchi</last>
<first>Xzavier</first>
<country>Swaziland</country>
</user>
</users>
</soapenv:Body>
</soapenv:Envelope>
This XML is not properly handled by the XSLT, no matter if within WSO2EI, or external XML processor. However, the same XML with qualified names:
<soapenv:Envelope xmlns:soapenv="http://schemas.xmlsoap.org/soap/envelope/">
<soapenv:Body>
<users xmlns:p="http://ws.wso2.org/dataservice">
<p:user>
<p:last>Waelchi</p:last>
<p:first>Xzavier</p:first>
<p:country>Swaziland</p:country>
</p:user>
</users>
</soapenv:Body>
</soapenv:Envelope>
is properly interpreted at least by the external XML processor. My problem is, that I cannot get WSO2EI data service to include qualified prefixes in its output.
OK, I have managed to bypass the problem transforming XML output by WSO2 data service into qualified XML using XSLT transform. However, I am still unable to get qualified XML directly from the data service; any suggestion shall be appreciated.
I have a simple mule flow that streams a csv file to a custom java component. I need to be able to handle large files so don't want to use a Transformer that reads the file to memory.
Currently, I get the following error: "Failed to delete file "C:\temp\input\inputCSV.csv" as part of the file move operation. The file was being deleted because AutoDelete was set on the file connector."
Changing the mule XML config Autodelete="false" and specifying a destination directory for the 'processed' file results in a similar error. Could someone tell me how to stream the file and postpone autodeletion until the file has been read fully?
I'm calling .close() on my mule payloadStream, when I'm done, but mule seems to be completing the file deletion too early!
Here's the flow XML config...
<?xml version="1.0" encoding="UTF-8"?>
<mule xmlns:file="http://www.mulesoft.org/schema/mule/file" 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" version="CE-3.5.0"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xsi:schemaLocation="http://www.mulesoft.org/schema/mule/file http://www.mulesoft.org/schema/mule/file/current/mule-file.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">
<spring:beans>
<spring:import resource="classpath*:/spring/config.xml" />
<spring:import resource="classpath*:/spring/extras/Rule-preprocessor-config.xml" />
</spring:beans>
<file:connector name="fileInput" streaming="true"
autoDelete="true"
moveToPattern="#[message.inboundProperties['originalFilename']]"
doc:name="File">
<!-- <service-overrides messageFactory="org.mule.transport.file.FileMuleMessageFactory" /> -->
</file:connector>
<flow name="stringflowFlow2x" doc:name="stringflowFlow2x">
<file:inbound-endpoint connector-ref="fileInput"
path="/temp/input" doc:name="inputCsv" responseTimeout="10000" fileAge="10000" />
<component class="com.benji.FileImportPreProcessor" doc:name="JavaPreProcessorLogic"/>
<logger message="Finished!" level="INFO" doc:name="Logger"/>
</flow>
</mule>
When on streaming mode, Mule will wrap the stream with a ReceiverFileInputStream. It will take care of the file removal or movement when the stream is closed. And this is the point, you should not call the close on the input stream. The stream itself will call it whenever EOF is hit.
I understand this a little differently: See considerations https://docs.mulesoft.com/mule-user-guide/v/3.6/file-transport-reference
If streaming is enabled a ReceiverFileInputStream is used as the payload for each file that is processed. This input stream’s close() method takes care of moving the file or deleting it. Streams are closed by transformers reading the input stream. If you process the stream in your own component implementation make sure to properly close the stream after reading.
Therefore I don't think mule handles this for you unless you use a transformer which is usually highly likely....but in my case some initial validation meant I had not even started to consider the payload meant I was ending the process before transforming the payload (and therefore not reading and closing the file stream)
You should you object-to-byte-array transformer in File connector itself. It will take care of closing the stream after reading the input stream.
I have an issue with using Camel CXF in PAYLOAD mode. I am sending a SOAP request with body having no namespace prefix.
<soap:Envelope xmlns:soapenv="http://schemas.xmlsoap.org/soap/envelope/" xmlns="http://www.mycompnay.com/test/" xmlns:ns1="http://www.mycompany.com/test/1/">
<soap:Body>
<request>
<ns1:identifier>TEST</ns1:identifier>
</request>
</soap:Body>
</soap:Envelope>
And I am trying to get the cxf body element as cxfPayload.getBody().get(0) which gives me a List of elements.
Now whenever I use a namespace without prefix, the element has a attribute "xmlns:xmlns". And I noticed that this is happening in two places.
DefaultCxfBiding.addNamespace(Element, Map)
CxfPayload.addNamespace(Element, Map)
And in both the places, "xmlns:" is simply prefixed to nsMap.get(key) without checking if the value is xmlns.
This is causing issues during Schema validation and also if the same CXFPayload is sent to another service (Proxy service patterns), it is causing the Out interceptors to fail as "xmlns:xmlns" is not valid namespace attribute.
Appreciate the help as I am not sure if I am missing something here.
It's bug of camel-cxf, I just created a JIRA for it.
I'm transforming XML request to SOAP via XSLT in WSO2ESB, just wondering is it possible to make request parameter available to be used in response?
E.g.
<request>
<test>123</test>
<param1>testing</param1>
</request>
-> converted to SOAP
<?xml version='1.0' encoding='utf-8'?><soapenv:Envelope xmlns:soapenv="http://schemas.xmlsoap.org/soap/envelope/"><soapenv:Body><S:Envelope xmlns:S="http://schemas.xmlsoap.org/soap/envelope/">#S:Body><ns2:testrequest xmlns:ns2="http://xml.testing.com/test"><teststring>testing</teststring></ns2:testrequest></S:Body></S:Envelope></soapenv:Body></soapenv:Envelope>
In the response
<?xml version='1.0' encoding='utf-8'?><soapenv:Envelope xmlns:soapenv="http://schemas.xmlsoap.org/soap/envelope/"><soapenv:Body><S:Envelope xmlns:S="http://schemas.xmlsoap.org/soap/envelope/"><S:Body><ns2:testresponse xmlns:ns2="http://xml.testing.com/test"><responsestring>success</responsestring></ns2:testresponse></S:Body></S:Envelope></soapenv:Body></soapenv:Envelope>
I want to return in XML
<responsestring>
<test>123</test>
<return1>success</return1>
</responsestring>
As you see, 123 isn't send to the server and has not received from the server. However, client is sending this parameter and i would like to just use this parameter in request and send back in response, is this possible? By how? I'm very new to synapse and very new to WSO2ESB, could anyone please enlighten me?
Thanks.
Yes it is possible. You can use property mediator in the Insequence to set the required value as a property and then add it in the outsequence to response using enrich mediator.
Got it working now.
Simply by adding the property mediator in both insequence and outsequence together with the XSLT, where the xslt is trying to get the value from test property. That's it!
Insequence
<property xmlns:ns="http://org.apache.synapse/xsd" name="TEST" expression="//request/*[local-name()=test]" scope="default"/>
outsequence
<xslt key="xxxx.xslt">
<property name="test" expression="get-property('TEST')"/>
</xslt>
Hello WSO2 community and hello Stackoverflow,
my testing of the SOA suite starting from the ESB is going good: now the ESB recognises external services, create correct proxies that return correct results.
SOLVED
About that, I have two issues: the first is that the "try it"
functionality raises the exception:
"Cannot find dispatch method for {http://schemas.xmlsoap.org/soap/envelope/}Envelope
[tagOpened]/soapenv:Text[tagClosed]"
when i try to send a SOAP enveloped created for the mock service of
the web service proxied.
Anyway, if I try the proxy service from an external client (created on
Netbeans) it works great.
ANSWER
For the first part, the reason is most probably the cross domain issue as try-it is sending messages through a java script stub from
the browser. You will notice that this works great when the service
itself is hosted in the ESB itself, because the request passes through
the same domain. This is why, although, it works perfectly through a
normal client invocation, it does not work through try-it.
The second issue is that I'm not able to orchestrate two services. My objective is sending the input of the first service to the second service, and then to the user.
I'm working on the tutorial Tharindu Mathew suggested: everything now makes sense to me except on one thing: the XSLT transformation.
Here is the out sequence the tutorial suggests you to create:
<outSequence xmlns="http://ws.apache.org/ns/synapse">
<switch source="get-property('STATE')">
<case regex="PERSON_INFO_REQUEST">
<log level="full">
<property name="sequence" value="outSequence - STATE 01 - response from PersonInfoService" />
</log>
<xslt key="xslt">
<property name="amount" expression="get-property('ORG_AMOUNT')" />
</xslt>
<log level="full">
<property name="sequence" value="outSequence - STATE 01 - request for CreditService" />
</log>
<property name="STATE" value="CREDIT_REQUEST" />
<send>
<endpoint key="CreditEpr" />
</send>
</case>
<case regex="CREDIT_REQUEST">
<log level="full">
<property name="sequence" value="outSequence - STATE 02 - response from CreditService" />
</log>
<send />
</case>
</switch>
</outSequence>
Now, focusing on the XSLT node of the first case of the switch, you can see that there's just a get for the amount property.
So that I think we have an XML from the in sequence that states the ID, and this get on the amount property (and I don't know what it does).
The tutorial then suggests:
To create the request to this CrediService, we use the following XSLT with the XSLT mediator. Note, we are using the ORG_ID that we stored in this XSLT as a XSLT parameter and using the XSLT mediator as well.
And here is the XSLT showed in the tutorial:
<xsl:stylesheet version="2.0"
xmlns:xsl="http://www.w3.org/1999/XSL/Transform"
xmlns:fn="http://www.w3.org/2005/02/xpath-functions"
xmlns:ns="http://samples.esb.wso2.org"
xmlns:ax21="http://samples.esb.wso2.org/xsd"
exclude-result-prefixes="ns fn">
<xsl:param name="amount"/>
<xsl:output method="xml" omit-xml-declaration="yes" indent="yes"/>
<xsl:template match="/">
<xsl:apply-templates select="//ns:getResponse" />
</xsl:template>
<xsl:template match="ns:getResponse" xmlns:ns="http://samples.esb.wso2.org">
<sam:credit xmlns:sam="http://samples.esb.wso2.org" xmlns:xsd="http://samples.esb.wso2.org/xsd">
<sam:info>
<xsd:amount><xsl:value-of select="$amount"/></xsd:amount>
<xsd:personInfo>
<xsd:address><xsl:value-of select="ns:return/ax21:address"/></xsd:address>
<xsd:id><xsl:value-of select="ns:return/ax21:id"/></xsd:id>
<xsd:name><xsl:value-of select="ns:return/ax21:name"/></xsd:name>
</xsd:personInfo>
</sam:info>
</sam:credit>
</xsl:template>
</xsl:stylesheet>
I was asked to put a similar file into the resources directory of WSO2 ESB, but this file is never used in the tutorial:
Copy the personToCredit.xslt in the sample zip to resources directory of WSO2 ESB.
---------LITTLE PARENTHESIS-----------
The WSDL file was not used either after it was stated:
Copy the CreditProxy.wsdl in the sample zip to the resources directory of the WSO2 ESB.
I cannot find the WSDL file in the Configuration/Governance Registry, and I don't know how to address it, so I chose to specify it inline instead.
---------LITTLE PARENTHESIS END-----------
This sentence is followed by the XSLT file text. My main question now is:
Where should I put this XSLT? I do not know where to put the XSLT mediator, neither how to build it.
Should I rely on registries?
A perfect answer could be the code of the out sequence, and the specified connection with the XSLT mediator suggested.
OverTheBitStair
Hi OverTheBitStair (nice nick!),
For the first part, the reason is most probably the cross domain issue as try-it is sending messages through a java script stub from the browser. You will notice that this works great when the service itself is hosted in the ESB itself, because the request passes through the same domain. This is why, although, it works perfectly through a normal client invocation, it does not work through try-it.
For the second part, the short answer is yes, it is possible. In terms of the ESB, we refer to it as a light-weight orchestration engine in addition to being a mediation engine. This means for light-weight and short-lived (<1 day) processes we can solve the orchestration requirements using the ESB without bringing in the Business Process Server.
To do this, we use this method called service chaining. What it does is introduce a method to get some output out of the initial service invocation and use it in a subsequent invocation. The article WSO2 ESB by example - Service Chaining should help you with implementation details on what you are looking for.
Hope this helps.
If you create a service chaining scenario where your proxy service calls two other services and return the result to the caller of the proxy service, it would look something like this:
Caller --> Proxy Service -- seq_A --> Service1 -- seq_B --> Service2 -- seq_C --> (proxy serviced response) --> Caller
In this case, seq_A would be the in sequence of the proxy service, seq_C the out sequence of the proxy service and seq_B another named sequence.
Input, i.e. the message body, to seq_A would be the input to proxy service. seq_A would contain a send mediator at the end and at that point in the sequence the message context would be the input to Service1. The send mediator also points to seq_B to be executed for the reply.
At start of seq_B the message body contains the output from Service1. If you want to keep some message data from before the service call you need to save that in properties in the context.
At the end of seq_B you would have a send mediator; at that point the message body should contain the input to Service2, The send mediator would in this case not need to point to an explicit reply sequence, if seq_C is the out sequence of the proxy service - that one will be used by default then.
When seq_C is executing the message body at that point is the response from Service2. Again, if you need to use/combine with some data prior to the call to Service2, you need that to be saved into properties.
Depending on the particular needs for the input and transformations needed at each step it can be fairly straightforward or a bit cumbersome to handle.
What also should taken into consideration is what needs to happen in error scenarios, as this may add some additional complexity, depending on the requirements.