How can we achieve load balance and fault tolerance of SOAP over HTTP web service in the Tibco

domain?

Details

Resolution:
You can initiate Fault Tolerance of the BW Engine at deployment time in TIBCO Administrator. When you
have two Engines in Fault Tolerant mode, only one of the Engines will be active at any given time. When the
first Engine goes down the Fault Tolerant Engine will become active.

For Load Balancing SOAP Servers,  BW does not handle the SOAP load balancing itself. You will have to use
the standard HTTP load balancers available from a third party. You can select one of the following external
mechanisms:

1). Hardware Load Balancer (eg., Local Director) .

2). Software Load Balancer (eg., Resonate Software) .
3). DNS Round Robin (Most DNS servers will support this).

The following link could be useful for Apache as a reverse proxy server. http://raibledesigns.com/tomcat/

In BW you cannot have the Engines be both Fault Tolerant and Load Balanced. What you will have to do is:

- Have two independent BW Engines (with different subject prefixes) as primary servers for Load Balancing.
- Have a Fault tolerant engine for each primary sever.

Basically you will have to have two pairs of BW Engines. However, only two Engines will be active at any
given time.

JDBC Query is used to Allow a query configured at design time to be executed. The values can be
modified per job based on prepared parameters.

SQL Direct on the other hand can have a fairly dynamic query since it's specified and constructed at
runtime for every job.

JDBC Query is better performant since it caches queries

edeliveryDelay

When redeliveryDelay is set, the EMS server waits the specified interval before returning an
unacknowledged message to the queue.
When a previously delivered message did not receive a successful acknowledgment, the EMS server
waits the specified redelivery delay before making the message available again in the queue. This is most
likely to occur in the event of a transaction rollback, session or message recovery, session or connection
close, or the abrupt exit of a client application. However, note that the delay time is not exact, and in most
situations will exceed the specified redeliveryDelay.
Note: The redelivery delay is not available for routed queues.
The value can be specified in seconds, minutes, or hours. The value may be in the range of 15 seconds
and 8 hours.
You can set redeliveryDelay using the form:

   redeliveryDelay=time[sec|min|hour]

where time is the number of seconds. Zero is a special value that indicates no redelivery delay.
You can optionally include time units, such as sec, min, or hour describe the time value as being in
seconds, minutes, or hours, respectively. For example:

   redeliveryDelay=30min

specifies a redelivery delay of 30 minutes.

During the delay interval, messages are placed in the $sys.redelivery.delay queue. This queue can
be browsed, but it cannot be consumed from or purged. However, purging the queue from which the
delayed message came, or removing the message using its message ID, immediately removes that
message from $sys.redelivery.delay.
Note: While a message is on the $sys.redelivery.delay queue, it is not on the queue from which it
came and so it is not included in statistical message counts. This
includes maxmsgs, maxbytes, flowControl, and so on.

tibco ems delivery delay

MS Send Message

JMS Send Message is a synchronous activity that sends a message to the specified JMS destination.

General

Delivery Delay(msec) Delivery Delay feature, which is supported in EMS, is now supported in TIBCO
BusinessWorks™ Container Edition 6.4.2.

It is the minimum length of time in milliseconds that must elapse after a message
is sent before the JMS provider may deliver the message to a consumer.

n order for reducing the client’s waiting time in a server client scenario
For a queue based messaging only the prefetch value allows the the server to send messages in batches
so that the message will be ready for the client when ever the client is ready. For automatic fetching its >1
and for disabling its "none".
More on for simple understanding , Prefetch value help to reduce client waiting time . It can
fetch(Consume) the messages faster than publisher send a messages to queue based on prefetch value
set per requirement.

his property used to limit the messages fetched from EMS queue by the receiver at a time. The
consumer will not be able to fetch more than the number of messages specified by prefetch.

Automatic Fetch Enabled To enable automatic fetch, set prefetch to a positive integer. Automatic fetch ensures
that if a message is available, then it is waiting when client code is ready to accept one. It can improve
performance by decreasing or eliminating client idle time while the server transfers a message. However, when a
queue consumer prefetches a group of messages, the server does not deliver them to other queue consumers
(unless the first queue consumer’s connection to the server is broken).

