Skip to content

Connectivity

Topic Transports

RabbitMQ Clustering for Topics

In Neuron ESB, Topics can be configured to use any number of transports including TCP, Peer, Named Pipes, MSMQ and RabbitMQ. MSMQ or RabbitMQ would typically be used if durable/persisted or transacted messaging was required end to end.

In Neuron ESB 3.1, RabbitMQ support has been substantially upgraded to support Clustered/Mirrored RabbitMQ environments.

Figure_49.png

In clustered RabbitMQ environments, mirroring of all Neuron ESB infrastructure queues should be configured through the RabbitMQ administration portal. Once this is done, each member of the cluster should be entered in the RabbitMQ tab of the Neuron ESB Explorer’s Deployment Groups section as displayed in the image above.

New property options on the Topic’s transport network property page determine the behavior as well as level of reliability that will be provided if either a member of the cluster or all members of a cluster fail. These property options can also guarantee once only delivery of the message.

Figure_50.png

The RabbitMQ transport for a Topic can be configured to run either in PublishConfirm (asynchronous type of transaction support based on acks/nacks), Transactional or no Transaction mode. It can also be configured to detect and discard any duplicate messages as well as resubmit all unacknowledged messages once connectivity is restored to the cluster if one or all machines in the Rabbit MQ cluster fail.

For example, consider the case where there are 2 RabbitMQ nodes configured in a mirrored cluster. If messages were being published and received through Neuron ESB while one of the nodes went down, the underlying Neuron ESB Runtime would automatically catch the failure condition, report it, and seamlessly roll over and send/receive messages to the remaining node in the RabbitMQ cluster. The original failed message would be resent to the surviving node and (if using PublishConfirms), any unacknowledged messages will be republished to the surviving node as well to ensure no message loss. Any messages that fail to be redelivered would be written to the Neuron ESB Audit database where they can later be resubmitted.

If both nodes go down, once the primary node is restored, all unacknowledged messages (if using PublishConfirms), will be resent to the primary node. Any failures will be written to the Neuron ESB Audit database where they can later be resubmitted.

Miscellaneous

RabbitMQ Dead Letter Monitoring – Neuron ESB automatically monitors a dead letter queue for all of its infrastructure queues. If the Neuron ESB dead letter processor fails on startup, any endpoint that successfully starts up after the fact will restart the dead letter processor.

RabbitMQ Endpoint Health statistics – The endpoint health statistics (errors and warnings) were never in sync with the statistics in the base child class, hence even if restarted and the statistics were cleared, they would be repopulated by the old number and always show red errors. This would be intermittent. This has been fixed.

Additionally, if a RabbitMQ based topic failed to start up when the Neuron ESB runtime was started, the timer would never be initialized so there was nothing watching to try to refresh the statistics reported in Endpoint Health within the Neuron ESB Explorer in case where the RabbitMQ topic would later be restarted.

Adapters

Microsoft Dynamics CRM 2013 Adapter

This is a new adapter included in the 3.1 release. This adapter supports both one way subscribe as two-way, solicit response mode. Users can either send updates or inserts into Dynamics CRM 2013, or make FetchXml Query requests against Dynamics CRM 2013. This adapter also supports meta-data harvesting. Users can browse the operations exposed by Dynamics CRM2013 and elect to generate Xml Schemas and sample Xml Messages for the various operations.

This adapter supports multiple security options, standard Windows credentials, Live Id credentials and Federated.

Figure_51.png

The Meta data generation wizard can be accessed through the “Retrieve Metadata” property of the adapter endpoint.

Figure_52.png

Operations can be selected by clicking the Add button. After operations are selected, the Import button will display the selected operations, allowing users to edit their properties and to optionally choose to generate sample Xml messages. The Finish button will store all the generated Xml Schemas and messages into the Neuron Explorer’s Repository.

Figure_53.png

Neuron ESB 3.1 ships a sample demonstrating how to use the new adapter. This can be found in the Neuron Explorer’s Sample Browser.

SalesForce.com Adapter

This is a new adapter included in the 3.1 release. This adapter supports the publishing of outbound notifications directly from SalesForce.com to Neuron ESB as well as two-way, solicit response mode. Users can either send updates or inserts into SalesForce.com, or make Query requests against SalesForce.com. This adapter also supports meta-data harvesting. Users can browse the operations exposed by SalesForce.com and elect to generate Xml Schemas and sample Xml Messages for the various operations.

When using the SalesForce.com adapter in Publish mode, the user must supply a URL that Neuron will host. All outbound notifications that are received can then be mapped to specific topics using the “Message Routing Table” property of the adapter endpoint.

Figure_54.png

The Meta data generation wizard can be accessed through the “Retrieve Metadata” property of the adapter endpoint.

Figure_55.png

Operations can be selected by clicking the Add button. After operations are selected, the Import button will display the selected operations, allowing users to edit their properties and to optionally choose to generate sample Xml messages. The Finish button will store all the generated Xml Schemas and messages into the Neuron Explorer’s Repository.

Figure_56.png

Extended Apache Active MQ Adapter

Several modifications were made to this adapter to achieve higher throughput in environments with limited IO capabilities. We added support for a configurable number of ActiveMQ Consumers to publish messages to Neuron ESB and a configurable number of producers to send messages to ActiveMQ from Neuron ESB.  Support was also added for different acknowledgement types when reading messages from ActiveMQ – Individual Acknowledge, client acknowledge, transactional, auto acknowledge.  For sending messages to ActiveMQ, we added support for both synchronous and asynchronous sends. Additionally, the client libraries were upgraded. We now use:

  • Apache.NMS.ActiveMQ – 1.6.2
  • Apache.NMS – 1.6.0

Updated Neuron ESB Adapter Framework

This has been updated and is now included in the Neuron Explorer’s Sample Browser. This is a sample project template that demonstrates how to build Neuron ESB Adapters using any message pattern such as request/response, solicit/response, one way publish, one way subscribe. Many helper functions have been pushed into main Neuron ESB assemblies making adapters much easier to develop.

Miscellaneous

POP3, Microsoft Exchange, Azure Service Bus, and FTP/SFTP/FTPS Adapters – At runtime, these adapters may use the Neuron ESB Audit Database for specific functions, if enabled. We found that under certain conditions the adapters would erroneously detect that there was no Neuron ESB Audit database configured for the environment. Hence those specific features, if enabled, would remain effectively disabled.  This has been corrected.

Microsoft Exchange Adapter – System.ArgumentException i.e. “The value must be greater than 0” would be thrown if a slash wasn’t used with the folder name.

Service Endpoints

Miscellaneous

NEW – Client Credentials, Service Credentials and Access Controls Lists are all populated by the Credentials created and maintained in the Security section of the Neuron ESB Explorer. If these were set in previous versions of Neuron ESB, they will have to be reconfigured to use the Credential store.

NEW – Windows authentication is now supported when using the REST binding with the Transport:Windows security setting.

In Neuron ESB 3.1 we have fixed service endpoints so when policy retries are defined, they show up as warnings similar to adapter endpoint retries when policies are used. Additionally, warnings and errors are incremented for the WMI performance counters for adapter endpoints.

Was this article helpful?
Dislike 0
Previous: Performance
Next: Developer Productivity and Business Processes