Knowledgebase: Articles
Cumulative Update 3 for Neuron ESB 3.5 (KB351-0715151)
Posted by Marty Wasznicky on 15 July 2015 03:04 PM

Cumulative Update 3 for Neuron ESB 3.5 (KB351-0715151)

Cumulative Update 3 (CU3) for Neuron ESB 3.5 resolves issues that were found in Neuron ESB 3.5 since the software was released. Additionally, several new features are introduced in CU3. This update rollup is highly recommended for all Neuron ESB 3.5 customers. This rollup release can be used to upgrade existing installations of Neuron ESB 3.5.x to Neuron ESB version 3.5.3.300

Released Version CU3 can be applied to:

Neuron ESB builds 3.5.0.4 to 3.5.2.x.

System Requirements:

*This patch requires PowerShell 4.0. Microsoft PowerShell 4.0 can be downloaded and installed from the following location: http://www.microsoft.com/en-us/download/details.aspx?id=40855 

Prior to installation, the NeuronPatch_3.5_CU3.zip file should be extracted to the local file system of the machine running Neuron ESB 3.5. As part of the update process only Neuron ESB files that have changed are backed up to Backup-NeuronESB_3.5_CU3 folder. This folder is listed at the end of the log created when InstallPatch.ps1 is executed. You need to ensure that you have at least 50MB free disk space available plus 30MB for each instance that will be updated. The files for the update requires another 70MB of disk space. If you were updating a single instance, then you will need a total of 150MB. For two instances a total of 180MB.

Fixes Included in CU3:

CU1 fixes and enhancements

http://support.neuronesb.com/index.php?/default_import/Knowledgebase/Article/View/52/15/cumulative-update-1-for-neuron-esb-35-kb351-121114

CU2 fixes and enhancements

http://support.neuronesb.com/index.php?/default_import/Knowledgebase/Article/View/60/15/cumulative-update-2-for-neuron-esb-35-kb351-0226151

Business Processes

NEW - A new attribute, ProcessStepAttribute, was added for developing custom process steps to allow for self-registration. Previously, users would be required to register their custom process steps manually by editing the neuronpipelines.config located in the pipelines directory of the instance install directory. Users no longer need to edit the config file. Users can now decorate their custom process step class with the ProcessStepAttribute as shown in the pseudo code sample below:

namespace NewCustomProcessStep

{

    [DataContract]

    [DisplayName("Sample Process Step")]

    [ProcessStep(typeof(MyStep),typeof(MyResource),"myname","mydescription",

        "CustomProcessStep","",Path="Training/My New Steps")]

    public class MyStep:CustomPipelineStep

