Creating and Modifying Destinations ,Creating Secure Destinations and Wildcards

-

Ø  Destinations are typically "static" administered objects that can be stored in a JNDI or LDAP server. Administered objects can also be stored in the EMS server and looked up using the EMS implementation of JNDI
Ø  Create a queue using the create queue command
Ø  Create a topic using the create topic command.
Ø  create a new queue named myQueue,enter:
§  create queue myQueue
Ø  To create a topic named myTopic, enter:
§  create topic myTopic
Ø  The queue and topic data stored on the EMS server is located in the queues.conf and topics.conf files, respectively.
Ø  Use the show queues and show topics commands to list all of the queues and topics on your EMS server.
Ø  Use the show queue and show topic commands to show the configuration details of specific queues and topics.
Ø  Properties can be specified when creating the queue or topic or modified for an existing queue or topic using the addprop queue, addprop topic, setprop queue, setprop topic, removeprop queue, and removeprop topic commands.
Ø  For example, to discard messages on myQueue when the number of queued messages exceeds 1000, you can set an overflowPolicy by entering:
addprop queue myQueue maxmsgs=1000,overflowPolicy=discardOld
Ø  To change the overflowPolicy from discardOld to rejectIncoming, enter:
addprop queue myQueue overflowPolicy=rejectIncoming
Ø  The setprop queue and setprop topic commands remove properties that are not explicitly set by the command.
Ø  For example, to change maxmsgs to 100 and to remove the overflowPolicy parameter, enter:
setprop queue myQueue maxmsgs=100









Creating Secure Destinations
Ø  By default, all authenticated EMS users have permissions to perform any action on any topic or queue. You can set the secure property on a topic or queue and then use the grant topic or grant queue command to specify which users and/or groups are allowed to perform which actions on the destination.
Ø  The secure property requires that you enable the authorization property on the EMS server.
Ø  For example, to create a secure queue, named myQueue, to which only users "joe" and "eric" can send messages and "sally" can receive messages, in the EMS Administration Tool, enter:
§  set server authorization=enabled
§  create queue myQueue secure
§  grant queue myQueue joe send
§  grant queue myQueue eric send
§  grant queue myQueue sally receive
Wildcards
Ø  Use wildcards when specifying statically created destinations in queues.conf and topics.conf. The use of wildcards in destination names can be used to define "parent" and "child" destination relationships, where the child destinations inherit the properties and permissions from its parents.
Ø  Wildcards * and > To understand the rules for inheritance of properties, it is important to understand the use of the two wildcards, * and >.
Ø   The wildcard > by itself matches any destination name.
Ø   When > is mixed with text, it matches one or more trailing elements.
For example:  foo.>
§  Matches foo.bar, foo.boo, foo.boo.bar, and foo.bar.boo.
Ø   The wildcard * means that any token can be in the place of *.
 For example: foo.*
§  Matches foo.bar and foo.boo, but not foo.bar.boo.
§  foo.*.bar
§  Matches foo.boo.bar, but not foo.bar.

Comments

Post a Comment

Popular posts from this blog

TIBCO EMS FAQ -5

-
131) What happens if the message expires/exceeded the value specified by maxredelivery property on queue? If the jms_preserve_undelivered property is set to true, then it moves he message to undelivered message queue, if set to false, the message is deleted by the server. 132) What are the wild cards that we use in ems?how do they work for queues and topics? *,> We can subscribe to wildcard topics, but cant publish to them. Where as in case of queues we can’t either send /receive. 133) Are bridges transitive? No 134) Tell me about flow control on destinations? Sometimes the producer may send messages faster than the consumers can receive them. So, the message capacity on the server will be exhausted. So we use flow control. Flow control can be specified on destinations. 135) Tell me about flow control on bridges and routes? Flow control has to be specified on both sides of bridges where as on routes it operates differently on sender side and receiver side. 136) Nam...
Read more

TIBCO EMS FAQ -4

-
101) What are the permissions that you can grant to users to access topics? a. Subscribe b. Publish c. Durable d. Use durable 102) What is the difference between Queues and Topics? Queue • Guaranteed Service • Only the Target gets the message (One message per Consumer) • Uses Peer-to-Peer Mode to deliver messages • Blocking • Load Balancing is possible Topic • Reliable Service • Everyone active gets the message (One message may Consumers) • Uses Pub / Sub mode to deliver messages • Non-Blocking • Load Balancing is not possible. 103) What is the use of secured queues and topics? Setting ‘secure’ property to queues/topics can restrict unauthorized users from publishing/sending and subscribing/receiving the messages. 104) What are acknowledgement modes and where do you set them and what is the applicability of each mode? Ans:The acknowledge mode for incoming messages. Can be one of the following: • Auto — the message is automatically acknowledged when it is re...
Read more

TIBCO BW FAQ -2

-
31) What happens if you use check point activity first and confirm next? Ans)In the case of confirmable messages , you must consider the consequences of performing a checkpoint before or after a Confirm activity. If the checkpoint is taken before the Confirm activity, then a crash occurs after a checkpoint but before a confirm, the original message is resent. In this case, the restarted process can no longer send the confirmation. However, a new process is started to handle the resent message, and you can implement your process to handle the restarted and new processes appropriately. If the checkpoint is taken after a Confirm activity, there is potential for a crash to occur after the Confirm but before the checkpoint. In this case, the message is confirmed and therefore not redelivered. The process instance is not restarted, because the crash occurred before the checkpoint. You must consider the type of processing your process definition performs to determine when a checkpoint i...
Read more