Difference between 'JMS Queue Message' activity and 'Wait for JMS Queue Message' activity

Wait for JMS Queue Message activity starts listening for messages from the time the BusinessWorks engine starts.
Get JMS Queue Message activity starts listening for incoming messages on the specified queue from the time the activity is triggered.

This can test by developing two simple example processes.i.e

First create a queue and place some pending messages in queue.

build a process_defention1 with one Wait for JMS Queue Message activity and configure it with queue name.
build a process_defention2 with one Get JMS Queue Message activity and configure it with queue name.

If we just start process_defention1 ,then the pending message count = 0. (No need to trigger Wait for JMS Queue Message activity)
If we just start process_defention2 ,then the pending messages count = not zero. it becomes zero when the Get JMS Queue Message activity triggered.

● Get JMS Queue Message activity can receive only one message from the specified queue at a time, when the Message Selector is not used.
● Get JMS Queue Message activity once triggered, then this  can either gets a message from the specified destination queue name before timeout and proceeds or it throws a timeout error and exits.

Wait for JMS Queue Message activity is non starter activity which behaves like queue reciever (starter activity) 

HTTP Methods

HTTP defines nine methods indicating the desired action to be performed on the identified resource.The list has mentioned below are the methods available for HTTP.

HEAD

Asks for the response identical to the one that would correspond to a GET request, but without the response body. This is useful for retrieving meta-information written in response headers, without having to transport the entire content.

GET

Requests a representation of the specified resource. Requests using GET (and a few other HTTP methods) "SHOULD NOT have the significance of taking an action other than retrieval".

POST
Submits data to be processed (e.g., from an HTML form) to the identified resource. The data is included in the body of the request. This may result in the creation of a new resource or the updates of existing resources or both.

PUT
Uploads a representation of the specified resource.

DELETE
Deletes the specified resource.

TRACE

Echoes back the received request, so that a client can see what (if any) changes or additions have been made by intermediate servers.

OPTIONS

Returns the HTTP methods that the server supports for specified URL. This can be used to check the functionality of a web server by requesting '*' instead of a specific resource.

CONNECT

Converts the request connection to a transparent TCP/IP tunnel, usually to facilitate SSL-encrypted communication (HTTPS) through an unencrypted HTTP proxy.

PATCH

Is used to apply partial modifications to a resource.
 

HTTP servers are required to implement at least the GET and HEAD methods and, whenever possible, also the OPTIONS method.

BW supports the METHOD= DELETE, POST, OPTIONS, HEAD, GET, PUT and  For other methods throughs the error code  "BW-HTTP-100000" "statusCode =405"

Enterprise Messaging System

TIBCO Enterprise Messaging Offering the EMS which extended the features of JMS

EMS is Enterprise Messaging System offering the fallowing list

• Message MODELS
• Delivery modes
• Message STRUCTURE
• Message DELIVERY MODES
• STORE
• Message ACKNOWLEDGEMENT
• Message SELECTORS
• Destinations
• TIBCO EMS Server -tibemsd
• Destination PROPERTIES
• Destination BRIDGES
• ROUTING
• Zones

EMS  have the three types of messagig models i.e.Point-to-Point (Queues),Publish Subscribe (Topics)
Multicast (Topics),

JMS provides 2 delivery modes for messages PERSISTENT,NON_PERSISTENT,EMS adds the 3rd delivery mode RELIABLE_DELIVERY

TIBCO BW Administration

TIBCO BW Administration is for User Management,Resource Management and Application Management

User Management -Managing authentication, roles, and users.
Resource Management -Managing machines, applications, and deployments.
Application Management -Creation, configuration, deployment, and monitoring of applications.

Roles and Responsibilities

 Various roles are recommended during a BW development project i.e.Domain Administrator,Project Administrator,Building of actual BW solution
 

Domain Administrator will Configures domains and grants access to different projects and runtime components.
 

Project Administrator  responsible for maintaining a specific server-based project and  maintains project templates, common services, global variables, shared resources, and shared schemas.
 

