1) Login to Tibco AMX Administrator

2) Select Perspective:Configure Enterprise Assets –> Users & Groups –> Permissions  :

Select of  “Tibco Active Matrix Administrator Desktop” , “Configure Enterprise Assets”, “Environment Definition”, “Environment Details & all sub items under it which is till policy managers” ———  View Permission  (Do NOT remove existing permission; Do NOT select the check box)

3. Perspective:Configure Enterprise Assets –> Environments ———  View Permission  ( view permission will ensure that user will not be able to create nodes )

4. Perspective: Configure an Environment –> Nodes ———– Edit Permission ( Users will be able to deploy, undeploy, start, stop SAs mapped to the node)

5. Perspective : Deploy to an Environment –> SAs  ————- Owner Permission ( Users will be able to delete existing SAs, upload new SAs)

For training on TIBCO AMX Administrator mail us at [email protected]

TIBCO Product Suite For SOA:  
Follows Model Driven SOA Patterns. 

• Mediation Pattern using AM Service Bus
  • Location/Implementation Transparency
  • Transport Transparency
• Orchestration Pattern – AM BW
  • Help process talk to each other
  • One Level Interaction Based / Response
• Composite Patterns using AM Grid
  • SCA (Service Composite Architect)
  • Multiple Level of Interaction between Services 

Features: SOA Offerings 

• Service Virtualization
• Mediation
• Normalized Messaging
• Net and Java applications integration
• Communication 
• Virtualization
• Transaction
• Deployment
• Policy/Service Management
• Monitoring
• Debugging 

All in One Editor:  

• One Console and Single Application
• Create / Pub / Mgmt
• Design:
• Development:
  • Hand Code Biz Logic
  • Can reference other service in code via annotations
• Deployment:
  • Horizontal and Vertical
  • Service Cloud

Server Startup Sequence:

1. EMS Server
2. HSQL DB
3. Demon
4. Amx Admin Server
5. Login to Console
6. Node Running

Policy Manager 
To enforce SOA Governance. 
Guidelines:

• People and Process
• Reusable Serives
• Focus on Core Business
• Policy Mgmt Seprate 

Features:

• Registry
• Repository
• Policy Mgmt
• Service Mgmt

Operation Of Service

• Flow – policy / Service / app
• Policy Mgmt is seprate from service development
• Policy gets applied to service by Policy Mgmt
• This get tranverse effect on application using that service
• Policy Mgmt alows same service deployment with different policy without changing service.

SOA Policy Standards:

• WS-Policy:
  • Audting
  • Logging
  • Routing
  • Schema Validation
  • SLA
• WS-Security:
•   Authentication / Authentication / Digital Cert / Encriiption

For training on TIBCO AMX Administrator mail us at [email protected]

ISSUE:

I am able to start process sentinel successfully but I am  getting following error when I issue the command “swstart”
“Couldn’t display the status of the SWIPE processes. The System could not  be started as the process sentinels are not ready”
The “swstart -p” was already successful with the message
The Staffware swnod Process Sentinels service is starting. The Staffware  swnod Process Sentinels service was started successfully.
I was working in iprocess for 1 month and last week i changed my system  password.
Todat i restarted my system and unable to start iprocess engine.

Solution :

Most likely reason for the “Couldn’t display the status of the SWIPE processes.”  message that you got from swsvrmgr status is that there is a problem with the  events on your system.
As passwords have changed you probably need to change the password configured  in the events system.
Please reset the password in ControlPanel-> AdministrativeTools ->  Component Services, then navigate to: “ComponentServices”, “Computers”, “My  Computer”, “COM+ Applications”, then Right-Click “Staffware Events”,  “Properties” then go to the “Identity” tab and enter the new password here  & restart the event using the Shutdown and Start options in the Right-Click  menu on “StaffwareEvents”.
Then restart the iPE (swtop -p & swstart -p) and that should hopefully  solve your problem.  If not then I think you will need to send some debug logs  to TIBCO support to help diagnose the problem.



For training on TIBCO IProcess mail us at [email protected]

Problem Description

When a message is corrupted in the EMS database, you may notice the following errors in the EMS log file:

SEVERE ERROR: Exception trying to read message from store.
ERROR: Exception trying to create message from store: IO failed.
SEVERE ERROR: Exception trying to create valid messages record, Invalid message.
SEVERE ERROR: Persisted message possibly corrupt.
SEVERE ERROR: Exception trying to create valid messages record, Invalid message.

When your client tries to consume the message, you may get a “javax.jms.JMSException: Corrupted incoming data message” exception.

When a corrupted message is sent to a client and the client application cannot process the corrupted message properly, the client will block successive messages sent to it. These messages will remain queued on the server and will not be consumed by the client.

Possible Reasons for Generating Corrupted Messages in the EMS Datastore

1. A hardware problem with the physical disk: Media error
2. Forced unmount of a physical disk when the disk is in use, or a hard disk in operation having been unplugged.
3. Locking problem, the record in the db file has been modified by different applications/threads of the application at the same time.
4. The EMS server receives a corrupt message.
5. The machine was terminated abruptly. For example: a running system in operation has been unplugged, etc.

Solution

When one or more messages are corrupted and a client cannot receive the corrupted messages, you can do the following to delete the corrupted messages:

1. If you have already enabled the “track_message_ids” then you should try to remove the corrupt message as follows. To enable track_message_ids, in EMS main configuration file, set: in tibemsd.conf

track_message_ids=enabled.

a) Use the tibemsadmin command (available in EMS_Home\bin directory) to set server console_trace = +MSG (or set log_trace if that is more appropriate).

b) Use the tibemsadmin command to set addprop queue trace.

c) When the server delivers the corrupted message to the consumer, the server should print the message ID.

d) Use the tibemsadmin command “delete message” with that message ID to remove the corrupted message.

e) Undo steps a) and b), if needed.



For training on TIBCO EMS mail us at [email protected]