Jms-enqueue

From GreenVulcano Wiki
Revision as of 15:08, 3 February 2012 by Anonymous (talk)
Jump to: navigation, search

The jms-dequeue element allows you to perform a enqueue on a JMS destination. It is used by Channel and routed-dequeue.

GVBuffer fields will be made available through the JMS message properties:

Field JMS
system SYSTEM
service SERVICE
id ID
retCode RET_CODE
properties p$<property name> (only GVBuffer properties with names that are valid Java identifier are managed)

It has the attributes:

  • type: enqueue.
  • class: it.greenvulcano.gvesb.virtual.j2ee.JMSEnqueueOperation.
  • name: Operation name. Used in the Flow section to associate workflow nodes to VCL operations.
  • connection-factory: JMS connection factory JNDI name.
  • destination-name: Destination JNDI name. Set appropriately the destination-type parameter.
  • destination-type: Destination type. Default: queue.
    The attribute's admitted values are:
    • queue
    • topic
  • transacted: Specifies whether the enqueue has to open his own transaction or fall in a global transaction.
    • 'true' open his own transaction and do not fall in the global transaction.
    • 'false' fall in the active global transaction. Must be used a XA connection factory.
This parameter is not relevant if the connection factory is not XA. Default: false.
  • acknowledge-type:In transactional enqueue acknowledgment is managed by the application server.
    This parameter is meaningful only for non-transactional enqueue and can take the following values:
    • auto-acknowledge: the acknowledgment from application server is automatically given upon delivery of the message.
    • client-acknowledge: the client must explicitly acknowledgment the message.
    • dups-ok-acknowledge: allows the JMS server to perform optimizations on the logic of acknowledgment messages, but can cause the redelivery of messages. Should only be used with systems that are tolerant to duplicated message. Default: auto-acknowledge
  • delivery-mode: Specifies whether the JMS server must file on a persistent store the message before returning to the caller.
    Sending messages persistent slightly affects the performance but provides greater guarantees of delivery. The possible values for this parameter are:
    • persistent : guarantees delivery. Default value
    • non-persistent: don't guarantees delivery
  • priority: Message priority. The messages with higher priority will be received before messages with lower priority. The priorities set for JMS ranging from 0 (lowest priority) to 9 (highest priority). The default priority of JMS messages is 4.
  • time-to-live: Lifetime of sent messages, in milliseconds.
    Upon expiration of the time-to-live the JMS server is allowed to discard the message without delivering it. If not specified it is assumed a time-to-live of one year.
  • use-vcl-pool: Indicates whether to use connection pooling capabilities of the VCL. Set to false if the container provides pooling capabilities. Default: true
  • invalidate-conn-on-pool-insertion: Indicates whether connections should be marked as invalid before reinsertion on the pool. Is significant only if the pooling feature is enabled. Default: false

The attribute's admitted values are:

  • ref-dp: Name of Data Provider to use. This Data Provider will return the JMS Message to send.
  • dump-message: If true the message to be enqueued is dumped on log file, at DEBUG severity level. Default false

Its subelements are:

XAHelper

The XAHelper Element is used by jms-dequeue and jms-enqueue.

Its attributes are:

  • auto-enlist: The attribute's default value is: false.
  • transaction-status: The attribute's admitted values are:
    • TMSUCCESS: default value
    • TMFAIL

and its subelements: