Am getting the error message below, any idea what am missing?
<?xml version="1.0"?><SOAP-ENV:Envelope SOAP-ENC:encodingStyle="http://schemas.xmlsoap.org/soap/encoding/" xsi:schemaLocation="http://schemas.xmlsoap.org/soap/envelope/ http://schemas.xmlsoap.org/soap/envelope" xmlns:SOAP-ENC="http://schemas.xmlsoap.org/soap/encoding/" xmlns:SOAP-ENV="http://schemas.xmlsoap.org/soap/envelope/" xmlns:xsd="http://www.w3.org/1999/XMLSchema" xmlns:xsi="http://www.w3.org/1999/XMLSchema-instance" xmlns:rpc="http://www.sonicsw.com/sonicxq/rpc"> <SOAP-ENV:Body> <xq:rejectedMessageInfo xmlns:xq="http://www.sonicsw.com/sonicxq"> <rejectedCode>XQ_ENDPOINT_EXCEPTION</rejectedCode> <rejectedLocation container="dev_ESBTest" host="LAP01862" process="JewsonsToConntrol-OrderApproval" serviceApplication="JewsonsToConntrol-OrderApproval" step="InsertJMSMessageId"/> <rejectedDetails>java.lang.RuntimeException: No session available to deliver the outgoing message. This may be due to an in progress broker reconnect. at com.sonicsw.xq.connector.jms.messagingbean.MessagingBean$SessionPool.getSession(MessagingBean.java:1870) at com.sonicsw.xq.connector.jms.messagingbean.MessagingBean.getSessionFromPool(MessagingBean.java:1107) at com.sonicsw.xq.connector.jms.JMSEndpointContext.send(JMSEndpointContext.java:140) at com.sonicsw.xqimpl.endpoint.container.EndpointContextContainer.send(EndpointContextContainer.java:234) at com.sonicsw.xqimpl.service.MessageSendingHelper.sendToEndpoint(MessageSendingHelper.java:199) at com.sonicsw.xqimpl.service.MessageSendingHelper.sendToService(MessageSendingHelper.java:360) at com.sonicsw.xqimpl.service.MessageSendingHelper.sendToAddress(MessageSendingHelper.java:76) at com.sonicsw.xqimpl.service.MessageSendingHelper.sendToProcess(MessageSendingHelper.java:827) at com.sonicsw.xqimpl.service.MessageSendingHelper.sendToProcess(MessageSendingHelper.java:845) at com.sonicsw.xqimpl.service.MessageSendingHelper.sendToAddress(MessageSendingHelper.java:80) at com.sonicsw.xqimpl.service.MessageSendingHelper.sendEnvelopes(MessageSendingHelper.java:951) at com.sonicsw.xqimpl.service.XQDispatcher.onMessage(XQDispatcher.java:493) at com.sonicsw.xqimpl.endpoint.container.EndpointContextContainer.onMessage(EndpointContextContainer.java:84) at com.sonicsw.xq.connector.jms.JMSEndpoint$JMSEndpointListener.onMessage(JMSEndpoint.java:570) at progress.message.jimpl.Session.deliver(Session.java:2998) at progress.message.jimpl.Session.run(Session.java:2390) at progress.message.jimpl.Session$SessionThread.run(Session.java:2775)</rejectedDetails> </xq:rejectedMessageInfo> </SOAP-ENV:Body></SOAP-ENV:Envelope>
How many web service sessions have you configured on the ESB http connection (see ESB Explorer in SMC --> Endpoints --> Connection Tab)?
Also, what is your scenario? Are you running from Workbench?
Hi Thomas, thanks for you response
Didn't change anything so it was set to 10, have tried changing it now to 100 but the sam problem. Am sending the jms message from workspace, can see that it comes into the entry point via Message Listener, but it stops on first step for a while and ends up in RME with the error above.
Any help greatly appreciated,
Btw, do you know of any tutorial with simple JMS as the starting point for process and with another step invoking db call?
I assume the first step is the Webservice invocation? How have you configured it? You using all defaults? If not what have you changed?
For samples you can import the existing ones at SONIC_HOME\ESB7.6\samples (Workbench File Menu --> Import --> Existing Project Into Workspace; Don't copy). I realize it does not have a database one, but they generally give good guidance. Essentially, DB Service works the same as WebServices in that you need to provide mappings to and from the messages. The only obstacle to overcome is to properly configure your dev.DBservice instance. Reference to the Workbench Help (Hit F1 and seach for database service / jdbc driver).
The project am working on already exists, am suppost to add new bits and pices ... after I learn how it works
But just getting it to run as it is from cvs is making me cry
The entry end point is mapped to the JMS queue, first step is the of type: XML transforamtion the next step should insert a record into the db, but it never gets there...
Hmmm. So you XForm step: Which Entry Endpoint does it use? And which ESB Connection does that use (URLs)? Is the corresponding broker/cluster running?
tszpinda wrote:But just getting it to run as it is from cvs is making me cry The entry end point is mapped to the JMS queue, first step is the of type: XML transforamtion the next step should insert a record into the db, but it never gets there...
Are you trying to upload a process into a different domain than the one you used in Workbench? If so, was it working in the Workbench situation as a scenario. It does look like you did deploy the process into a container, which is good, but I would then check all the Endpoints you are routing to (i.e. the XForm service especially) and verify
the entry endpoints for these have connections that point to the 'correct' brokers. (I am wondering if you can't get the sessions because the broker can't be connected to)
As I can see you are testing a custom service in an ESB process.
The custom service is in dev_ESBTest container, but when you deploy a new process you have configure a new service instance and add it to dev_ESBCore.
Then restart your Core container, change the service at the process level, upload it and run a test scenario.
You can also make sur that all your endpoints and connexions are well configured.
jerem wrote:... As I can see you are testing a custom service in an ESB process.The custom service is in dev_ESBTest container, but when you deploy a new process you have configure a new service instance and add it to dev_ESBCore.Then restart your Core container, change the service at the process level, upload it and run a test scenario....
The above information is not correct. You (as a typical user of Workbench) should never have to change or modify dev_ESBCore. (You can do it, but you never NEED to do it).
You also don't need to deploy the ESB Process. (Technically, in Workbench, their is a special "dev.Run" service that forwards your scenario to the Process using a variation of intracontainer. The service you are testing DOES need to be deployed (and usually the default of dev_ESBTest is the right place) and the service does need a viable JMS-based Entry Endpoint.
The original point about "No session being available" is probably due to some custom service 'hanging' or not returning correctly. It could also be because some endpoint was configured with a ESB Connection to a broker that was not accessible.
Sorry for my bad answer. I won't do it agains
jerem wrote:Sorry for my bad answer. I won't do it agains
Better to have people give answers that can be 'tweaked' than not to have participation. Keep on answering.