    {}

 

Samples that demonstrates using the ProcessStepAttribute can be downloaded from here: http://support.neuronesb.com/downloads/neuron35/SampleProcessSteps.zip

NEW - A search box has been added to the top of the Process Step library within the Business Process designer to allow users to easily search for Process Steps.

MOD - When a name is not specified for a business process step, a default named based on the activity type will be used so that any resulting error messages will have meaningful name of the process step within it.

MOD - Modified the drop down box property of the Adapter Endpoint Process Step and Workflow activity so that they no longer display Publish mode adapter endpoints.

MOD - The System.Collections.Generic namespace was added to the C# code templates for the process code steps and workflow activities. This will allow types like List<T> to be accessed without using the fully-qualified namespace name.

MOD - Transform Process Step - added option to include or exclude the xml declaration on output.

MOD - A user will now be warned if the ESBService.exe is running a different configuration then what the user is attempting to test at design time within the Business Process Designer.

MOD - Service Endpoint Process Step - A fault or exception did not cause an exception to occur. A Boolean property has now been added to the process step that, if set to true, will cause the exception to be fired allowing the user to handle the exception within the Business Process. Default value is false.

FIX - Adapter Endpoint Process Step - would send out duplicate messages, the number of which would equal the number of retries associated with the Adapter Policy assigned to the underlying adapter endpoint.

FIX - Changes made within the Neuron ESB Business Process Designer would sometimes not be persisted when the user selected to save all changes. This could happen if the user was previously prompted to reload their configuration due to a change that the Neuron ESB detected in the underlying configuration.

FIX - Publish Process Step - In the Neuron ESB Business Process Designer, the code topic selector dialog would not save edited code when closed. The Publish step would still display the tooltip “The code for the selector must be set”. When the code editor was reopened, any previously entered code would be lost.

FIX - Attempting to access the context.Configuration object from a Business Process running remotely using the Client API or hosted by the Neuron ESB Test Client would fail with the following exception:

The type initializer for 'Neuron.Configuration.NeuronConfiguration' threw an exception

FIX - Code Process Step - When a user adds an assembly reference to a Code Process Step, then follows that by removing the same assembly reference, the user would be unable to re add the same assembly reference.

FIX - ODBC Process Step - having a '?' in data that’s sent to either the ODBC adapter or Process Step would generate a parameter error.  For example, if an ODBC adapter endpoint was configured for execute mode, the following statement would generate a System.IO.InvalidDataException exception. The adapter would misinterpret the ‘?’ that appends the data in the value clause as a parameter:

string sqlStatement = "<Statement type=\"Text\" sql=\"INSERT INTO Customer(Name) VALUES('Joe the guy?')\"></Statement>";

FIX - Code Process Step - If a user deleted a code process step from a Business Process while the code Process Step Editor was also opened in another tab, the tab remained open. It will now be automatically removed.

FIX - Service Endpoint Process Step - In an associated service policy, when electing to republish to a new topic, custom properties would be lost.

FIX - Audit Process Step - After several exceptions, an Audit Process Step may throw a System.ServiceModel.CommunicationObjectAbortedException exception.

FIX - Code Process Step - Debugging C# Code Process steps in the Business Process Designer causes duplicate window to appear– During the debugging process if a user hit F10 a new duplicate window of the current C# Code editor would open and the user would receive prompts during debugging that changes to the underlying configuration were detected, prompting the user to save them.

FIX - Adapter Endpoint Process Step – base.name and base.PartyID were not being populated which prevented adapters from reporting those values when errors occurred.

FIX - When using the Execute Process process step and dynamically setting the value of the child process to run at design time, users could experience high CPU utilization at runtime when running under load. This was caused because Neuron was not caching the child process that would be called. Every execution would cause the child process to be recreated/recompiled, which could also generate unnecessary temp files.

FIX - If a user moved an existing business process step to a different location on an existing business process, the Apply button would not be activated.

FIX - An unhandled exception would occur when trying to load an existing business process or workflow that referenced a custom process step that had yet to be registered.

FIX - If a user deleted an existing Business Process, upon saving the changes they would be presented with the Review Change List dialog. This would contain the change, as well as a number of “ADD” changes for existing publishers and subscribers that were not affected by the changed Business Process.

Workflow Designer

NEW - Retry Workflow Activity - A new Retry workflow activity has been introduced that can contain other workflow activities and be configured to retry their execution N (user defined) number of times if an exception is thrown.

MOD - Service Endpoint Workflow Activity – A fault or exception did not cause an exception to occur. A Boolean property has now been added to the activity and process step that, if set to true, will cause the exception to be fired allowing the user to handle the exception within the Workflow. Default value is false.

MOD - Transform Workflow Activities - added option to include or exclude the xml declaration on output.

MOD - The System.Collections.Generic namespace was added to the C# code templates for the process code steps and workflow activities. This will allow types like List<T> to be accessed without using the fully-qualified namespace name.

FIX - Within the Neuron ESB workflow designer, a Workflow with Execute Process activity would always enter a "modified" state (i.e. Apply button would be enabled and there would be an asterisks in the tab) when a person navigates away and then back to the workflow designer.

FIX - Code Workflow Activity - When using the C# workflow activity within the Neuron ESB Workflow designer, compile errors would still be reported, even after the compile error had been corrected in the code.

FIX - Code Workflow Activity - When a user adds an assembly reference to a Workflow Activity, then follows that by removing the same assembly reference, the user would be unable to re add the same assembly reference.

FIX - A user will now be warned if the ESBService.exe is running a different configuration then what the user is attempting to test at design time within the Workflow Designer.

FIX - Service Endpoint Workflow Activity - In an associated service policy, when electing to republish to a new topic, custom properties would be lost.

FIX - C# Class Workflow Activity - The message variable was not available in the Workflow C# Class Activity. In order to retrieve the value of the argument or variable, a user must write a public property with a getter/setter, and at runtime the activity will invoke the setter to set the value of the property. For example:

public ESBMessage message { get; set; }

FIX - Adapter Endpoint Workflow Activity – base.name and base.PartyID were not being populated which prevented adapters from reporting those values when errors occurred.

FIX - Publish Workflow Activity – if an error occurred publishing to the Topic, 2 errors would be generated rather than one and both were incorrect.

FIX - Workflow Designer – any design time change to a C# Workflow Activity would not be reflected at runtime when in online mode and the user saves the changes.

FIX - Publish Workflow Activity – When the Publish Workflow Activity would fail to publish to the assigned Topic at runtime it would not throw an error back to the running Workflow. This would cause the Workflow to appear in Workflow Tracking with a Completed state rather than an Aborted state, even though the error was correctly logged in the Neuron ESB Event log.

FIX - Users may experience the following error when referencing a custom assembly within the Workflow Designer during simulation after the Neuron ESB Explorer has been closed and reopened:

Compiler error(s) encountered processing expression 

FIX - When Assembly References were added or removed in Add Assembly reference dialog within the Workflow Designer, the Apply button would not become enabled.

FIX - When browsing for types within the Workflow Designer, no types would appear in the type browser dialog.

FIX - Adding an assembly reference to an existing workflow could generate a Null reference exception.

FIX - When adding assembly references to a workflow, duplicate references could be added if one was added at the code workflow activity as well.

FIX - Adding a reference at the workflow activity would work at runtime, however a compile time error would occur when testing the workflow within the designer.

Workflow Runtime

FIX - Adapter Endpoint Workflow Activity - would send out duplicate messages, the number of which would equal the number of retries associated with the Adapter Policy assigned to the underlying adapter endpoint.

FIX - When Neuron ESB starts up, if the ESB Management objects feature were not installed, the Availability Groups would not start up and there would be no warning as to why they would not startup and how to correct.

FIX - Stopping ESB Service with active Availability Groups could generate the following errors –

1. Can't perform operation STOP# on Workflow Endpoint 668ba063-6f99-4175-a37b-39e25cca6a8e, running under Workflow Order Process Host, because cannot write to a closed TextWriter.

2. Can't perform operation Stop Operation on Availability Group Workflow Order Process Host, because Object reference not set to an instance of an object.

FIX - Availability Group would not automatically recover/restart if the SQL Server suddenly went down (i.e. network failure) and came back on line.

FIX - In environments where more than one Neuron ESB server is running the same solution and sharing the Neuron ESB database, users may experience the following error associated with Availability Groups:

Control of the Availability group Availability Group X has been transferred to another server in the farm. Shutting down heartbeat thread process.

FIX - Availability Groups were not applying the Environment Variable value applied as the ConnectionString property on the Neuron ESB Database.

FIX - When a persistence exception occurred in a Workflow the original message was not written to the Failed Message table within the Neuron ESB database.

FIX - Race condition in correlated workflows could occur and prevent subsequent workflows from starting - users could experience one of the following:

a)      The user submits messages to the workflow endpoint, but no workflows start running. The user would see messages queueing up in the pending messages table.

b)      The user submits messages to the workflow endpoint. One workflow may start, but will move into an Unloaded state and will not resume; no other workflows would start. Again, you’d see messages queueing up in the pending messages table.

FIX - Error when attempting to start a Workflow Endpoint - When either a user or the Neuron ESB runtime attempts to start a Workflow Endpoint, the following error could be reported if the Topic assigned to it is unavailable or disabled:

System.AggregateException: One or more errors occurred. ---> System.Collections.Generic.KeyNotFoundException: The given key was not present in the dictionary.

The Workflow Endpoint would also appear in a Started state within Endpoint Health. This has been corrected.

FIX - Assigning an Availability Group to multiple machines could cause the ESBHost.exe to constantly recycle itself.

