SonicConnect Questions/Clarifications

I'm still puzzled about the acceptor-like listener piece that ties all of this together.  My WSDL port that the SonicConnect top-down is based on specifies an address of the flavor:  http://localhost:88/extensionURLforService

There is nothing established to listen on port 88 per netstat on my local machine.  If I try and put an acceptor in place on the broker after deploying the SonicConnect service, the broker startup throws a bind exception stating that port 88 is already in use.  By what?

Also, with the deployed SonicConnect service having a defined entry endpoint, I tried using the JMS client and publishing an XML message (my SOAP request) to the entry endpoint of the SonicConnect service with a known JMSReplyTo populated in the message properties.  I get this exception in my logging:

[10/11/08 15:07:21] ID=dev_ESBTest (severe) [Dispatch] Exception calling service C2CWebServiceSonicConnectService: message rejected
[10/11/08 15:07:21] ID=dev_ESBTest (severe) Trace follows...
com.sonicsw.xq.XQServiceException: Missing runtime parameter: esbcamelBeanId
    at com.progress.sonic.esb.service.connect.ConnectService.service(ConnectService.java:193)
    at com.sonicsw.xqimpl.service.ServiceMessageHandler.callService(ServiceMessageHandler.java:477)
    at com.sonicsw.xqimpl.service.ServiceMessageHandler.handleMessage(ServiceMessageHandler.java:204)
    at com.sonicsw.xqimpl.service.XQDispatcher.onMessage(XQDispatcher.java:434)
    at com.sonicsw.xqimpl.endpoint.container.EndpointContextContainer.onMessage(EndpointContextContainer.java:96)
    at com.sonicsw.xq.connector.jms.JMSEndpoint$JMSEndpointListener.onMessage(JMSEndpoint.java:577)
    at progress.message.jimpl.Session.deliver(Session.java:3057)
    at progress.message.jimpl.Session.run(Session.java:2463)
    at progress.message.jimpl.Session$SessionThread.run(Session.java:2852)

[10/11/08 15:07:21] ID=dev_ESBTest (severe) [Dispatch] ServiceMessageHandler for service C2CWebServiceSonicConnectService - XQ_SERVICE_EXCEPTION error processing message: Missing runtime parameter: esbcamelBeanId

What component ties the client request to the SonicConnect service and the underlying processes that implement the web service operations?

Chris,

SonicConnect is implemented differently from the previous version of Web Services integration that Sonic provided.

Most importantly, to expose and consume SOAP/HTTP Web Services, SonicConnect does not send traffic though the broker.

HTTP is directly from the ESB Container.

Sonic Connect leverages a combination of CXF and CAMEL technology to both consume and expose.

In answer to your question,  the HTTP "acceptor" equivalent is a Jetty server activated by a Spring.xml file with CAMEL and CXF definitions, and supporting property files.

These files are created by Workbench, in the runtime, the Spring fragments appear inside a Sonic Connect archive(.csar) that tooling deploys . The .csar is an initialization parameter for each Sonic Connect service.

The fact that you see port information in the ESB Container log that houses Sonic Connect reflects that it is the ESB Container that is activating the port.

Sonic Connect can both expose and consume SOAP/HTTP or REST/HTTP Web Services. In the expose use cases, CAMEL routes defined in the Spring.xml dispatch from a cxfjetty component to ESB itinerary endpoints. In the consume use-case the Sonic Connect service is included as an itinerary step and an invocation(esbcamel) is setup using itinerary input, output and mapping. Sonic Connect service steps only appear in an itinerary .esbp file when an invoke is being performed. The invocation is described  in an esbcamel file( This explains the error you reported in your second message).

As for exposing SOAP Web Services, ESB message parts relate to the WSDL interface parts. Your example (where you want to pass a single XML document inside a SOAP Body into ESB) suggests that you should be using a DOC LIT WSDL .

I'm not sure why you are having trouble calling the exposed process. There are several Sonic Connect samples that are worth going over to get an understanding of all the flows. If you still have trouble you can always attach the project artifacts (.csar,.properties)

