Neudesic Blogs

Passion for Innovation

Neuron ESB 2.5.13 Release Available Now!

I’m very pleased to announce the July Feature release update (version 2.5.13) for Neuron ESB. This can be downloaded here

The product team is very excited about this release as it’s contains many new features which our customers will immediately benefit from. This release moves us further in ensuring that developing and deploying Neuron solutions continues to become easier for our customers. This release contains accumulated fixes, documentation updates, as well as incremental, customer requested updates to Neuron ESB:

·         Custom Pipeline Steps – Users will be able to create a reusable custom Pipeline Steps, register them, and use them within the Neuron ESB Pipeline Designer by simple drag and drop.

·         MSMQ Pipeline Step – This will provide users the ability to send messages to a Queue within a pipeline.  It will also support correlated receives from a Queue as well.

·         Pipeline Execution Pipeline Step – Provides the ability to create composite pipelines by executing existing pipelines within a pipeline for easy reuse.

·         Global Pipeline Cache – This will support the creation and initialization of any variable type that can be used across all instances of a pipeline executed by a Neuron Party

·         Custom SOAP Header Support for the Service Pipeline Step

·         Dynamic Transform Pipeline Step – Allows users to determine XSLT to run at runtime, rather than design time

·         Dynamic Schema Pipeline Step – Allows users to determine Schema to validate against at runtime, rather than design time

·         Environmental Variable support for Service/Client Connectors – This was the last step to make deployment truly easy for all customers. This deprecates the use of the Addresses tab located on Deployment Groups.

·         Multi-threaded receive for MSMQ based topics – This provides performance enhancements.

·         MSMQ Time to Live – The ability to set this property at the Topic level

·         WSDL support for Client Connectors - Ability to associate an existing WSDL endpoint with Client connectors so developers can use “add service reference” or “add web reference” within Visual Studio by referencing the client connector configured urls

·         Resubmit – the ability to resubmit a message directly from either the Audit or Failed Message reports.  In the next feature release we’re going to try to introduce bulk resubmit as well as the ability to resubmit to a specific adapter or service endpoint.

·         Reorder Pipelines – The ability to re order pipelines for a party within the UI so that users do not have to remove and then re-add.

·         RFID Sync and Async enhancements – Refactored to increase performance by 10 fold, as well as remove need to modify configuration files and enhanced tracing

·         Scatter Gather Sample – Updated the scatter gather sample and documentation (see attached) to use new Dynamic Transform Pipeline Steps

·         Unique WMI Performance Counters– By default Neuron ESB generates performance counter names for Parties using the Party Name appended by a guid.  Now we provide an option to generate these names by only using the Party name.  This allows predictable use of 3rd party monitoring tools


Besides new features, this release includes all the accumulated bug fixes from the past few months, since our previous 2.5.10 release in April 2011. Some of these fixes include the following:

·         Performance enhancements for service endpoints

·         Exception propagation for service endpoints to calling clients

·         Several Neuron “Farm Mode” fixes/enhancements were introduced to ensure resilience and reliability. Neuron Farm mode is used to scale out Neuron servers when using TCP based topics in conjunction with  the remote Neuron ESB client API. 

·         Several “DirectConnect” fixes were introduced.  DirectConnect mode is used for routing to service endpoints within a Pipeline, circumventing the Neuron Pub/Sub engine

·         Under certain conditions a service connector’s service policy would fail to execute when the WCF Message could not be created from the Neuron ESB Message.

·         Removed duplicate event log registry entries which were causing event information to be written to the disk file in the Log directory rather than the event log.

·         Code pipeline step no longer uses temp files.

·         Exceptions that occur in a pipeline are now passed back to a requesting client.

·         Removed duplicate failure exceptions being logged in the failed message database

·         Corrected issue where Party name and direction were incorrectly logged or missing in failed message database

·         Corrected issue where the service url in the Service Pipeline Step could being used rather than the metadata url even though the value was empty.

 