FIX - When using the Persistent Delay Workflow Activity, the Neuron ESB scheduler for deserializing the workflow may fire multiple times. This could result in the following entry in the Neuron ESB log file:

System.Runtime.DurableInstancing.InstanceNotReadyException: The execution of an InstancePersistenceCommand was interrupted because the instance '831bc3b6-39e9-4890-b776-e026d975e012' has not yet been persisted to the instance store.

FIX - Within the workflow, if a publish activity publishes a message to a Topic that is stopped, failed or in any kind of inaccessible state, it would not throw an exception back to the workflow instance to abort it. Instead, Workflow tracking would show that the workflow completed successfully.

FIX - Users could experience a memory leak for the Neuron ESB Workflow host when Workflow Tracking was enabled.

FIX - A “Synchronous” property has been added to the PublishRequestMessage Workflow Activity. Its default value is false. Previously, the PublishRequestMessage activity would send a request then persist the workflow, even if the response was expected to be returned in several seconds. However, if there were a great many instances of workflows running, it could take much longer for the workflows to receive the responses and continue the workflow instances since all the response messages would be effectively queued.  By setting Synchronous to true, Neuron will no longer let the workflow go idle and persist, instead the PublishRequestMessage activity will now wait for the reply to be returned and continue, keeping the workflow alive.

FIX - If a persistence error occurred when trying to resume a workflow, semaphore locks could be released.

FIX – During runtime the operating system could return a null reference for a performance counter which could cause the Workflow host environment to crash.

FIX – SQL Server could experience very high CPU usage (>80%) after all workflows in a batch had completed.

Service Endpoints

NEW - CORS header support has been added as a checkbox option to the Neuron ESB Client Connector to allow cross domain scripting for REST and HTTP based endpoints. Previously customers would need to create a custom behavior and add that to the service endpoint.

NEW - Added support for adding/retrieving http headers from non-REST (http based bindings) service endpoints. A new “Enable HTTP Headers” checkbox has been added to both the Client and Service connector tabs of the Service Endpoint entity. Regardless of whether or not this is enabled, HTTP headers are always processed for REST endpoints. Additionally, the Capture and Restore Headers options have been renamed to “Enable Custom SOAP Headers” on bother the Client and Service connector tabs of the Service Endpoint entity. This also modifies the previous behavior of the Service endpoints when dealing with custom SOAP Headers. Previously, if a user created 2 service endpoints (i.e. one a client connector, the other a service connector) and wanted to have custom SOAP header support end to end, the user could have to enable both the “Capture Headers” and “Restore Headers” on each Client connector and Service connector tab of both endpoints, even though one tab on each would effectively be disabled in all other respects.  Now the user just need to check “Enable custom SOAP Headers” on either the enabled Client or Service Connector tab.

NEW - Support has been added for using Username and Password with the TransportWithMessage security setting for Service Endpoints. Previously, only Certificates were supported.

MOD - Service Endpoints called through either the Service Endpoint Process Step or Workflow activity no longer need to be enabled to be used at runtime.

FIX - If user called into a Neuron ESB Client Connector endpoint by first adding a Proxy to the HTTP header on the Request message that is the same proxy as the one that the message will be forwarded to (i.e. a configured Service Connector), it would generate a multi hope cycle error from the target endpoint.

FIX - Deleting a running Client or Service connector from the Neuron ESB Explorer could generate the following exception when the changes were saved:

“Could not find service endpoint with Id”

Monitoring/Reporting

NEW - Added WMI EndpointStateChangeEvent event to Topics, Availability Groups and Workflow Endpoints – Users can now use WMI to monitor all endpoints within Endpoint Health for state changes as well as failures. Users can use WMI’s query language to limit the monitoring to any combination of properties exposed by the EndpointStateChangeEvent. For example, the “Type” property can return any of the following values:

  •  
    • TcpPublishingService
    • AmqpEndpoint
    • MsmqPublishingService
    • NamedPipePublishingService
    • ServiceConnector
    • AdapterEndpoint
    • AvailabilityGroup
    • WorkflowEndpoint
    • ClientConnector

The WMI code that monitors only Adapter Endpoints may look like this:


using System;

using System.Globalization;

using System.Management;

 

namespace WmiFailedMessageSample

{

    class Program

    {

        static void Main()

        {

            try

            {

                var managementScope = new ManagementScope("\\\\.\\root\\Neudesic_ESB_v0");

                managementScope.Connect();

                var eventEndpointQuery = new WqlEventQuery("EndpointStateChangeEvent");

                eventEndpointQuery.Condition = "Type = 'AdapterEndpoint'";

                var watcher1 = new ManagementEventWatcher(managementScope, eventEndpointQuery);

                watcher1.EventArrived += EndpointChanged;

                watcher1.Start();

 

                Console.WriteLine("Listening for events. Press Enter to exit.");

                Console.ReadLine();

                watcher1.Stop();

            }

            catch (Exception ex)

            {

                Console.Error.WriteLine(ex);

                Console.WriteLine("\nPress Enter to exit.");

                Console.ReadLine();

            }

        }

 

        static void EndpointChanged(object sender, EventArrivedEventArgs e)

        {

 

            string zone = e.NewEvent["Zone"] as string;

            DateTime eventDate =
               ManagementDateTimeConverter.ToDateTime(e.NewEvent["Datetime"] as string);

            string type = e.NewEvent["Type"] as string;

            string name = e.NewEvent["Name"] as string;

            string state = e.NewEvent["State"] as string;

            string hostName = e.NewEvent["Hostname"] as string;

            string instanceName = e.NewEvent["EsbInstanceName"] as string;

            string application = e.NewEvent["Application"] as string;

            string deploymentGroup = e.NewEvent["DeploymentGroup"] as string;

            string endpointId = e.NewEvent["Id"] as string;

            string info = e.NewEvent["Message"] as string;

 

            var message = string.Format(

                CultureInfo.InvariantCulture,

                "Name={0}, Endpoint Type={1}, State={2}, Instance={3}, Zone={4}, Machine={5},  
                 Application={6} , DeploymentGroup={7}, Info={8}, DateTime={9}",

                name,

                type,

                state,

                instanceName,

                zone,

                hostName,

                application,

                deploymentGroup,

                info,

                eventDate.ToString());

 

            Console.WriteLine(message);

        }

    }

}