Flow Control In some situations, message producers may send messages more rapidly than message consumers
can receive them. The pending messages for a destination are stored by the server until they can be delivered, and
the server can potentially exhaust its storage capacity if the message consumers do not receive messages quickly
enough. To avoid this, EMS allows you to control the flow of messages to a destination. Each destination can
specify a target maximum size for storing pending messages. When the target is reached, EMS blocks message
producers when new messages are sent. This effectively slows down message producers until the message
consumers can receive the pending messag

flowControl The flowControl property specifies the target maximum size the server can use to store pending
messages for the destination. Should the number of messages exceed the maximum, the server will slow down the
producers to the rate required by the message consumers. This is useful when message producers send messages
much more quickly than message consumers can consume them. Unlike the behavior established by the
overflowPolicy property, flowControl never discards messages or generates errors back to producer.
Resolution:
Description:
============
JMSCorrelationID of queue Requestor in TIBCO Businessworks does not work well when using
the static destination.

Environment:
===========
Version: all        
Hardware: all      
OS: all

Symptoms:
========
“JMS Queue Requestor” activity uses temporary destinations to ensure that reply messages are
received only by the process that sent the request. It will not work well when using the static
destinations

Resolution:
==========
The JMSCorrelationID was used to link the response message with the request message. If you
did not set this value, the response message’s JMSCorrelationID should be the same as request
messageID . Note that the EMS server will not actively check JMSCorrelationID for request/reply,
even if the JMSCorrelationID is different. The requestor will receive any reply on that destination.

- “JMSCorrelationID” is used to link a response message with its related request message. For
this you need to use the message selector for the correlation ID set while sending the request
message if you want set correlation ID.

- “JMS Queue Requestor” activity uses temporary destinations to ensure that reply messages are
received only by the process that sent the request. It will not work when using static destinations
as there is no facility to provide the message selector, which is needed for correlation ID.

- In this case you can use a combination of “JMS Queue Sender” and “Get JMS Queue Message”
in Request and “JMS Queue Receiver” and “Reply to JMS Message” activities to use a correlation
id along with message selector. (Refer to the attached project. Filename: JMSCorrelationID.zip).

Reply to JMS message Tibco

Reply To JMS Message is a synchronous activity that sends a reply to a previously received JMS
queue or topic message. The Reply For Event field in the General tab lists the activities that can receive
the JMS message. The activity you select determines the response of the reply message.
Difference between Get JMS Queue Message activity and Wait for JMS Queue message activity

Details

Resolution:
The "Get JMS Queue Message" activity uses the pull mechanism to receive messages from the JMS server.
So if there is a message in the queue, it will be received immediately. If there is no message,  this activity will
wait for a message to arrive at the queue or timeout, whichever occurs first. It is not a good idea to set
timeout to 0 or blank, else this activity will wait indefinitely until a message arrives at the queue.  The "Wait
for JMS Queue Message" activity works in passive mode. It is notified once a message arrives on the specified
queue.

Another difference is on the number of message these activities can process.  Suppose the Message Selector is
not used, when bw engine starts up the "Get JMS Queue Message" activity in this engine receives only one
message from queue,  but the "Wait for JMS Queue Message" activity consumes all messages from the
queue.

Example usage of the "Wait for JMS Queue Message" activity could be that when you send out a request to a
request queue and then expect a response from a response queue. In this case, you can use Candidate Event
Key and Key fields to get the correct response message from response queue.

KEYWORDS:GET JMS QUEUE MESSAGE,WAIT FOR JMS QUEUE MESSAGE, DIFFERENCE

n. EMS provides a server-based solution to this problem. You can create bridges between destinations so that
messages sent to one destination are also delivered to all bridged destinations.

 How to configure an EMS route.

Description:
=========
1). Enable routing in the tibemsd.conf file on both servers (routing=enabled).

2). Create the route on both servers to point to the other server (create route name url=URL
zone_name=zone_name zone_type=1hop|mhop properties)

Where:
  
name is the name of the server at the other end of the route; it also becomes the name of the route.

URL specifies the other server by its URL—including protocol and port.

zone_name specifies that the route belongs to the routing zone with this name. When absent, the default value
is default_mhop_zone