As always, the complete list of changes can be found in the change log (Neuron Change Log) installed at the root of the Neuron ESB installation directory as well as on our support site.

As an addendum to our shipped documentation, I’ll be regularly posting information on how to use the new features, so continue to monitor our blog and forums!

 

Kind regards,

Marty Wasznicky
Neuron ESB

Neudesic, L.L.C.
Work: (949) 754-5223

Fax: (949) 754-6523

marty.wasznicky@neudesic.com
| www.neudesic.com

Posted: Jul 29 2011, 13:00 by marty.wasznicky | Comments (0) RSS comment feed

Tags:
Categories: AppFabric | Connected Systems | General | Headlines | Neuron | Neuron ESB | WCF

Neuron ESB 2.5.13 Pre Release Announcement

Hello Everyone,

As many of you know we've been hard at work on the Neuron ESB feature release for July.  Our goal is to send out a general announcement at the end of this week (July 29th) to let users know where to download it, and how to use some of the new features.  The "how to use" part though may come over the weekend, as I think there is a lot to write about :).

I'm personally very excited about this release as it’s going to include many features I think a lot of our customers have wanted, and many features that will make developing and deploying Neuron solutions much easier to do. Besides new features, this release will include all the accumulated bug fixes from the past few months. Some of the features we’re including in this release are:

·         Custom Pipeline Steps – Users will be able to create a reusable custom Pipeline Steps, register them, and use them within the Neuron ESB Pipeline Designer by simple drag and drop.

·         MSMQ Pipeline Step – This will provide users the ability to send messages to a Queue within a pipeline.  It will also support correlated receives from a Queue as well.

·         Pipeline Execution Pipeline Step – Provides the ability to create composite pipelines by executing existing pipelines within a pipeline for easy reuse.

·         Global Pipeline Cache – This will support the creation and initialization of any variable type that can be used across all instances of a pipeline executed by a Neuron Party

·         Custom SOAP Header Support for the Service Pipeline Step

·         Dynamic Transform Pipeline Step – Allows users to determine XSLT to run at runtime, rather than design time

·         Dynamic Schema Pipeline Step – Allows users to determine Schema to validate against at runtime, rather than design time

·         Environmental Variable support for Service/Client Connectors – This was the last step to make deployment truly easy for all customers. This deprecates the use of the Addresses tab located on Deployment Groups.

·         Multi-threaded receive for MSMQ based topics – This provides performance enhancements.

·         MSMQ Time to Live – The ability to set this property at the Topic level

·         WSDL support for Client Connectors - Ability to associate an existing WSDL endpoint with Client connectors so developers can use “add service reference” or “add web reference” within Visual Studio by referencing the client connector configured urls

·         Resubmit – the ability to resubmit a message directly from either the Audit or Failed Message reports.  In the next feature release we’re going to try to introduce bulk resubmit as well as the ability to resubmit to a specific adapter or service endpoint.

·         Reorder Pipelines – The ability to re order pipelines for a party within the UI so that users do not have to remove and then re-add.

·         RFID Sync and Async enhancements – Refactored to increase performance by 10 fold, as well as remove need to modify configuration files and enhanced tracing

·         Scatter Gather Sample – Updated the scatter gather sample and documentation (see attached) to use new Dynamic Transform Pipeline Steps

·         Neuron Farm Enhancements – Numerous fixes were introduced to support Neuron Farm mode with TCP based topics

·         Unique WMI Performance Counters– We no longer generate performance counter names using Guids.  Now they are generated by appended the Party name with a number.  So if only one instance of a Party is used, the Performance counter name will now be predictable.

 

Stay tuned this channel!  Once I finish the “What’s New” and “How to use it” documentation, I’ll post the download link and the docs.

Kind regards,

Marty Wasznicky
Neuron ESB

Neudesic, L.L.C.
Work: (949) 754-5223

Fax: (949) 754-6523

marty.wasznicky@neudesic.com
| www.neudesic.com

     