NEW – Resubmission count for messages resubmitted using the Message Resubmit dialog. When users resubmit a message, the row in the Neuron ESB Audit database for the message will be updated with an incremented submission count value. That value is now displayed as the “Submission Count” column in the Message History and Failed Message reports. Once a message has been resubmitted, users can re-query the reports and view the number of times a message has been resubmitted.

MOD - Endpoint Health refresh interval is no longer linked to service report interval. There is a new Refresh Interval property located on the Tools à Options menu of the Neuron ESB Explorer.

FIX - Within Endpoint Health, the rate being reported would be inaccurate if the screen was refreshed.

FIX - Within the Message History and Failed Message reports, the Related Messages context menu would throw exception indicating a Missing Instance column

FIX - If an exception occurred when starting a Workflow Endpoint, Endpoint Point would reflect a “Starting…” state rather than a failed state.

FIX - If an exception occurred during the connection of the underlying Party associated with a Workflow Endpoint, Endpoint Health would incorrectly show that the Workflow Endpoint was started rather than failed.

FIX - Within the Failed Message and Message History reports, setting the Topic Filter could sometimes throw an Index Out of Range Exception. This would occur if audited records contained sub topic references. Users could also experience the following exception:

System.Data.SqlClient.SqlException (0x80131904): Ambiguous column name 'TopicRoot'

FIX - Sorting Issues with Message History and Failed Message reports - Message Id and Transaction Id column sorting were not returning results in the correct order.

FIX - Endpoint Health – Running Workflow Endpoints do not appear in Endpoint Health if a different solution is running than that which is loaded in the Neuron ESB Explorer.

FIX - Users could not delete a workflow entry in the Workflow Tracking UI if the Workflow Definition file was missing. This could be because a user deleted it, or a different solution was loaded in the Neuron ESB Explorer that referenced the same Neuron ESB database.

FIX - Starting an aborted workflow generates a generic error processing message – When attempting to start an aborted workflow that by design could not be started (i.e. there was not a persistent point defined within the workflow) the following generic exception would be thrown:

System.Runtime.DurableInstancing.InstanceNotReadyException

Neuron will now display an exception letting the user know why it couldn’t start i.e. a persistent point did not exist in the workflow.

FIX - PendingEvents counter on Endpoint Health could erroneously display 2 billion records. Restarting the Availability Group/Workflow endpoint could cause this when there were active workflows in the database to process.

FIX - Workflow Tracking – On the Messages tab of Workflow Tracking, the Move Context Menu did not always work.

FIX - Endpoint Health – Previously, if errors occurred on an endpoint, the icon representing that endpoint would turn red. However, if the error conditions for the endpoint were resolved and successful messages were sent, the icon would remain red. This has been resolved. The icon will turn back to Green once a subsequent successful message is detected sent over endpoint.

FIX - Cluster Support - Workflow Endpoints – When running in a Windows Cluster environment the metrics for Workflow Endpoints within Endpoint Health were not being incremented.

FIX - Workflow Endpoint and associated Party dependencies would fail to remain in sync. The dependent Workflow endpoint could enter a state where it would be unaware if the dependent Party became disabled, disconnected or failed to successfully connect to the dependent Topic. If any of these conditions occurred, within Endpoint Health, the Workflow Endpoint would appear in a healthy, Started state rather than move into a Failed state.

FIX - App Domains were not unloading from memory when endpoints are reconfigured or stopped within the Endpoint Health. This could result in errors reconnecting to Topics.

FIX - When using a Named Pipes based Topic and attempting to restart an ODBC Adapter Endpoint multiple times from Endpoint Health, the user may experience the following exception:

Cannot listen on pipe

FIX - Client connector would be displayed in a Stopped state in Endpoint Health instead of disabled when its underlying party is disabled - If the party assigned to a service endpoint (i.e. client connector/service connector) or adapter endpoint or workflow endpoint is disabled and if a user attempts to start the endpoint in Endpoint Health, it shows up RED, in a stopped state, and NO errors are indicated in endpoint health even though an error is recorded in the Neuron ESB event log. Moving forward, if any party assigned to an endpoint is disabled, the endpoint will be displayed as disabled within Endpoint Health and a warning will be logged to the Neuron ESB event log indicating the reason why its disabled.

FIX - Endpoint Health can generate an unhandled exception if “while displayed”, a user restarts the Neuron ESB service from the Neuron ESB Explorer toolbar.

FIX - Restarting a Neuron ESB Topic within Endpoint Health when its assigned port is currently in use will cause the Topic to be set to a failed state which is expected. However, it will immediately thereafter be switched to a Stopped state. Once that happens, even if the port condition is corrected, the Topic can no longer be restarted in Endpoint Health.

FIX - When a polling based adapter reports that it will be disconnected, its state in Endpoint Health would remain in a Started state. This affected the following adapters:

    • Azure Service Bus
    • File
    • FTP/SFTP/FTPS
    • IBM MQseries
    • Microsoft Exchange
    • POP3
    • ODBC

FIX - Unable to stop polling based adapter in Endpoint Health. When a user attempts to stop a polling based adapter within Endpoint Health, its state will briefly be set to Stopped and then immediately reset to Started.

FIX - If a Service Connector or Client Connector failed to start up, specifically open a proxy for the target URL, Neuron ESB would increment of the error count in Endpoint Health, but the endpoint would still register as Started in Endpoint Health.

FIX - If an error occurs when starting or reloading a workflow, the active performance counter was not being decremented. This would make it appear in Endpoint Health that there were more active workflows than there really were.

FIX - When republishing a large number of messages using the Message Resubmit dialog to an MSMQ based topics, users may experience the UI hang and high memory utilization. This only occurred when users selected to republish using a Party. This was due to Neuron ESB waiting for .NET garbage collection to finish. This has been fixed.

FIX - When republishing a messages users may see an error message box displayed in the background with a System.AggregateException message. This only occurred when users selected to republish using a Party. This has been fixed.

