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.

Configure Java VisualVM for BW6 analysis

Performance testing is one of the crucial activity to measure software  sustainability and reliability. To understand the memory usage of the BW6 software, the JAVA virtual machine needs to be monitored. In this post, the steps are described to configure an Java VirsualVM with TIBCO BW6 server.

1. Copy the AppNode configuration file at location /data/appdata/tibco/tibco/bw/<<version>>/domains/<<domainName>>/appnodes/<<appSpaceName>>/<<appNodeName>>/config.ini in a temporary location. 

2. Add the following properties to the file 

#JMX parameters for monitoring via Java VisualVM

Jmx.Enabled=true

java.property.com.sun.management.jmxremote=true

java.property.com.sun.management.jmxremote.port=9999

java.property.com.sun.management.jmxremote.authenticate=false

java.property.com.sun.management.jmxremote.ssl=false

3. Push this properties to the run time environment. (following the steps as mentioned in the blog tibco-bw6-application-runtime)

4. Download and install Java JDK 7 or higher.

5. Run the executable: "C:\<<installationLocation>>\jdk<version>\bin\jvisualvm.exe"

6. Click on Application --> Remote --> "Add Remote Host"

7.  Specify the host name. 

8. Right click on the host name and add JMS connection.

9. Provide the host and port number. This is the one that is used in the AppNode tra file JMX properties mentioned in #2 and click OK

10. It will take a few while before it makes the connection.

It should be noted that the  JMX connection should be recreated when ever there is a restart of AppSpace or the AppNode.

TIBCO BW6: Application runtime configuration

Configuration of FlowLimits on AppNode level:

I have worked till now with TIBCO BW6.3.2 along with TEA_2.2.0 . I have experienced that the TEA GUI do not allow to change the flow limits for the components. This need to be configured at config.ini file for the AppNode. Also, this setting s only applied specific component for which it is configured. In order to do the same, we have to execute the following steps.

1. Find the name of the component as shown in the figure below.

2. Copy the AppNode configuration file at location /data/appdata/tibco/tibco/bw/<<version>>/domains/<<domainName>>/appnodes/<<appSpaceName>>/<<appNodeName>>/config.ini in a temporary location. 

3. Add the property in the following format.

bw.application.job.flowlimit.<UsersBWApplicationName>[.<UsersBWApplicationVersion>][.<UsersBWComponentName>]=8

e.g

 bw.application.job.flowlimit.MSDMS_IS_REST-HTTP.application.1.0.ComponentDocumentbeheerAsync=15

4. At the end of the file add below 2 linein order to improve the performance:

bw.engine.event.publisher.enabled=false

bw.frwk.event.subscriber.metrics.enabled=false

5. Push the configuration to Run time environment, by executing the command (at location /data/appdata/tibco/tibco/bw/<<version>>/bin), 

./bwadmin config -d <<domainName>> -a <<appSpaceName>> -n <<appNodeName>> -cf /tmp/config.ini

6. Finally restart the appNode in order to apply the changes.

TIBCO BW6.x: Working with Context Resource

Configuring context resource with TIBCO BW Web Services is a bit tricky. When it comes to TIBCO BW6, it is even more tricky than BW5.

In order to configure a Web Service having Context resource in TIBCO BW6, following steps needs to be executed.

1.    Create BW6 project module in Eclipse.
2.    Create schemes  corresponding to the webservice request & response, and for the context as shown in the figure

Fig-1

3.   Create an abstract WSDL using the webservice schema. 

4.   Using the abstract WSDL create an Interface of the process as shown in the following diagram.

Fig-2

5.     Click on the Interface name (e.g. EmpServices), and select the "context" tab within "Properties" tab.

6.     Add the input and output context parameters using the buttons as shown in the figure.

7.      Configure activities GetContext(when input context parameter is used) and SetContext( when ouput context parameter is used). e.g 

8.      Open Module Descriptors-->Components. Select the component, and go to Bindings tab in the Properties tab. Then click on the Add Binding button.

9.      Select "SOAP Binding", and click on Finish.

10.    Set the Transport Configuration to JMS/HTTP, and configure it properly.

11.     Map the input and the output context as per requirement. as shown below. 

12.     Start BW6 application in from Eclipse in bebugger mode and test the service.

13.     Generate the Concrete WSDL for the client application as below.

For reference, you may download the project here.

DOWNLOAD

**Please feel free to ask/suggest as comment.

TIBCO Businessworks 5.13.0 & TLSv1.2

We always face issues when we have to configure certificates with TIBCO BW. This time we have to migrate from TLS 1.0 to TLS 1.2. I am documenting my experience for future references.

Scenario

 In our scenario we have to interact/call a third party application using SOAP over HTTPS using TLS 1.2. Certificates were provided by the vendor, and following TIBCO release notes, the code migrated to TIBCO BW 5.13.0 (although TLS 1.2 is compatible with TIBCO BW5.12 onwards) from 5.11.x.

While calling the third party application web service using “SOAP Request Reply” activity we were facing Timeout issues. When the traffic over the network was monitored using wireshark, it was noticed that, TIBCO was not using TLS v1.2 where as it was using v1.0.

Resolution

By default TIBCO BW 5.13 use TLS 1.0 for SSL communication, although it is compatible with TLS 1.2. In order to make it work with TLS 1.2, a JAVA property need to add in the bwengine.tra file (located in <<TIBCO_HOME>>\bw\5.13\bin). Viz,

java.property.TIBCO_SECURITY_VENDOR=j2se

This is very strange for us on that occasion as this information was nowhere mentioned in the TIBCO BW document

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

TIBCO Business Events: Execute External command

There are few occasions where Business Events need to execute operating system's commands. Just like TIBCO Business Works external command, TIBCO Business Events can also execute "External commands". But there are some limitations. Unlike TIBCO BW, TIBCO BE cannot invoke external command synchronously, so that the RTC should not hang or involve in long time execution.

To execute an external command, use
void System.exec(String command).

Depending on the Operating System the command text must be passed. for example

Windows
=======
System.exec("cmd /c START D:/STUDYMETERIAL/hello.bat");

Where "cmd /c" represent this is being executed in Windows.
START represents, the command is going to execute as a different process.
D:/STUDYMETERIAL/hello.bat is the batch file, containing the sequence of batch commands that need to execute.

Unix
=====
System.exec("sh D:/STUDYMETERIAL/hello.sh &");
Where "sh" represent this is being executed in UNIX as shell script.
"&" represents, the command is going to execute as a different process.
D:/STUDYMETERIAL/hello.sh is the Shell file, containing the sequence of shell commands that need to execute.