Posted: Jul 26 2011, 09:07 by marty.wasznicky | Comments (0) RSS comment feed

Tags:
Categories: Neudesic Main | AppFabric | Connected Systems | Dynamics CRM | Neuron | Neuron ESB | WCF

Visual Studio 2010 and MsBuild Tasks for Azure Deployment

While Windows Azure SDK and Windows Azure Tools for Visual Studio help a lot when developing and deploying Cloud Services, there's still much to be desired, especially with managing application setting and numerous connection strings between development, cloud staging and production, as well as “mixed mode” deployments. Where there's no place for human errors - automation rules, which is where MsBuild can help.

 

Let’s say I have this service configuration

 

 <?xml version="1.0" encoding="utf-8"?>
<ServiceConfiguration serviceName="WindowsAzureProject1" xmlns="http://schemas.microsoft.com/ServiceHosting/2008/10/ServiceConfiguration" osFamily="1" osVersion="*">
  <Role name="MvcWebRole1">
    <Instances count="1" />
    <ConfigurationSettings>
      <Setting name="Microsoft.WindowsAzure.Plugins.Diagnostics.ConnectionString" 
               value="UseDevelopmentStorage=true" />
      <Setting name="Greeting" value="Hello from Azure (Dev) Web Role!" />
    </ConfigurationSettings>
  </Role>
</ServiceConfiguration>

 

and want to deploy the service to the cloud with:

 


<?xml version="1.0" encoding="utf-8"?>
<ServiceConfiguration serviceName="WindowsAzureProject1" xmlns="http://schemas.microsoft.com/ServiceHosting/2008/10/ServiceConfiguration" osFamily="1" osVersion="*">
  <Role name="MvcWebRole1">
    <Instances count="2"/>
    <ConfigurationSettings>
      <Setting name="Microsoft.WindowsAzure.Plugins.Diagnostics.ConnectionString" 
         value="DefaultEndpointsProtocol=https;AccountName=[cloud account];AccountKey=[account key]"/>
      <Setting name="Greeting" value="Hello from Azure (Published) Web Role!"/>
    </ConfigurationSettings>
  </Role>
</ServiceConfiguration>

 

While it is possible to modify .cscfg via a generic Xslt transformation, it is preferable to use transform file using the http://schemas.microsoft.com/XML-Document-Transform syntax (as used with ASP.NET 4.0 projects). The transform file to use, ServiceConfiguration.Publish.cscfg, could look like:


<?xml version="1.0" encoding="utf-8"?>
<sc:ServiceConfiguration serviceName="WindowsAzureProject1" osFamily="1" osVersion="*"
  xmlns:sc="http://schemas.microsoft.com/ServiceHosting/2008/10/ServiceConfiguration"
  xmlns:xdt="http://schemas.microsoft.com/XML-Document-Transform">
  <sc:Role name="MvcWebRole1" xdt:Locator="Match(name)">
    <sc:Instances count="2" xdt:Transform="Replace" />
    <sc:ConfigurationSettings>
      <sc:Setting name="Microsoft.WindowsAzure.Plugins.Diagnostics.ConnectionString" 
          value=" DefaultEndpointsProtocol=https;AccountName=[cloud account];AccountKey=[account key]" 
          xdt:Locator="Match(name)" xdt:Transform="Replace" />
      <sc:Setting name="Greeting" value="Hello from Azure (Published) Web Role!" xdt:Locator="Match(name)" xdt:Transform="Replace" />
    </sc:ConfigurationSettings>
  </sc:Role>
</sc:ServiceConfiguration>

 

This resembles the original configuration file but contains only items that need to be added, modified or removed (notice xdt:Locator and xdt:Tranform attributes).

To make the transformation work, one needs to import and use TransformXml task within a target which executes after the “CorePublish” task.

 

Here is how (as the Cloud Service projects allows for limited actions what can be added using VS UI, the file need to be added and .ccproj file edited manually):

 