FIX - When republishing messages using the Message Resubmit dialog, if there was an existing Action value on the original message, it would not be republished with the message. This only occurred when users selected to republish using a Party and has been fixed.

FIX - Modified the Message Resubmit dialog so that it only displays Subscribe side adapter endpoints. Previously this would display all adapter endpoints regardless of mode (i.e. Publish mode, etc.).

FIX - Modified the Message Resubmit dialog so that messages can be resubmitted directly to Endpoints without the need for the Neuron ESB Service to be running.

FIX - When attempting to conduct an operation on a workflow record in Workflow tracking a user could experience the following erroneous error message:

"One or more selected workflows do not belong to current instance ‘N’. These workflows will be skipped. Do you want to continue?”

This message could be displayed even though the selected Workflow item DID belong to the current instance. This has been fixed.

FIX – User could experience a “The SELECT permission was denied on the object” exception when running either the Message History, Failed Message or Workflow tracking reports. This would occur if the specific user was added to the NeuronUsers database role.

FIX - When using Endpoint Health for monitoring workflow endpoints, they could appear under the incorrect Availability Group.

Neuron Database

NEW - SQL Azure as the Neuron ESB database can cause Network Connection and Timeout Exceptions. Transient fault handling for components that interact with a SQL Azure database has been introduced. We found in testing that customers that used SQL Azure as their SQL data store were experiencing frequent faults that are common to SQL Azure. The transient fault handling code allows Neuron to intercept and respond to these events by applying a strategy for retrying the database operation multiple times before failing.
Configuration Section

The configuration settings for the transient fault handling are currently configured in the following configuration files:   

  •  
    • ESBService.exe.config
    • ESBHost.exe.config

The configuration section is named neuron.transientFaultHandling. The configuration section needs to be registered in the <configSections> header element of the configuration file:

<configuration>
    <configSections>
        <section name=”neuron.transientFaultHandling”
                  type=”Neuron.Esb.TransientFaultHandling.Configuration.RetryPolicyConfigurationSettings, Neuron.Esb.TransientFaultHandling”/>

        …
    </configSections>
</configuration>

The neuron.transientFaultHandling configuration section is used to define retry strategies that will be executed to retry database operations when database operations fail. The specific retry strategies are documented in the next section. In the Neuron ESB 3.5.3 release, we currently only use the default strategy as configured in the configuration section. The configuration section will look like this:

<configuration>
    <neuron.transientFaultHandling defaultRetryStrategy=”incremental”>
        <incremental name=”incremental”
            firstFastRetry=”true”
            maxRetryCount=”15”
            retryIncrement=”00:00:01”
            initialInterval=”00:00:01”/>
    </neuron.transientFaultHandling>
</configuration>

This configuration section indicates that the incremental retry strategy will be used. The incremental retry strategy is configured to retry the database operation a maximum of 15 times before failing. The retry strategy will initially wait for 1 second and will pause for 1 second between successive retries.

Retry Strategies

Incremental Strategy

The incremental retry strategy attempts to retry a failing operation for a specified maximum number of attempts and uses an incremental time interval between retries. The incremental strategy is defined in the configuration using the incremental configuration element and has the following attributes:

<incremental name=”…”
    firstFastRetry=”true”
    maxRetryCount=”10”
    retryIncrement=”00:00:01”
    initialInterval=”00:00:01”/>

Attribute

Type

Description

name

String

A unique identifier for the retry strategy.

firstFastRetry

Boolean

If true, the first retry attempt occurs immediately if a failure occurs. If false, the first retry will remain subject to the retry interval.

maxRetryCount

Integer

The maximum number of retry attempts to perform before the operation fails.

initialInterval

TimeSpan

The initial interval that will apply for the first retry.

retryIncrement

TimeSpan

The incremental time value that will be used to calculate the progressive delay between retries.

Fixed Incremental Strategy

The fixed incremental retry strategy attempts to retry a failing operation for a specified maximum number of attempts and uses a fixed time interval between retries. The fixed incremental strategy is defined in the configuration using the fixedIncremental configuration element and has the following attributes:

<fixedInterval name=”…”
    firstFastRetry=”true”
    maxRetryCount=”10”
    retryInterval=”00:00:01”/>

Attribute

Type

Description

name

String

A unique identifier for the retry strategy.

firstFastRetry

Boolean

If true, the first retry attempt occurs immediately if a failure occurs. If false, the first retry will remain subject to the retry interval.

maxRetryCount

Integer

The maximum number of retry attempts to perform before the operation fails.

retryInterval

TimeSpan

The time interval between retries.

Exponential Backoff Strategy

The exponential backoff retry uses an exponential delay between retries to attempt to complete the failing operation. The exponential backoff strategy is defined in the configuration using the exponentialBackoff configuration element and has the following attributes:

<exponentialBackoff name=”…”
    firstFastRetry=”true”
    maxRetryCount=”10”
    minBackoff=”00:00:01”
    maxBackoff=”00:00:30”
    deltaBackoff=”00:00:10”/>

Attribute

Type

Description

name

String

A unique identifier for the retry strategy.

firstFastRetry

Boolean

If true, the first retry attempt occurs immediately if a failure occurs. If false, the first retry will remain subject to the retry interval.

maxRetryCount

Integer

The maximum number of retry attempts to perform before the operation fails.

minBackoff

TimeSpan

The minimum backoff time.

maxBackoff

TimeSpan

The maximum backoff time.

deltaBackoff

TimeSpan

The value that will be used to calculate a random delta in the exponential delay between retries.

 

MOD - The Update Purge and Archive Sql Agent job was modified so that the archive portion of job could be optional.

FIX - Workflow and using SQL Azure – Transaction deadlocks could occur against the WorkflowCorrelatedWorkflow table could occur when using SQL Azure.

Logging

FIX - Availability Group logging has been corrected so that issues are now reported in the Neuron ESB Event log. Previously they were only logged in the Neuron ESB log files. Error messages have also been augmented with more actionable information.

FIX - Cluster support - Event Logging - When running in a Windows Cluster environment Host name was being recorded rather than cluster network name

FIX - Cluster Support - When running in a Windows Cluster environment MSFT Failover cluster events were being captured in the Availability Group Neuron log files

