TIBCO BW6.3.2 Malfunctioning Features

"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.

TIBCO Buinessworks 6.2.2 Issues

1.       The operation is removed from the interface definition of the sub process when the corresponding WSDL file is relocated.

a.       Create a XSD file.

b.      Right click on process folder àNewàBusinessWorks Sub Process

c.       In the popup window, provide the Process name and select “Create Service Interface” as “Custom” à click “Next”

d.      In the next window provide interface name and operation name

e.      Provide the XSD elements for “Input Message” and “Output Message”.

f.        Click Finish.

g.       Sub process would be created along with the WSDL. The WSDL is placed at pre-defined folder “Service Descriptors”

h.      Create a folder in the “Service Descriptors” and move the WSDL to the new folder.

i.         Some errors appear on the WSDL. To remove the error clean the project.

j.        The operation is removed from the interface definition of the subprocess.

Resolution for BW 6.2.2

a.       Create the WSDL first

b.      Please to the proper location

c.       With creating the subprocess, select the option “Use an existing WSDL interface for service”.

d.      Select the respective Service from the list.

e.      Click Finish.

NOTE: this issue is fixed with the BW 6.3.1 based on Eclipse 4.4.1

2.       While invoking a sub process which has no output, the invocation activity shows error, although the mandatory inputs are mapped properly.

Resolution for BW 6.2.2

a.       Search for

<bpws:variable messageType="ns8:InvokeLogProcessRequest"

            name="InvokeLogProcess-input" sca-bpel:internal="true"/>

                                <bpws:variable name="InvokeLogProcess" sca-bpel:internal="true"/>

b.      Delete the highlighted text.

c.       Again search for

<bpws:invoke

                        inputVariable="InvokeLogProcess-input"

                        name="InvokeLogProcess"

                        operation="PublishRequest"

                        outputVariable="InvokeLogProcess"

                        partnerLink="PublishRequest"

                        portType="ns8:Logger" tibex:xpdlId="a961ea4f-10a6-48c8-95c8-2559fd6e5aa7">

d.      Delete the highlighted text.

e.      Save the file. And refresh the BW6 process.

NOTE: this issue is fixed with the BW 6.3.1 based on Eclipse 4.4.1

3.       Difficult to rename an existing REST operation name.

Simulation

a.       Create a new REST service by choosing the operation GET and rest of the parameters as the default ones.

b.      An operation called “get” gets created as shown above.

c.       If the operation is  rename from “get” to say “retrieveData” in the WSDL.

d.      The process shows  that, the name has been updated.

e.      In the Components tab click if you look at the operation name it’s still ‘get’ and Null Pointer Exception pops up.

Resolution in BW 6.2.2

a.       Rename the operation using the properties tab. Not in WSDL.

b.     

NOTE: this issue is shows up differently in BW 6.3.1 based on Eclipse 4.4.1. You cannot change the rest operation name. An error window pops up as soon as you confirm the rename action and there aren’t changes. If you try to manually edit the “.json” service description also doesn’t see the changes and you can’t rename the REST service operation as well.

A Tibco SR has been raised (676953) – Defect id is - AMBW-21864, it will be fixed in BW 6.3.2

4.       Explicit client acknowledgement mode works only with JMS receiver activity.

Simulation

a.       Create a process.

b.      Create a SOAP bindings in the components for that process

c.       Select the transport JMS.

d.      Select acknowledge mode  as  “Tibco EMS Explicit Client”.

e.      Do not use confirm activity in the corresponding process.

f.        Test the service. It is found that the JMS message is acknowledged although no confirm activity is used.

Resolution for BW 6.2.2

                No work around

NOTE: this issue is still present in BW 6.3.1 based on Eclipse 4.4.1. A Tibco SR has been raised (679556 – Defect Id is: AMBW-20428)

               

5.       Adding a new operation to an existing service in the abstract WSDL gets reflected in the process but does not appear in the service bindings.

Simulation

a.       Open an existing WSDL file in the service descriptor folder.

b.      Add a new operation to the in the WSDL interface definition.

c.       If we open up the corresponding process the new operation name will appear on the service definitions.

d.      Open the SOAP bindings in the component tab and it could be seen that the new operation name is missing in the Endpoint bindings. 

e.      Note: removing operations from the WSDL design panel doesn’t reflect in an update of the SOURCE WSDL. They are still present in it.

Resolution for BW6.2.2 and BW6.3.1

Delete the existing SOAP bindings and create them from the scratch.

This approach needs to be followed whenever a new operation is added.

NOTE: this issue is still present in BW 6.3.1 based on Eclipse 4.4.1. A Tibco SR has been raised (676637 - DefectID = AMBW-22291).

6.       Addition of a new field in the existing service interface needed changes to be done at the source level.

Simulation

a.       Open an existing schema (XSD) definition and add a new element.

b.      The changes are reflected in the process definition where the schema is being called.

c.       Open up the service bindings section in the “Component” tab.

d.      Notice that the new element name is missing in the parameters section.

Resolution

By no means can one add the new elements in Parameters section directly except to add it by using the source code available in the “module.bwm” tab.

7.       Generation of the concrete WSDL results in missing references.

Simulation

a.       Create a process definition that uses an abstract WSDL containing header and resultaat information which has been imported in the schema definition.

b.      Go to the components tab and generate the concrete WSDL file.

c.       The BW6 generated concrete WSDL is erroneous. One can check this using SOAP UI tool.

Resolution for BW 6.2.2

We need to include the “header” element type information in the generated concrete WSDL file by editing it manually.

                NOTE: this issue is fixed with the BW 6.3.1 based on Eclipse 4.4.1

8.       Unable to change the Header namespace for the REST resource.

Simulation

a.       Create a new REST resource.

b.      BW6 will automatically create the Header schema with name “RESTSchema.xsd”.

c.       Open up the XSD  and see that target namespace is http://tns.tibco.com/bw/REST

d.      Try to change this namespace to a meaningful name.

e.      Now test the service.

f.        During runtime, it would throw an error.

Resolution in BW 6.2.2

                 No work around. The namespace cannot be changed.

                NOTE: this issue is still present in BW 6.3.1, a TIBCO SR (677411) has been raised.

9.       Shared module changes are not automatically reflected in other projects

Simulation

a.       Create a project which includes a shared module.

b.      Add a new property in the shared module in a different workspace.

c.       Refresh the workspace created at step a.

d.      An error pops up “Application configuration error. A set of module properties included in the BW application [xxxxxx.application] are not in sync with the module properties configured for the module [XyzSharedModule”.

Resolution in BW 6.2.2

a.       Open “Includes” tab present under the projectname.application.

b.      “Remove the shared module.

c.       Save the project.

d.      Add the shared module once again.

NOTE: this issue is fixed with the BW 6.3.1 based on Eclipse 4.4.1