Channel Keys allow automatic purging of duplicate metadata
values based on a channel key name and a depth.
Using channel keys to automatically purge redundant
data
For example if you have a channel called BondDefinitions
where each Bond should have 1 and only 1 definition
you could enforce that by using a channel key. So in
the above example you would create your BondDefinition
channel as shown in the following Realm Manager screen
shot:
This means that as soon as an event is published to
the BondDefinitions channel with a Dictionary
entry called BONDNAME, the server checks to see
if there is another event with the same value for that
key. For example if an event is published with BONDNAME=bondnameA
and there is already an event with BONDNAME=bondnameA,
then the old event will be removed and the new one will
take its place as the latest definition for bondnameA.
Another example would be if you wanted to keep the
latest definition and the 1 before it you would create
the channel key with depth 2 as in the following screen
shot (implying that maximum 2 events with the same value
for key name BONDNAME can exist on the channel)
Using channel keys to manage message state
from a queue consumer
Another example use of channel keys would be to use
them to manage message state in a scenario where messages
are being consumed from a Nirvana queue and then published
to another external service. If the publish to an external
service failed you may wish to re-publish the message
to the queue. This can be achieved by publishing the
event to a state channel with various dictionary entries
recording the state of the message delivery.
Using an approach like this is more powerful then client_ack
functionality on the queue because of the ability to
support multiple message states. In addition this approach
also overcomes the problem with JMS where an ack implicitly
acks all previous events delivered to your JMS session.
In a multi-consumer JMS session you may want to continue
acking messages after one consumer has failed to call
ack.
For example if you have the following states defined:
MSG_CONSUMED_FROM_Q=0
MSG_AWAITING_RESPONSE_FROM_DETINATION=1
MSG_FAILED_RESPONSE=2
MSG_SUCCESS_RESPONSE=3
If your service consumes an event with FOO_MSG_ID=10
from a queue you will publish and event with the following
keys to the state channel:
FOO_MSG_ID=10
FOO _MSG_STATE=0
Once you have sent the event to the desination service
you will publish another event to the state channel
with the following keys
FOO_MSG_ID=10
FOO _MSG_STATE=1
The nirvana server will automatically purge the previous
event containg FOO_MSG_ID=10 (Because you have defined
a depth of 1 for that key, it will only keep one event
with that value).
If you then received an error back from the destination
service you would publish another event to the state
channel with the following keys
FOO_MSG_ID=10
FOO _MSG_STATE=2
If your initial publisher to the nirvana queue has
a thread consuming from the state channel with a selector
of FOO_MSG_STATE=2 it will immeadiately get called back
with any events where delivery failed. You can then
republish it.
Additional dictionary entries could be used in the
steps above to record which queue it was consumed from
and which service it was rejected from. You could also
include the error returned etc. thereby giving you more
granular access to overall system performance and the
ability to add logic in the publisher to attempt an
alternative route based on any error reported.
|