Developer  Builds the actual BW solution.Release / Test / Deployment Engineers optional roles responsible for testing, building EAR files, and deploying EAR files.


TIBCO Administration Domain

A collection of users, machines, and services managed by a TIBCO Administration Server and secondary servers may be added.Here cannot run a master and secondary on the same machine.
 

Multiple administration domains may exist on one server.Each domain must have an associated master server.Stores user and group information in the domain data store.This can also sync with LDAP for users and groups and supported LDAP servers include SunONE Directory Server, NovelleDirectory, and MS Active Directory.
 

By default, all machines that belong to a domain are expected to be on the
same network subnet.This can use RVRD if access across subnets is required.

Administrator Users and Roles

Maintain ACL’s by specifying users, roles, passwords, and authorization
levels.Administrator access is given on a per-UI element basis.i.e. Read, write, and administer access.
 

If using LDAP, you cannot create/rename users or change passwords in the
Administrator GUI.
– Performed through the corporate LDAP.
– Exception: May change the password for the original admin user.
Changing the original admin password also involves using the Domain Utility
on every machine in the domain.
– Ensure that the Administration Server is running!
Members of a child role are automatically members of each parent role.

TIBCO Deployment

Have two deployment methods i.e One-Click deployment and Scripting deployment

These are the general steps in process.

1. Create Project.
2. Build EAR from project.
3. Save EAR to Disk.
4. Upload EAR via HTTP.

• Domain Configuration
• Application Runtime RepoInstance

5. Configure Application
6. Deploy Application
7. Contact TSM for Deploy with Hawk
8. Execute Deployment Plugin
9. Save .tra file to disk (substituting from template .tra)
10. Contact TSM for Starting Engines with Hawk
11. Launch Engine
12. BW/Adapter reads configuration with RV or HTTP(s).
13. Monitor Application.
14. Gather stats with Hawk
15. Return runtime stats.


steps 5-11 are “One-Click Deployment” 

Command-Line Deployment

This is Full command-line deployment (scripting deployment) and available in Add-on pack on top of BW 5.x. and also Redeployment of an existing application is supported via command line.

However, with BW 5.x, can manually generate scripts to create an automated deployment process and can use  prepareDeployment.exe, redeploy.exe and deployment.xml, tibco.xml (global variables)


Redeployment

When a new archive is loaded, a diff of the new archive with the existing
archive is performed.New services are added, services not present in the new archive are removed.
 

If the shared configuration in the application archive or application level deployment descriptors are changed, all deployed service instances will be stopped (whether they are affected by the new archive or not), the repo instance is updated, and the client side .tra files are regenerated.
 

If the binary content of the service archive or the service level deployment descriptors are changed, then ONLY the affected service instances are stopped, and the client side .tra files for those affected service instances are regenerated.

The following configuration items must be performed in the Administrator:
– Binding services to machines.
– Hawk rulebase uploading.
– Service instance configuration (e.g. JVM properties).
– Fault-Tolerance.

TIBCO BW Monitoring

Monitoring takes two primary forms i.e Passive Monitoring and Active Monitoring.

Passive Monitoring includes the Heartbeats and Application State (e.g. Running)
 

Active Monitoring and Management inlcudes the Passive Monitoring,Also includes application enabling / disabling, and the ability to take proactive actions.
 

Monitoring BW deployments is typically a combination of BusinessWorks Administrator,Hawk / EM Advisor and Third Party Software (e.g. HP Openview, CA UniCenter)

