Couple of questions about HTTP WS datasources

[ssedlmeyer]

First, this is all using Teiid 7.3 and Designer 7.3.

I'm trying to use an HTTP based web service which requires me to post a request with an XML document in the parameter requestDoc and returns an XML document.  The service also requires the use of transport security (SSL/TLS with Client Auth).

At the moment I have 3 questions I'm hoping someone can help me with...

1.  The reference guide talks about an execution parameter called XMLParamName which seems like it will let me tell the ws translator to stick the request XMLLiteral into a parameter with the name of my choice.  It doesn't, however, mention how to set that parameter either globally or on a datasource level.  Anyone have any suggestions?  When I go into the admin console I can see the other two execution parameters (DefaultBinding and DefaultServiceMode) in the Configuration panel for the ws translator but XMLParamName doesn't appear in the list.

2.  I need to configure CXF to use a keystore and do client auth with the server.  The docs talk about pointing to a cxf config file from the -ds.xml file but when I do that I get a parse error on the first node in the cxf config ("<beans...").    In this case it would work for me to be able to tell Teiid to globally configure CXF to use the same properties.  Anyone know specifically how I configure it for either a specific data source or globally?

3.  For both of the above can I configure them in the models, datasource or vdb so that I don't have to edit files directly?  If so, how...

thanks in advance...

[rareddy]

Steve,

1) Tooling support to override the Translator properties is a feature that is coming in 7.4 Designer. With 7.3 you would have to manually edit the "vdb.xml" file inside your ".vdb" file in the META-INF folder. Below is an example xml for doing that.

    <model name="Accounts" visible="false" type="PHYSICAL">
        <source name="accountsService" translator-name="ws-override" connection-jndi-name="java:myAccountsService" />
    </model>

    <translator name="ws-override" type="ws">
        <property name="XMLParamName" value="some value"/>
    </translator>

2) in -ds.xml file, you need to specify the path the "jboss-ws-cxf.xml" and the port name using proeprties as

<config-property name="configFile">/path/to/jbossws-cxf.xml</config-property>
<config-property name="configName">portName</config-property>

Note along with defining the jboss-cxf.xml file, you need to specify necessary property files, certificate files etc. See here http://community.jboss.org/wiki/Jbossws-stackcxfUserGuide

3) For now this is manual process.

Hope this helps. Let us how this works. If possible please post a working example to aid other users.

Thanks

Ramesh..

[ssedlmeyer]

Ramesh,

Thanks for the quick response.  I made the suggested changes but I'm unable to test.  When I add in the configFile and configName properties in the datasource config I get a SAXParseException at the "beans" node.  The xsd is in the spring-beans jar and the spring.schemas file in the jars META-INF folder looks correct so I'm not sure why it's not getting found.  I also tried pulling the xsd out of the jar and putting it on the file system then replacing the URL in the schemaLocations attribute with the coresponding file URL with the same result.  Any ideas?

Thanks,

Steve

[ssedlmeyer]

never mind, found that issue, re-testing.

[ssedlmeyer]

Ok, after correcting my issue ("schemalocation" vs. "schemaLocation") I was able to test with the suggesting configuration information.  The cxf config worked as expected and I'm now successfully connecting to the service with client auth and the changes to the vdb also seem to have worked as the request is coming in with a parameter named "requestDoc" in the body of the POST.  However, it seems that the parameter, which I thought would contain the XML request document supplied to "invoke", is empty.  Is there something else that needs to be set to cause the request XMLParam to be set to the XML literal I passed in?

Thanks,

Steve

[ssedlmeyer]

Based on what I'm seeing in the code it doesn't do what I'm hoping for.  I'd like to post a request with the body of the request looking something like:

requestDoc=<sometag>....</sometag>

It looks like org/teiid/translator/ws/WSProcedureExecution.java would have to be modified to insert the following at line 120:

                } else if (source != null && this.executionFactory.getXMLParamName() != null) {
                         StringWriter writer = new StringWriter();
                         Transformer t = TransformerFactory.newInstance().newTransformer();
                         t.transform(source, new StreamResult(writer));
                         source = new StreamSource(new StringReader(this.executionFactory.getXMLParamName()+"="+writer.toString()));
                 }

Sorry I don't have access here to what I need to produce this as a patch...

Message was edited by: Steve Sedlmeyer:  missed a ")"...

[shawkins]

Steve,

So you're looking to do a POST and have the payload look like a parameter, or would you just want to send a regular query string parameter with the doc?

Steve

[ssedlmeyer]

Exactly, I need to post the request XML as a parameter in the POST body rather than in the query string.  It's standard valid HTTP, just a little unusual.

[shawkins]

Steve,

Did you test your proposed fix?  I don't think that jax-ws allows this style of invocation.  Even if you use MESSAGE mode, it still expects the the payload content to be well formed. 

Assuming you don't have to worry about entity escaping, a possible path is to use invokeHttp instead. 

call invokeHttp(action='POST', request=>XMLCONCAT(XMLPARSE(CONTENT 'paramname=' WELLFORMED), requestDoc))

The return parameter result will be blob.  You can use the to_chars system function to convert to a clob, or just use xmlparse if the content is xml.  However due to issues with their binary dispatch, invokeHttp by-passes CXF - see BinaryWSProcedureExecution.  Currently invokeHttp only supports basic auth.  An enhancement would be needed to support ssl client auth - unless you can configure the handling using java default properties.

Steve