FIX - The Neuron ESB Event log contains several errors on startup when completed workflow instances existed in the Neuron ESB database – specifically:

System.Runtime.DurableInstancing.InstanceNotReadyException

FIX - If the Neuron logging location was changed by setting the following registry keys:


HKEY_LOCAL_MACHINE\SOFTWARE\Neudesic\Neuron ESB v3\ESB\SystemLogFolder
HKEY_LOCAL_MACHINE\SOFTWARE\Wow6432Node\Neudesic\Neuron ESB v3\ESB\SystemLogFolder

Users would experience an exception (System.ServiceModel.FaultException) when they attempt to “Connect” to the running instance using the Neuron ESB Explorer. The exception would occur when attempting to select the Instance to connect to within the drop down box.  To correct this, the registry key has been moved. If the Neuron logging location needs to be changed, users should now use the following registry keys, where SystemLogFolder is a string value:

HKEY_LOCAL_MACHINE\SOFTWARE\Neudesic\Neuron ESB v3\SystemLogFolder
HKEY_LOCAL_MACHINE\SOFTWARE\Wow6432Node\Neudesic\Neuron ESB v3\SystemLogFolder

Neuron Explorer/Test Client

NEW - Added the format context menu to the xml editors located on the Neuron ESB Test Client so that users can just right-click and select "Format”.

FIX - The Neuron ESB Web Service Import would fail with WSDLs that had schemas which included ##any elements. Although these can now be imported correctly, these WSDLs are still invalid to use as a metadata setting for client connectors

FIX - When closing Neuron ESB Explorer, saving a new configuration did not add the configuration to the MRU list of the Neuron ESB Explorer

FIX - In the Neuron Explorer, within the Binding Expression dialog, the Binding Expression field would only allow a user to scroll to the right in order to check first 75 characters of the url. 
If the url was longer than 75 characters, the full length would be stored, but only 75 characters could be viewed by scrolling to the right in the field.

FIX – Within the Neuron ESB Explorer the Delete button/icon for the Process/Workflow Library did not work for workflow objects.

FIX - The Endpoint Health toolbar button should only be enabled IF there is a solution opened in the Neuron ESB Explorer.

FIX - When in offline mode, users could not configure the “Endpoint Policy” property of the MSMQ Transport for a Topic.

FIX - The Neuron ESB Log files for Availability Groups and Workflow Endpoint logs were being misnamed when new daily logs were created

Adapters

NEW – A new Adapter Wizard for generating XML Schemas and Sample XML messages has been added. This wizard is accessible through the tool bar “Generate” button located on Adapter Endpoints and XML and Schema Repository within the Neuron ESB Explorer. Using this wizard, users can select a registered adapter that supports meta data generation, choose the operations and select to generate both the schemas and sample messages that the adapter endpoint requires. Currently, the SAP, NetSuite, Dynamics CRM and Salesforce adapter are all supported. Additionally, developers can use the Neuron ESB Adapter framework to develop their own adapters that support our new meta data API. Those adapters will automatically be supported by the Adapter Wizard.

Adapter Wizard

NEW - TCP/IP Socket Client and Server Adapters - The TCP/IP Socket adapters establish a bi-directional channel for sending messages between two processes using just the TCP/IP protocol. The primary use case for the TCP/IP Socket adapters is to link two Neuron adapters that exist in separate zones such as a DMZ and a secure intranet. Using the adapters, the DMZ ESB service can expose WCF client connectors to the unsecure Internet, and forward requests to be processed by the linked ESB service that is running in a secure intranet. The TCP/IP Socket adapters have been designed to support overcoming firewall connection issues that typically exist when establishing a DMZ. The TCP/IP Socket adapter can also be used to send messages to or receive messages from external programs that can communicate using TCP/IP Sockets.

NEW – Redis Adapter - This adapter supports one way subscribe and two-way, solicit response modes. Users can send updates, inserts keys/values, or make all get Query requests against a Redis Server. The Neuron ESB Redis adapter supports all operations provided by Redis.