1.       Copy the transform file (ServiceConfiguration.Publish.cscfg) to the cloud service folder (in Windows Explorer).

2.       Unload the Cloud Service Project (right-click the project, then select Unload Project).

3.       Open the project file for editing (Right-click the project, then select Edit [project name].ccproj).

4.       Add the following task after the last target in the project file:

 

<Import Project="$(MSBuildExtensionsPath)\Microsoft\VisualStudio\v10.0\Web\Microsoft.Web.Publishing.targets" />

<ItemGroup>
    <EnvironmentConfiguration Include="ServiceConfiguration.Publish.cscfg">
      <BaseConfiguration>ServiceConfiguration.cscfg</BaseConfiguration>
    </EnvironmentConfiguration>
    <None Include="ServiceConfiguration.Publish.cscfg">
      <DependentUpon>ServiceConfiguration.cscfg</DependentUpon>
    </None>
  </ItemGroup>
  <Target Name="TransformEnvirontmentConfiguration" AfterTargets="CorePublish">
    <MakeDir Directories="$(OutDir)TransformCscfg" />
    <Copy SourceFiles="$(OutDir)Publish\%(EnvironmentConfiguration.BaseConfiguration)" 
        DestinationFiles="$(OutDir)TransformCscfg\%(EnvironmentConfiguration.BaseConfiguration)" />
    <TransformXml Source="$(OutDir)TransformCscfg\%(EnvironmentConfiguration.BaseConfiguration)" 
        Transform="%(EnvironmentConfiguration.Identity)" 
        Destination="$(OutDir)Publish\%(EnvironmentConfiguration.BaseConfiguration)" />
    <Message Importance="high" 
        Text="Transformed %(EnvironmentConfiguration.BaseConfiguration) using %(EnvironmentConfiguration.Identity) into $(OutDir)Publish\%(EnvironmentConfiguration.BaseConfiguration)" />
  </Target>

 

5.       Save and close the file, then reload the project.

 

 

The above fragment imports ASP.NET 4.0 MsBuild targets, includes the transform file into the project fold and defines a new target named "TransformEnvironmentConfiguration" to be executed before "CorePublish" (one of the Cloud Service project tasks). The transform task internally makes a working folder TransforCscfg, where it copies the service configuration file, after which the required transformatino takes place. Note that copying to the working folder is a workaround to the bug in TransformXml which keeps a lock and prevent successful completion of the MsBuild script.

 

Now when the Cloud Service project is published to the cloud or to the intermediary location, the transformation kicks in.

If the project was published locally, it can be executed in "mixed mode", i.e. running in the compute emulator while using cloud storage service and other resources by adding yet another another task to the project: 

 

  <Target Name="RunPublishedServiceConfig">
    <Exec Command="&quot;$(ServiceHostingSDKInstallDir)bin\csrun.exe&quot; /run:$(OutDir)$(ProjectName).csx;$(OutDir)Publish\%(EnvironmentConfiguration.BaseConfiguration) /launchbrowser" />
  </Target>

 

The task can be then invoked as an external tool from Visual Studio as follows:

Command: C:\Windows\Microsoft.NET\Framework\v4.0.30319\MSBuild.exe
Arguments: $(ProjectDir)$(ProjectFileName) /T:RunPublishedServiceConfig

This works well for an ideal solution where the roles use RoleEnvironment class to obtain settings and connection strings. In Azure deployments, storing these in web.config and app.config files is very close to "hard coding", as any change requires re-deployment of the service. In a previous project I was able to add similar transforms for each web and worker role .config. What remains is to enable multiple transforms for different deployment targets, such a staging and production. I hope I'll figure it out before the next Azure project.

Posted: Jul 01 2011, 10:11 by Milenko.Djuricin | Comments (1) RSS comment feed

Tags:
Categories: Azure | Custom Application Development

Tags

Categories

Archive

Blogroll

Neudesic Social Media

Follow Neudesic on Twitter Follow Neudesic on Facebook Neudesic Neudesic