TIBCO Administrator Temporary Files

TIBCO Administrator use the temporary folder (usually /tmp on Unix machine) to save configuration data, which might be required during re-deployment or roll-back of a deployed application.

 If files from the temporary folder are tampered, then TIBCO Administrator will fail to re-deploy applications. This can happen if for example, the machine is rebooted, which deletes all files from the temporary folder.

The work-around to avoid this issue is to have TIBCO Administrator use another folder to store its temporary data. This must be done after the domain and the primary TIBCO Administrator Server has been created:

Complete the following activities on the machine that will run the Admin.

1. Connect as login  to the machine.
2. Stop TIBCO Administrator Server if it is already running:
3. Open the file “/opt/tibco/administrator/5.2/bin/tibcoadmin_<DOMAIN>.tra” with vi. If the version of TIBCO Administrator is 5.3, the file is “/opt/tibco/administrator/domain/<DOMAIN>/bin/tibcoadmin_<DOMAIN>.tra”.
4. Add the following text at the end of the file (if not present):

# redirect temp to /opt/tibco/tra/domain/<DOMAIN/tmp

java.property.java.io.tmpdir=/opt/tibco/tra/domain/<DOMAIN>/tmp

###############################################################################

###  END OF FILE  #############################################################

###############################################################################

5. Create the folder “/opt/tibco/tra/domain/<DOMAIN>/tmp”.
6. Restart TIBCO Administrator.

TIBCO Admin -Transport options local / rv / http

When TIBCO Administrator deploys an application, it creates an application repository which contains information about the application configuration.

We can view and change certain aspects of the application repository.
 

TIBCO Admin -Transport  options local / rv / http

In TIBCO Admin , browse new ear file and  go to the path "Edit Application Configuration > Advanced tab"

There are two sections

Global Variables
TIBCO BusinessWorks and Adapters Deployment Repository Instance    

under the section "TIBCO BusinessWorks and Adapters Deployment Repository Instance" there is Transport drop down box having the options local ,rv and http

This transport is that the administration server uses to communicate with the client application.

•  local

By default, the transport is set to local. This means that the application repository will be sent to the target machine. This allows the application to run independently of the administration server.

If you change the transport from local to another value, the application repository will not be pushed to the target machine, and the application will communicate with the administration server at runtime.
 

The local choice is supported only if the target machines have installed TIBCO Runtime Agent 5.3 or later.

•   rv

If rv selected, the client application will use TIBCO Rendezvous to communicate with the administration server.
 

• http

If selected, the client application will use HTTP to communicate with the administration server.

If administration domain is not initially enabled for HTTPS, and there are deployed applications in the domain that use HTTP to connect to the application repository, the service instances will not restart after they are shut down. In this case, you must redeploy each service instance after changing the transport to HTTPS.
 

The parameter  HTTP URL, HTTPS URL  is the URL on which the client attempts to connect to the server. What displays depends on whether you configured the server for HTTPS

Exporting an EAR file from Administrator

We can export an EAR file and its configuration file of deployed application in Admin with AppMange command

 AppManage -export -out c:\temp\ExampleApp.xml -genEar -ear c:\temp\ExampleApp.ear -app root/folder1/ExampleApp -user <username> -pw <password> -domain <domain name>

The deployment configuration file and EAR file are created in the c:\temp folder. The application is embedded in root/folder1/, which is relative to the Application Management root in the TIBCO Administrator GUI.

We can export all applications EARs in an administration domain using the appManage -batchExport option.

Example,

AppManage -batchExport -user <user name> -pw <password> -domain <domain name> -dir c:\temp\test

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 Administrator Fault Tolerant Setup

This is about the configuration and the implementation details for Administrator Fault Tolerant SetUp.

TIBCO Administrator is widely used to deploy BW processes to different machines in the domain. 

If the Administrator server is down for some maintenance or hardware related Issues the deployment cannot happen and roll out dates will be affected.

To over come this problem TIBCO has provided the feature of fault Tolerant setup

1.    Product Versions

Fault Tolerant SetUp is provided with TRA Versions 5.2 and above.

The XMLs are available under

$TRA_HOME/5.6/template/domainutility/cmdline folder.(modify the XMLs to the current environment.)

2.    Configuration

This section talks about the configuration steps.

1.Install Administrator on the secondary server
2.Run create domain  script on the secondary server 

cd /apps/tibco/tra/5.6/bin>
. /domainutilitycmd –cmdFile /apps/tibco/CreateDomain.xml

3. Run Add Secondary script on the secondary server

cd /apps/tibco/tra/5.6/bin
. /domainutilitycmd –cmdFile  /apps/tibco/ModifyLDAPConfiguration.xml

4.Start Administrator on the secondary server