"TIBCO EMS explicit client" ack not working with SOAP-Over_JMS
"TIBCO EMS explicit client" acknowledgement mode not working with SOAP-Over_JMS. It is behaving more like client acknowledgement mode with 1 session.
When more than 1 messages are send to asynchronous SOAP-Over-JMS service. It is expected that all the instances should create in parallel in its own session. But this is not the case. BW6 is creating instances one after other, just like client acknowledgement mode, where all the messages are handled in one session.
On the other hand "TIBCO EMS explicit client" is working fine with JMS receiver as expected.
Confirm activity not working properly for SOAP-Over-JMS with bulk messages.
This issue was noticed in the TIBCO BW 6.3.2 run-time environment. We have a business logic in which, BW6 gets a SOAP message from EMS queue and process it. During this processing
- it reads a file (in a sub process).
- send the binary content to REST API (in a sub process)..
- Once success fully done, it remove the file (in a sub process).
- confirm the SOAP message in the parent process with "confirm activity"
- If there is any issue it throw an error and do not confirm the message.
- We are using TIBCO explicit client acknowledgement mode, along with retry of 5 times with a delay of 10 minutes. So if there is any issue in the processing, then the message is not ack-ed and it is resubmitted by EMS after 10 minutes.
ISSUE:
-----------
Once the message is submitted it is properly reading the file, sending it the REST api, removing the file and executing the "confirm" activity, but still the message is not acknowledged properly. as a result the same message is redelivered to BW6. Since the message is already deleted, so this time it is throwing file not found error.
Log
--------
15:51:25.200 ERROR [bwEngThread:In-Memory Process Worker-2] com.tibco.bw.core - TIBCO-BW-CORE-500050: The BW process [webservicecontext.module.SetEmployee] instance faulted, JobId [bw0a100], ProcessInstanceId [bw0a100], ParentProcessInstanceId [-], Module [ACKFailure.module:1.0.0.qualifier], Application [ACKFailure:1.0].
<CausedBy> TIBCO-BW-CORE-500064: Activity [Root Task] error.
<CausedBy> com.tibco.bx.core.faults.BxException: TIBCO-BW-BINDING-SOAP-500270: Failed to acknowledge Service Request message for Operation
[{http://www.deb.com/employee/service/1}AddEmployee], SoapServiceBinding [EmployeeSOAPJMSServiceBinding], Application [ACKFailure:1.0] due to exception [javax.jms.IllegalStateException]
TIBCO support Team revert on this issue. According to them this behaviour is not observed in TIBCO BW 6.4.0. I am yet to check this scenario on TIBCO BW 6.4.0
Hot deployment in shared module is not working.
In design time we can test the BW6 application in debug mode. If some changes are made on the BW 6 process while the engine is running, BW 6 studio take the changes and these changes are automatically applied to the running instances.But this behaviour is not working, when some changes are done in the shared module which is part of the running application. Below are the steps those are executed.
1. BW6 component started in Studio in debug/test mode.
2. Some changes are made in one of the process in the shared module (which is part of the running application)
3. The change is updated by BW6 runtime (also, shown in the console logs), where as all the JMS SOAP receivers are disabled.
4. No consumers are available in the EMS queue receivers.
SOAPBinding not in synch with service interface
While using BW 6.3.1 and an unexpected behavior was found for the SOAPBinding. Below there is a description on how to reproduce the issue and what we have found out.
Steps performed:
1) Create a new BW Process Service
2) Create a service entry point with one operation (called Operation1 with in/out elements as simple string).
3) Associate a WSDL with a separate schema
4) Implement a constructor and map the output string
5) Create a SOAP binding with HTTP transport
6) Open the abstract WSDL and add a new operation (Operation2-OneWay with only an input string)
7) Add the implementation of the Operation2-OneWay
At this point in time you can experience:
8) The SOAP Binding is not updated with the new Operation2-OneWay.
-; There isn't way to get the SOAP Binding again in synch with the service interface. Even cleaning again the project.
-; There aren't errors in the project.
-; The only solution is to remove the existing binding and create a new one
-; Remove the old SOAPBinding, save the project, clean it and add a new SOAPBinding. The list of the operations is not in synch with the service interface. On the SOAPbinding there is Operation1 and "operation" as one way operation, but the real name should be "Operation2-OneWay"
9) Remove the operation from the service interface. The WSDL is partially updated. The one way operation doesn't appear anymore, but the message type is still there:
;/wsdl:message;
;wsdl:message name="Operation2-OneWayRequest";
;wsdl:part element="extns:Operation2-OneWayRequest" name="parameters"/;
;/wsdl:message;
and also the schema keeps the element type
;element name="Operation2-OneWayRequest";
;complexType;
;sequence;
;element name="in" type="string"/;
;/sequence;
;/complexType;
;/element;
Message is confirmed on the queue with SOAP over JMS even without Confirm activity
While using BW 6.3.2 and an unexpected behavior was found for the SOAP over JMS acknowledge mode. Below there is a description on how to reproduce the issue and what we have found out.
Steps performed:
1) Create a new BW Process Service with a SOAP over JMS receiver.
2) Mapped the output without adding a confirm activity palette
3) Added a SOAP binding with JMS and selected either the Client or the TIBCO EMS Explicit Ack Mode
4) Created a client process to test it
5) Run the process and we figured it out that the processes where completed successfully and the messages have been acknowledged on the queue, regardless the fact that the Confirm activity was not in the process
Work around
-----------------
SOAP -over-JMS with Explicit Client ACK or client ACK mode works in the same fashion as webService implemented with "SOAP Event Source". The message is always acknowledged properly unless an underhanded exception is thrown. So, we modified the implementation is the following way.