Here the BusinessWorks Administrator is define Simple Monitoring Events (e.g. CPU, Disk, # Processes) and define Action(s) to take when event conditions are met (e.g. Alert,Email).

Can also Enabling Custom Hawk Plug-ins by Hawk Configuration

Set the Hawk Domain to the same name as the BW Domain.
Can now use BW Hawk Agent Microagents in custom rulebases.
Rulebases may be uploaded into the BW Administrator.

Can also enable custom plug-ins to be used in conjunction with the BW Hawk
Agent.

For example, the "tibjmsadmin.hma" plug-in may be added to the agent.
JMS Microagents will then be available through the Hawk Console in the BWAdministrator (if the Console is enabled), or through the Hawk Display.

Interview Questions

Which two input parameters are mandatory for the BuiIdEAR Utility?

Answer: 1. the location of the Tibco Designer project ,2. the project path of the Enterprise Archive Resource

Which two actions can be performed using coercions? 

Answer: 1. change the type of an element , 2. set the type of a undefined element

Which three Event Types are available when specifying a custom alert for a Tibco ActiveMatrix BusinessWorks application?

Answer: 1. Log Event,2. First Component Failure ,3. Subsequent Component Failure

You have created an XSD schema and a process definition in your Tibco ActiveMatrix BusinessWorks project. You need to share this schema and the process definition with other developers working on the same project for reuse. What should you use to accomplish this?

Answer: LibraryBuilder

Which two operations can be performed with the Tibco Domain Utility?

Answer:1. add a machine to the domain, 2. secure the domain using HTTPS

You have created a Web service to expose to several customers. In the implementation process, you need to access the username of each client invoking the Web service for authorization purposes. The username information is passed as a SOAP header in the SOAP requests. Which resource allows you to hold the header data from the incoming requests?

Answer:Context Resource

HTTP Error 'Method Not Allowed', BW Message Code 'BW-HTTP-100000' and statusCode is 405

Allowed methods in BW HTTP palette for attribute  METHOD='DELETE, POST, OPTIONS, HEAD, GET, PUT' and  For other methods generates the error code  "BW-HTTP-100000" and "statusCode =405"

' <MsgCode>BW-HTTP-100000</MsgCode>,<httpVersion>HTTP/1.1</httpVersion>                <statusCode>405</statusCode><server>Apache-Coyote/1.1</server> '

Below is the difference between METHOD="GET" (the default) and METHOD="POST" in HTTP Palette
 

METHOD="GET"  is the default  should be used for the case data retrivals (like select statement in JDBC) and the POST used for any action (like insert or update statements in JDBC)

The official recommendations say that "GET" should be used if and only if the form processing is idempotent, which typically means a pure query form.  There are, however, problems related to long URLs and non-ASCII character repertoires which can make it necessary to use "POST" even for idempotent processing.

BusinessWorks Process Design Methodology

Analysis

TIBCO BusinessWorks implicitly supports analysis and design by offering a set of objects representing services and activities as the basis for the project flow. The design team can use these objects during project design.

Domain Setup

A TIBCO administration domain is the set of software and hardware resources used by integration project.
Services Configuration

TIBCO BusinessWorks uses different types of services that can be accessed from within the process.

Process Design

Using the TIBCO Designer GUI, you create your business process using predefined activities and add

conditions and mapping as appropriate.

Deployment

The TIBCO administration domain supports a simple installation and deployment paradigm

Management and Monitoring

After the integration development team has configured and deployed the integration project, can use the TIBCO Administrator GUI for monitoring and management.

Components of TIBCO BusinessWorks Solution

Components & Description

TIBCO Designer

This is GUI that  supports adapter configuration, process design, and testing of the integration project in one easy to use interface and also can use TIBCO Designer in test mode to incrementally verify design during development

TIBCO BusinessWorks Engine

Runs the business processes in test mode and at run-time

TIBCO Administrator

Supports deployment, security administration, and monitoring and management of processes and machines.

TIBCO Administrator consists of the TIBCO Administration Server and the web browser based TIBCO Administrator GUI

TIBCO Runtime Agent (TRA)

Runs on each machine and executes scripts, sends alerts, and performs recovery as specified.

Integration Evolution

Connections are established between systems without a coherent strategy

Connectivity based,Connection technology is standardized SOA Oriented connectivity

Integration Infrastructure is Intelligent infrastructure with support for process automation, transformation etc.

Problems in IT today – that can be addressed by EAI

High Order processing cost.

Lot of redundant manual activities slow downs the overall order processing  performance.

No consolidated view of the customer.

Disparate systems across the organization don't give the complete integrated view.

High maintenance cost.

Managing and Monitoring of the system becomes difficult because of there is no single point of administration.