Peter

Peter,

Thanks for that explanation.  I had begun to do a little investigation with the FUSE ESB before we turned back to Sonic and the Camel/CXF implementation for SonicConnect services in the ESB Container should prove out well  We should realize improved performance without having to leave the ESB Container MF Container to get back to the broker in order to receive or send web service requests.

Mahesh responded earlier that using the SonicConnect service, we could do away with the SOAP tag extractors and wrapper which were typically required to implement a common SOAP web service by older means, i.e. HTTP acceptors.  I'm passing in a SOAP message payload to my SonicConnect service but I am having difficulty verifying exactly what my operation, implemented by a custom ESB process/service is getting in the message part that is delivered to its entry endpoint.  I disabled intra-container messaging anticipating that I could tap the process/service implementation entry-endpoint at the broker.

I'm submitting requests two ways:

1. Using the Workbench Scenario tab, consuming a specific operation, and specifying the input parameter as a file, the contents of the file are identical to the SOAP request our web service expects - full soap tags and body payload XML.  When I submit this way, the container log appears to show my custom service in the implemented operation process getting hit, but it takes unmarshalling exceptions.  Our service layer expects to be working on only the XML payload.
   
   Caused by: javax.xml.bind.UnmarshalException: unexpected element (uri:"http://schemas.xmlsoap.org/soap/envelope/", local:"Envelope")
   
   I would get this exception if we were still attempting to process the XML with the SOAP envelope and tags around the message part.  Is there a good place to confirm that the process that is implementing the tested web service operation gets only the XML which is delivered in the SOAP body tags or do I need to specify I only want the body content and not the full wrapper?
   
   
2. Using SOAP UI to submit the same SOAP request to the web service URL externally.  The WSDL document is returned nicely in my browser when I browse to it, as expected.  When I use SOAP UI, the exception received looks much farther upstream than even making the custom process/service which implements the web service operation.  I get this exception:
   
   Nov 9, 2010 11:38:26 AM org.apache.camel.component.cxf.interceptors.AbstractMessageInInterceptor createDOMMessage
   INFO: AbstractMessageInInterceptor Converting Stax Stream to DOM
   [10/11/09 11:38:28] ID=dev_ESBTest (info) [] USU: Processing Response for jurisdiction "Arlington County" with agency "ARLRMS".
   [10/11/09 11:38:28] ID=dev_ESBTest (severe) [] com.sonicsw.xq.XQMessageException: Failed to get part.  No part with content id resultcom.sonicsw.xq.XQMessageException: Failed to get part.  No part with content id result
       at com.sonicsw.xq.connector.jms.XQJMSMessage.getPartIndexForContentId(XQJMSMessage.java:1139)
       at com.sonicsw.xq.connector.jms.XQJMSMessage.getPart(XQJMSMessage.java:970)
   
   Using the external call, something is not correlating properly

Thanks in advance.  I'm obviously trying to get beyond the framework configuration issues here so I can simply work on the web service operation implementations in the ESB layers.

More information:

Using the workbench to test the SonicConnect Service interface for one of the web service operations, if I use an input XML message without the SOAP envelope (simply what should be the XML payload part), I get the expected processed response from the custom service in the ESB process which implements the web service operation.  Additionally, if I put back in place the SOAP tags removal XML transformation service in front of the custom service step in the custom process which implements the web service operation, I can process the payload by using an external request as well.  Why isn't the SonicConnect service removing the SOAP?  Is there something specific that needs to be configured for this aspect?

There seems to be a warning message about the broker and temp queues it is using for this processing also:

[10/11/09 12:22:11] ID=dev_ESBTest (warning) com.sonicsw.xq.XQEndpointCreationException:  (Failed to find MgmtBroker::$ISYS.USERS.TemporaryQueues.Administrator.$TMPAPPID$9$$SESSION$118.*.*.-142702917221-873658342MgmtBroker in context endpoint - There is no element /xqEndpoints/MgmtBroker::$ISYS.USERS.TemporaryQueues.Administrator.$TMPAPPID$9$$SESSION$118.*.*.-142702917221-873658342MgmtBroker in the Directory Service) (Failed to find MgmtBroker::$ISYS.USERS.TemporaryQueues.Administrator.$TMPAPPID$9$$SESSION$118.*.*.-142702917221-873658342MgmtBroker in context endpoint - There is no element /xqEndpoints/MgmtBroker::$ISYS.USERS.TemporaryQueues.Administrator.$TMPAPPID$9$$SESSION$118.*.*.-142702917221-873658342MgmtBroker in the Directory Service)

Is this a remnant from a previous temp queue possibly used for responses for the Sonic Connect service?  I seem to be having basic issues just getting the SonicConnect dots connected so I can get back to the web service operation implementations.

Chris,

For scenarios that directly test your ESB Process, you create your scenario in terms of ESB test messages, not SOAP. Although the itinerary happens to be exposed by Sonic Connect, when you test your process using itinerary scenarios, the test messages are not going through Sonic Connect - they are going directly into the ESB process.

This is different from our previous Web Service support where in order for an ESB process to implement a Web-Service the process needed explicit SOAP Unwrap and SOAP Response steps, or needed to be surrounder by a wrapper process that did these steps.

Sonic Connect does the unwrap and response steps for you. This big advantage here is that your ESB process can be SOAP agnostic and focus on the application data.

In your DOC-LIT use case, the ESB itinerary should expect and produce single-part ESB messages whose part name co-incides with the abstract WSDL operation messages.

Peter

Peter,

Once again, thanks for the response.  I believe I empiracally stumbled on the fact that the Workbench scenario was testing the operations and just the processes on the message payload and not the complete soap message.

What you've indicated about the response and looking for the part named or identified by the output name specified in the WSDL operation jives with the error messages.  The output part name on the operation was simply "result."  The error message is stating there is no part with content id "result."

Many thanks.

Is there documentation on the SonicConnect web services beyond the rudimentary web_services.pdf document and the demonstrations?

I would like to use a SonicConnect service as a step in an ESB Process to call an external web service and have the next step in the ESB Process process the response (either expected or a fault).  The endpoint I need to call could be one of several possible external web service endpoints.  Is there a way to dynamically configure, either through the use of message properties or other means, to override and set the endpoint the SonicConnect service will use to call the external web service?

Thanks.

Chris

The online documentation has some Multimedia tutorials, http://communities.progress.com/pcom/docs/DOC-103562.

Alas, dynamic URL override for calling SOAP Web Services using Sonic Connect is not currently implemented, but this is a feature that will be implemented in the next release.

(You can change URLs at configuration easily as these are externalized through the Sonic Connect properties file.)

Peter

Peter, thanks for the reply.

By next release, do you anticipate that being a major release such as 8.1 or 8.2 or would this feature to override the endpoint for a SonicConnect web service client be perhaps in 8.0 SP2?

I guess our alternative to do this dynamically is to use the Dynamic HTTP Outbound Routing Definition and override the URL endpoint in the message header properties before calling the endpoint referencing the routing definition?

Is there documentation which shows all of the message headers populated by the SonicConnect service when it receives an incoming SOAP request and passes it on as a JMS message internally to the mapped process?

I'm partciularly interested in the property which would contain the equivalent of the X-HTTP-ReceiveURL which is populated by an HTTP Acceptor when it receives a request and passes it on to the mapped endpoint as an ESB/JMS Message.

I'm not sure what your use case for X-HTTP-ReceiveURL would be.

Generally you'll receive inbound arbitrary HTTP headers like SOAPAction, Host etc. This is configurable by the header filter definitions in the spring.xml/

Now, say your application needs a custom header as you describe, an option is to edit the spring.xml file and add the header using camel:setHeader e.g.

uri="cxf:bean:PPortEndpoint?headerFilterStrategy=#HeaderFilterStrategy.PPortEndpoint"/>

${PService.PPort.address}

${in.header.operationName} == 'P'

uri="directsonicesb:PService.PPort.P"/>

Peter, thanks.