The zone type is either 1hop or mhop. When omitted, the default value is mhop.

properties is a space-separated list of properties for the route. Each property has the syntax:
  prop_name=value

If authorization is enabled on any routed EMS Servers, after setting the server password, you also must make
sure that on that server there is a user/password that matches the name of the EMS Server that you are
creating a route to. Assume  
there are two servers named EMS-SERVER1 and EMS-SERVER2 and in both of them authorization is
enabled. In that case, in the users.conf of EMS-SERVER1 you should have a user EMS-SERVER2 with
password of EMS-SERVER2, and in users.conf of EMS-SERVER2, you should have a user called EMS-
SERVER1 with password of user EMS-SERVER1.

3). Use the tibemsadmin tool to connect to EMS-SERVER1 and execute the following command:

a). set server password=&ltserver1_password>

b). create user EMS-SERVER2 password=&ltserver2_password> (if user "EMS-SERVER2" is not already
created) or

c). set password EMS-SERVER2 < server2_password> (if user "EMS-SERVER2" has already been created
in user.conf).

d). set server authorization=enabled

4). Use the tibemsadmin tool to connect to EMS-SERVER2 and execute the following command:

a). set server password=&ltserver2_password>

b). create user EMS-SERVER1 password=&ltserver1_password> (if the user "EMS-SERVER1" is not
already created) or

c). set password EMS-SERVER1 < server1_password> (if user "EMS-SERVER1" has already been created
in user.conf).

d). set server authorization=enabled

There are sample config files for working with routes, "tibemsdroute-1.conf" and "tibemsdroute-2.conf" in
the &ltEMS>/bin directory for reference.

WADL is an XML file-format,

. 2. WADL is a machine-readable description of HTTP based REST web services.

whereas WSDL is an XML language for describing web services. 2. WADL is a machine-readable
description of HTTP based REST web services.

WSDL The Web Service Description Language (WSDL) is an XML vocabulary used to describe SOAP-
based web services. WADL The Web Application Description Language (WADL) is an XML vocabulary
used to describe RESTful web services.

Click to see full answer.

Also asked, what is WADL and WSDL?

The Web Application Description Language (WADL) is a machine-readable XML description of HTTP-
based web services. WADL is the REST equivalent of SOAP's Web Services Description Language
(WSDL), which can also be used to describe REST web services.

Subsequently, question is, what is difference between REST and

SOAP? KEY DIFFERENCE SOAP stands for Simple Object Access Protocol whereas REST stands for
Representational State Transfer. SOAP only works with XML formats whereas REST work with plain text,
XML, HTML and JSON. SOAP cannot make use of REST whereas REST can make use of SOAP.

Correspondingly, what is the use of Wadl file?

WADL is a machine readable XML description of HTTP based web-services. WADL is intended to

simplify the reuse of web services that are based on the existing HTTP architecture of the Web. It is
platform and language independent and aims to promote the reuse of applications beyond the
basic use in a web browser.

The objective of Swagger is to create a “RESTful contract for your API, detailing all of its resources and
operations in a human and machine-readable format.” In this sense it is a functional equivalent of
WSDL documents for SOAP, providing automatically generated descriptions that make it easier to
discover

Swagger is an Interface Description Language for describing RESTful APIs expressed using JSON.
Swagger is used together with a set of open-source software tools to design, build, document, and use
RESTful web services. Swagger includes automated documentation, code generation, and test-case
generation. Wikipedia
Sending Data in the HTTP request The Invoke REST API activity contains different types of parameters for
sending data in a request: •

Template—this parameter is displayed when using a WADL file or a Swagger file to invoke RESTful web
service.

• Query

• Header

Body—this parameter contains four child parameters: — Form — Text — Binary — Multipart Describing
RESTful Web Service with WADL or Swagger Files If the protocol type is WADL or Swagger, and a WADL
file or Swagger file is given, the WADL file or Swagger file will be mapped to the input parameters in the
Input tab. Table 11 shows the rules for mapping a WADL file to the input parameters. You are not
allowed to alter the structure of the HTTP request message in the Input tab. If the data structure in the
WADL file or Swagger file does not match the RESTful web service, edit the elements in the file, and then
click Reload.