In order to use Redis adapter you need to configure connection properties:   

  • Server Name
  • PrimaryPort
  • SecurePort
  • SlavePort

    The Neuron ESB Redis adapter expects the developer to pass custom properties as part of the ESB message header. Below is the example of setting custom properties (via the Neuron ESB Test Client) to the adapter end point in order to perform a SET operation.

    SET command

    set command

    As shown above, in order to use the Neuron ESB Redis adapter you need to pass the custom properties on the ESB message header. The adapter requires you to pass “what” operation you want to do and its respective parameters. One need to pass the exact Operation name which is used in Redis. You can find the list of commands here: http://redis.io/commands

    When you send the message to an adapter endpoint, the Result custom property will be returned which will contain the status of operation.

    results

    Note

    a)      In order to pass a parameter which is of type Timespan as expected by the EXPIRE command, the developer needs to only pass in the value as the number of seconds.

    b)      In Order to pass array in the parameter the developer needs to pass it by space value. For example, if the developer wants to perform the DEL command for multiple keys, the parameter would be passed as follows:

    results2

    c)      If you do not pass a parameter which is supposed to have a specific value, Neuron will pass the body of the ESBMessage as a value.

    NEW – An SAP adapter has been added that will allow users to easily update and query existing SAP systems using IDOC, BAPI and RFC interfaces as well as receiving IDOC messages to be published to the bus. This adapter also supports meta data generation in the form of XML Schemas and sample XML messages using the new Adapter Wizard.

    NEW - A new Microsoft SQL Service Broker adapter has been added. This can be used to either monitor Microsoft SQL Service Broker queues or send messages to those queues.

    NEW – NetSuite adapter - Added support for multiple versions of NetSuite’s SOAP API. The adapter currently supports 2013_2, 2014_1, 2014_2 and 2015_1.

    MOD - Adapter Endpoints called through either the Adapter Endpoint Process Step or Workflow activity no longer need to be enabled to be used at runtime.

    MOD - Dynamics CRM 2013 Subscription Adapter - Added a send timeout property.

    MOD - Salesforce Adapter – When generating XML and XSD schemas from the Meta generation tool, those documents stored in the Neuron ESB Repository will include the Salesforce version number configured for that endpoint.

    MOD - Salesforce Adapter – Now supports latest version(s) of the Salesforce SOAP API - Added support for changing the Salesforce SOAP API version. This includes a new adapter property, along with adding an annotation to updated schemas for which version of the SOAP API they were generated with. Also modified the Neuron ESB Schema version number to match the SOAP API version. Current support is for versions 28.0 - 33.0.

    FIX – The SharePoint 2010 Plugin – referenced incorrect versions of Neuron ESB assemblies – the correct versions are compiled against .NET 3.5

    FIX – SharePoint 2010 Plugin – users with limited access security could not publish events to Neuron ESB.

    FIX - ODBC Adapter - having a '?' in data that’s sent to either the ODBC adapter or Process Step would generate a parameter error.  For example, if an ODBC adapter endpoint was configured for execute mode, the following statement would generate a System.IO.InvalidDataException exception. The adapter would misinterpret the “?” that appends the data in the value clause as a parameter:

    string sqlStatement = "<Statement type=\"Text\" sql=\"INSERT INTO Customer(Name) VALUES('Joe the guy?')\"></Statement>";

    FIX - If an Adapter Endpoint was marked as Single Instance in solution running on more than 1 server, it could go into a stopping state.

    FIX - Dynamics CRM 2011 plugin - The Neuron EB Dynamics CRM 2011 plugin would generate an error during installation due to incorrect XRM SDK assembly references.

    FIX - Salesforce adapter – Exceptions could arise from concurrency issues related to how the adapter was internally managing the Salesforce session ids.

    FIX - Salesforce adapter – When using the REST capabilities of the adapter, if an exception occurred, the aggregate exception rather than the true exception could be recorded/logged.

    FIX - Dynamics CRM Adapter – The x64 Neuron ESB installer only installed the x86 CRM SDK assemblies.

    FIX - ODBC Adapter Endpoint – If the endpoint was marked as single instance and deployed to more than 1 machine, the endpoint would continue to flip back to a Started state if a user stopped it from Endpoint Health.

    FIX - Salesforce adapter – when attempting to launch the Meta generation dialog from the adapter properties grid with an expired password, the dialog would launch but when a user attempted to select/expand the Salesforce objects, no objects would appear. Moving forward they will be alerted to the expired password condition.

    FIX - A threadabortexception could occur during the shutdown of a File adapter endpoint configured for publish mode. This was due to a race condition which has been fixed.

    FIX - Added a new property to the Azure Service Bus adapter to allow a developer to choose between ACS and SAS (default) for authentication. The adapter will create an ACS URI for the service bus if ACS authentication is requested.

    FIX - The Dynamics CRM 2013 adapter would throw an instance of an object exception if a CRM entity didn't have a description.

    FIX - When sending a message to a custom adapter using either the Adapter Endpoint Process Step or Workflow activity, the Neuron ESB Configuration object was not being set. This could prevent specific functions from working, for example, auditing the message on a publish mode adapter when the publish activity failed.

    FIX - SMTP Adapter – Previously we did not allow context properties to be used for the Filename parameter in property grid UI. If used, a Filename validation exception would be thrown.

    FIX - File Adapter – When using an Adapter policy to control retries, a retry would write both a warning and an error to the Neuron ESB event log.  Only warnings should be written for each retry with 1 failure message when the retries exhaust themselves.

    Installation and Setup

    MOD - Updated Xceed libraries to version 5.7

    FIX - Neuron ESB Installer: Installing only the Development Tools option would not install the Pipelines directory. If using the Neuron ESB Test Client, the following error would result: 

    Unable to deserialize pipeline from configuration file

    FIX - The "Neuron Availability Groups" performance counter category had a typo and was previously named "Neuron Availabilty Groups" in the installer.

    Messaging

    NEW - A global application setting in ESBService.exe.config has been added to force TCP topics to use the IP address of the client instead of the host name when establishing the connection to the client's receiver service. This circumvents the need for DNS lookups. The new application setting is “UseClientIPAddress”. This can be set to True or False. If not present, false is assumed.

    NEW - Added the new “RemoveProperties” method to ESBMessage class as a way to clear all the custom properties of like prefix.

    MOD - The EnvironmentVariables collection object accessible within a Business Process or Workflow has been marked as readonly to prevent users from attempting to modify the contents.

    FIX - ESBMessage.Clone() was sharing binaryBody between the original and cloned object - ESBMessage.Clone copied the reference to binaryBody from the original ESBMessage object to the new ESBMessage object. Any change to the byte array of either object would also affect the other, and potentially any number of clones that were created from the original message or clones. A copy of the byte array for each clone will now be made.

    FIX - Party may not reconnect to a Topic in some circumstances if the underlying Transport for the topic was changed or if the Topic’s publishing service failed and later came back on line. Also, in some cases the Party may believe its connected when it is not which could cause the following exception when sending a message: can't send..not connected error

    FIX - When using RabbitMQ based topics and connecting to the Neuron ESB server using the remote Client API, there will be 2 different queues created in RabbitMQ with similar names but different casing.

    FIX - When using either TCP or Named Pipes based Topics, users may experience the following exception:

    System.InvalidOperationException: Cannot send - party is not connected

    This could be followed by an inner exception of:

    System.ObjectDisposedException: Safe handle has been closed

    This could occur when the party calls a Send() method to publish to the bus. Effectively a race could occur where the pool of connections for the party would be disposed before the Send() call completed.

    FIX – MSMQ Topics - If a policy was associated with the “Endpoint Policy” property of the MSMQ transport for a Topic, its expiration value would override the configured Time to Live property of the transport. If the expiration was set to 0, this could cause all messages delivered to the subscriber to almost immediately be rerouted to the System Dead Letter queue as they would expire within moments of delivery.

    FIX - When attempting to publish a message using the Neuron ESB Client API within a service hosted by an IIS app pool running under the network service account, the following error could occur:

    System.UnauthorizedAccessException "Access to the path is denied"

    Download Locations:

    NOTE: You must be logged into the Neuron ESB Support Center to view downloadable files.

    The Neuron ESB 3.5 CU3 Update patch package can be downloaded directly from the Neuron ESB Support Center's 3.5 download section. Title: Neuron ESB 3.5 Cumulative Update 3 (CU3) - Patch, Filename is :NeuronPatch_3.5_CU3.zip Size: approx. 133MB

    Alternatively, the Full Neuron ESB 3.5 CU3 installation package can be downloaded. This can be found in the Neuron ESB Support Center's 3.5 download section. Title: Neuron ESB 3.5 Cumulative Update 3 (CU3) - Full Install, Filename is: NeuronInstall_3.5_CU3.zip , Size: approx. 182MB

    Install Instructions:

    If installing the NeuronPatch_3.5_CU.zip patch, the installation instructions can be found in the README.txt enclosed in the ZIP file. A summary of those instructions follow:

    Running Powershell:

    • Open command prompt as administrator
    • Enter: powershell
    • Enter: set-executionpolicy allsigned
    • Change to the directory where the InstallPatch.ps1 script file is located
    • Enter: .\InstallPatch.ps1 > log.txt
    • Enter "r" at prompt to run the InstallPatch.ps1 script
    • Respond Y or N to the prompt about backing up files that will be overwritten
    • Enter "r" at prompt to run the CreateManagementObjects.ps1 script
    • When the script runs, it will prompt you if you want to upgrade each qualifying instance.     Type Y and press Enter if you want to update or N if you do not.
    • When the script completes, open the log.txt file and make sure that the Errors count at the end of the log is 0
    • For each database at version 9, 10 or 11, upgrade them to database version 12 by doing one of the following:
      • Using SQL Server Management Studio, run the following contained in the Sql folder of the Neuron ESB Install folder:  
        • At database version 9 (3.5.0.x): run 0010_UpdateTo3_5_0_34.sql, 0011_UpdateTo3_5_2.sql and 0012_UpdateTo3_5_3.sql 
        • At database version 10 (3.5.1.x): run 0011_UpdateTo3_5_2.sql and 0012_UpdateTo3_5_3.sql 
        • At database version 11 (3.5.2.x): run 0012_UpdateTo3_5_3.sql
      • Using Neuron ESB Explorer
        • open a configuration solution
        • navigate to Deployment > Databases and select the database
        • click the Test/Create button
    • The update could make changes to Test Client configuration which could be different than custom settings you might have set. To correct this: 
      • open a Neuron Test Client 
      • navigate to Tools > Connection Settings 
      • update the values for Address, Zone and Service Identity as needed

    Manual update:

    To manually install this update, do the following:

    • Stop the "Neuron ESB 3.5 Discovery Service" which should also stop the dependent Neuron ESB v3 instance services
    • Make backup copies of the following folders (examples assume that the Neuron ESB instances are installed in the child folder of the main install folder:   
      • - C:\Program Files (x86)\Neudesic\Neuron ESB v3   
      • - C:\Program Files\Neudesic\Neuron ESB v3 (or the location you installed Neuron ESB)   
      • - Each instance folder if not installed in C:\Program Files\Neudesic\Neuron ESB v3
    • Copy files from NeuronESB_3.5_CU3.zip "files\DiscoveryService" folder to C:\Program Files (x86)\Neudesic\Neuron ESB v3
    • Copy files from NeuronESB_3.5_CU3.zip "files\InstallPath" folder to C:\Program Files\Neudesic\Neuron ESB v3 (or the location you installed Neuron ESB)
    • For each Neuron ESB Instance being updated that is running x64 version of files, copy files from NeuronESB_3.5_CU3.zip "files\Instancex64" folder to instance folder
    • For each Neuron ESB Instance being updated that is running x86 version of files, copy files from NeuronESB_3.5_CU3.zip "files\Instancex86" folder to instance folder
    • For each database at version 9, 10 or 11, upgrade them to database version 12 by doing one of the following:
      • Using SQL Server Management Studio, run the following contained in the Sql folder of the Neuron ESB Install folder:  
        • At database version 9 (3.5.0.x): run 0010_UpdateTo3_5_0_34.sql, 0011_UpdateTo3_5_2.sql and 0012_UpdateTo3_5_3.sql
        • At database version 10 (3.5.1.x): run 0011_UpdateTo3_5_2.sql and 0012_UpdateTo3_5_3.sql
        • At database version 11 (3.5.2.x): run 0012_UpdateTo3_5_3.sql
      • Using Neuron ESB Explorer
        • - open a configuration solution
        • - navigate to Deployment > Databases and select the database
        • - click the Test/Create button
    • Start the "Neuron ESB 3.5 Discovery Service" and each "Neuron ESB v3 ..." instance service
    • The update could make changes to Test Client configuration which could be different than custom settings you might have set. To correct this:
      • - open a Neuron Test Client
      • - navigate to Tools > Connection Settings
      • - update the values for Address, Zone and Service Identity as needed.
    • Delete the following old files from each Neuron ESB Instance folder:
      • - Infragistics4.Shared.v13.2.dll 
      • - Infragistics4.Win.Misc.v13.2.dll 
      • - Infragistics4.Win.UltraWinDataSource.v13.2.dll 
      • - Infragistics4.Win.UltraWinEditors.v13.2.dll 
      • - Infragistics4.Win.UltraWinGrid.v13.2.dll 
      • - Infragistics4.Win.v13.2.dll 
      • - Xceed.Compression.Formats.v5.6.dll 
      • - Xceed.Compression.v5.6.dll 
      • - Xceed.FileSystem.v5.6.dll 
      • - Xceed.Ftp.v5.6.dll 
      • - Xceed.GZip.v5.6.dll 
      • - Xceed.SSH.Client.v5.6.dll 
      • - Xceed.SSH.Core.v5.6.dll 
      • - Xceed.SSH.Protocols.v5.6.dll 
      • - Xceed.SSH.SFtp.v5.6.dll 
      • - Xceed.Tar.v5.6.dll 
      • - Xceed.Zip.v5.6.dll
    (1 vote(s))
    This article was helpful
    This article was not helpful

    Comments (0)
    Post a new comment
     
     
    Full Name:
    Email:
    Comments:
    Help Desk Software by Kayako Fusion