Recommended
Recommended
More Related Content
What's hot
What's hot (20)
Similar to Here are the answers to your questions:1. You can configure the Neuron ESB Runtime to use a specific Deployment Group by assigning that Deployment Group in the configuration of the Neuron ESB service. 2. A Deployment Group contains information like the Neuron ESB and MSMQ servers to use, the RabbitMQ configuration, the Endpoint Host deployment settings, and more.3. Environmental Variables can be defined and maintained in the Neuron ESB Explorer or in the esbservice.exe.config files.4. The values for Environmental Variables are stored encrypted within the Deployment Group XML files. 5. Environmental Variables can be used almost anywhere bindings expressions are supported, in
Similar to Here are the answers to your questions:1. You can configure the Neuron ESB Runtime to use a specific Deployment Group by assigning that Deployment Group in the configuration of the Neuron ESB service. 2. A Deployment Group contains information like the Neuron ESB and MSMQ servers to use, the RabbitMQ configuration, the Endpoint Host deployment settings, and more.3. Environmental Variables can be defined and maintained in the Neuron ESB Explorer or in the esbservice.exe.config files.4. The values for Environmental Variables are stored encrypted within the Deployment Group XML files. 5. Environmental Variables can be used almost anywhere bindings expressions are supported, in (20)
More from StephenKardian
More from StephenKardian (20)
Recently uploaded
Recently uploaded (20)
Here are the answers to your questions:1. You can configure the Neuron ESB Runtime to use a specific Deployment Group by assigning that Deployment Group in the configuration of the Neuron ESB service. 2. A Deployment Group contains information like the Neuron ESB and MSMQ servers to use, the RabbitMQ configuration, the Endpoint Host deployment settings, and more.3. Environmental Variables can be defined and maintained in the Neuron ESB Explorer or in the esbservice.exe.config files.4. The values for Environmental Variables are stored encrypted within the Deployment Group XML files. 5. Environmental Variables can be used almost anywhere bindings expressions are supported, in
- 2. Deployment and Configuration • Provide an understanding of Neuron ESB Deployment Groups • Understand the Endpoint Host Deployment Model • Provide an understanding of Environmental Variables • Learn Neuron ESB Solution Deployment Options • Understand High Availability Neuron ESB Requirements Goals
- 3. Deployment and Configuration • Configuring Neuron ESB Deployment Groups • Configuring Endpoints using Endpoint Hosts • Creating and Deploying Environmental Variables • Using Environmental Variables • Deploying Neuron ESB solutions • Neuron ESB High Availability Configurations Lesson Plan
- 4. Deployment and Configuration Deployment Groups • Provides environment-specific information to the Neuron ESB Runtime and its associated Endpoint Hosts, such as: • What values to use for endpoint properties, business process step properties, database connection strings, etc. • What Neuron ESB servers are expected to work together, sharing the same Neuron ESB solution • What Neuron ESB Database, MSMQ and Rabbit MQ servers to use • Only one Deployment Group can be assigned to a Neuron ESB Runtime Instance • All Deployment Groups are defined within a Neuron ESB Solution
- 5. Deployment and Configuration Deployment Groups A Neuron ESB Runtime can be configured to run a specific Deployment Group.
- 6. Deployment and Configuration Deployment Groups • Neuron ESB and MSMQ Servers that will be used are listed in the Machines tab • DO NOT USE LOCALHOST - If using remotely connected Parties • Use the netbios machine name, fully qualified domain name or IP address • Remote parties use the name listed to know what serve to connect to • If using MSMQ-based Topics, the MSMQ Server checkbox must be checked on at least one machine listed
- 7. Deployment and Configuration Deployment Groups • Rabbit MQ servers are listed in the RabbitMQ tab • If Rabbit MQ is not a clustered node set then ONLY enter 1 Rabbit MQ server • If working with a clustered node set, enter all machines in the cluster • Use vHost to replicate Deployment Group topology • E.g. create a vHost for each deployment group • Allows multiple deployment groups to share same Rabbit MQ node, while having their own isolated exchanges and queues!
- 8. Deployment and Configuration Deployment Groups • Endpoint Hosts • Provides Failover Clustering • Deployment Settings tab • Used to determine what servers within the Deployment Group should be used to round robin execution of endpoints on vs. what servers should be configured as failover servers
- 9. Deployment and Configuration Environment Variables Environmental Variables • Maintained in Neuron ESB Explorer • Contains name-value pairs • Just string values • Used to dynamically configure everything that needs data specific to the runtime server environment • Example: • URL or database connect string used from a server in QA may need to be different when running on a server in Production
- 10. Deployment and Configuration Environment Variables Environmental Variables • Each name is stored as an XML file in the EnvironmentVariables folder of a Neuron ESB Solution • Each Value is stored ENCRYPTED within their respective Deployment Group XML file located in the DeploymentGroup folder • Deploying an Environmental Variable means deploying BOTH files
- 11. Deployment and Configuration Environment Variables Maintaining Values • Using the Neuron ESB Explorer • Pros – easy to use • Cons – values visible to everyone • Alternatives • Values can be maintained in each esbservice.exe.config file • File based security can be used in each environment to limit access • Can be maintained in Source Control • Must Add the “neuron.environment” section to configSections • Don’t include other Deployment group XML files
- 12. Deployment and Configuration Environment Variables Applying Values • Bindings Expressions Dialog • Available almost everywhere • Can set any property using Environment Variables • Using C# in any Business Process or Workflow • HTTP Client Utility
- 13. Environmental Variables : Demo Purpose: To familiarize users with how to access and apply Environmental Variables Objectives: To acquaint users with the following: • Using Environmental Variables to configure endpoints for different groups • Accessing Environmental Variables in C#
- 14. Deployment and Configuration Deploying ESB Solutions Folder and file structure • Deployment Options • Xcopy • Repository Documents Won’t work with Xcopy • Neuron ESB Runtime will pick up new entity and process in about 15 seconds • Up to operations to ensure dependencies are deployed • Import/Export • Supports partial and full deployment • Handles selection of dependencies • Will import in correct order • UI or Command Line • Source Control
- 15. Deployment and Configuration Deploying ESB Solutions Import/Export • Neuron ESB Explorer • via the File Menu • Export • Prompted to accept dependencies • Creates an *.esb package file • Can generate response files (*.rsp file)
- 16. Deployment and Configuration Deploying ESB Solutions Import/Export • Neuron ESB Explorer • via the File Menu • Import • Can be used to import pre 3.0 ESB solutions • Users are prompted to select a *.esb package file to import • Will import into existing solution • Must press “Import” button
- 17. Deployment and Configuration Import/Export • Command Line • The programs are located in the Neuron Instance directory (e.g. “C:Program FilesNeudesicNeuron ESB v3DEFAULT” if installed in the default location) • Example syntax using the ExportConfig.exe program: ExportConfig.exe [options] path-to-directory path-to-esb-file • Where “path-to-directory” is the ESB configuration folder that you want to export elements from and “path-to-esb-file” is the path to the file that you want to save the exported elements to. • Example Usage: ExportConfig.exe --party ExamplePub “C:NeuronESBConfiguration” “C:Export.esb” ExportConfig.exe --party Party1 --party Party2 --process Process1 --process Process2 “C:NeuronESBConfiguration” “C:Export.esb” • Also will detect and support Response files ( e.g. *.rsp) ExportConfig @TopicsAndParties.rsp C:MyConfiguration C:TopicsAndParties.esb Deploying ESB Solutions
- 18. Deployment and Configuration Import/Export • Command Line • The programs are located in the Neuron Instance directory (e.g. “C:Program FilesNeudesicNeuron ESB v3DEFAULT” if installed in the default location) • Example syntax using the ImportConfig.exe program: ImportConfig.exe [options] path-to-esb-file path-to-directory • Where “path-to-directory” is the ESB configuration folder that you want to import elements to and “path-to-esb-file” is the exported esb file that you want to import from. • Example Usage: ImportConfig.exe --party ExamplePub “C:ExportedConfig.esb” “C:MyESBConfig” ImportConfig.exe “C:ExportedConfig.esb” “C:MyESBConfig” ImportConfig.exe --party Party1 --party Party2 --process Process1 --process Process2 “C:ExportedConfig.esb” “C: MyESBConfig” Deploying ESB Solutions
- 19. Deploying ESB Solutions : Demo Purpose: To familiarize users with how to deploy Neuron ESB artifacts to different servers/solutions Objectives: To acquaint users with the following: • Using Copy/Paste • Using Import/Export UI
- 20. Deployment and Configuration Multiple Instances • Windows NT Service – ESBService.exe • Multiple instances of runtime supported through Installer • Means you can run multiple Configurations on same box • Each Neuron ESB Runtime provided an “Instance” name at install time • Used to run - multi part solutions on same machine • Example: x86 and x64 living on same box • Solutions could “share” messages if using MSMQ queued Topics and configured with same Topic name. • Great way to take CPU/Thread intensive endpoints and assign them to a dedicated host instances Neuron ESB Runtime Financial Processing Solution Service Integration Gateway Neuron ESB Runtime Manufacturing Solution Neuron ESB Runtime Service Integration Gateway Neuron ESB Runtime Financial Processing Solution
- 21. Deployment and Configuration Multiple Instances • Considerations • Running Different Solutions • Port Configurations • All Solutions by default use same ports defined in Port tab of Zone Settings • Must be unique between Solutions • -OR- • Use TCP Port Sharing • MSMQ-based Topics • Topics must be uniquely named between solutions • RabbitMQ-based Topics • No issues • Client Connector URLs • Full addresses must be unique Neuron ESB Runtime Financial Processing Solution Service Integration Gateway Neuron ESB Runtime Manufacturing Solution Neuron ESB Runtime Service Integration Gateway Neuron ESB Runtime Financial Processing Solution
- 22. Deployment and Configuration Single Machine Deployment – No High Availability ActiveMQ MongoDB ActiveMQ Adapter MongoDB Adapter In-Memory Message Routing Neuron Server Neuron Database
- 23. Deployment and Configuration Single Machine Deployment – No High Availability ActiveMQ MongoDB ActiveMQ Adapter MongoDB Adapter MSMQ/RabbitMQ Durable Message Routing Neuron Server Neuron Database
- 24. Deployment and Configuration Multiple Machine Deployment – No High Availability ActiveMQ MongoDB MSMQ/RabbitMQ Neuron Server Neuron Server Neuron Database
- 25. Deployment and Configuration Multiple Machine Deployment –High Availability SAN ActiveMQ MongoDB Neuron Server Neuron Server MSMQ Server MSMQ Server Cluster MSMQ MSMQ SQL Cluster Neuron Database Neuron Database
- 26. Deployment and Configuration Multiple Machine Deployment –High Availability ActiveMQ MongoDB Neuron Server Neuron Server RabbitMQ Server RabbitMQ Server Cluster/Mirror RabbitMQ RabbitMQ SQL Cluster Neuron Database Neuron Database Load Balancer
- 27. Deployment and Configuration Review • How can you configure the Neuron ESB Runtime to use a specific Deployment Group? • What elements are contained within a Deployment Group? • What 2 places can you define Environmental Variables? • Where are the values for Environmental Variables stored? • Where can I use Environmental Variables? • When can I NOT use localhost as a machine name? • How do Endpoint Hosts use Deployment Groups? • What can’t I deploy using Xcopy? • What can I used from the Neuron ESB Explorer to move my changes to a Topic from one environment to another? • Where can I find deployment command line tools?
Editor's Notes
- The goals of this lesion are to provide users with an understanding of Neuron deployment groups; what are they and how can they be used. Teach users about the endpoint host deployment model. Show users how to use environmental variables in conjunction with deployment groups to make their solutions more dynamic based on environment. Take a look at the deployment options for Neuron ESB and finally look at the high availability requirements of Neuron ESB.
- To facilitate our goals this lesson has been broken down into six sections to make the information provided easier to understand. The sections that we will be covering are Configuring Neuron ESB Deployment Groups Configuring Endpoints using Endpoint Hosts Creating and Deploying Environmental Variables Using Environmental Variables Deploying Neuron ESB solutions Neuron ESB High Availability Configurations
- Deployment groups provide environment specific information to the Neuron ESB runtime and it’s associated endpoint hosts. Each Neuron Instance can be assigned a single deployment group, so for example the development instance of Neuron ESB would be assigned the development deployment group while the production instance of Neuron ESB would be assigned the production deployment group. The deployment group tells the Neuron instance a variety of information such as what machines are included in the environment, development could use ESBDev01 and ESBDev02 while production could use ESBProd01 and ESBProd02, the values to use for environment variables that effect endpoints, business processes and databases etc. Since deployment groups are assigned to the instance of Neuron ESB and only defined in the solution there is no need to make manual changes when moving a solution from one environment to another. If a solution with both a development deployment group and a production deployment group is moved from development to production, you do not need to make any changes to the solution to have production use the proper values as defined. Neuron ESB will automatically correlate its deployment group and the values in the solution.
- Defining a deployment group can be done either through the configure server dialog window in the Neuron ESB Explorer, under the Active Deployment Group drop down list, or via the esbDeploymentGroup setting in the appSettings section of the appSettings.config file for the Neuron ESB instance.
- Machines that are assigned to a deployment group are listed in the machines tab of the deployment group. You can add additional machines to this list by entering the name of the machine in the open space provided. If you are using remote parties do not use local host to identify the machine as the remote parties will attempt to use their local host and not the local host of the Neuron ESB instance. Rather you should use the netbios machine name, a fully qualified domain name or the IP address of the machine. Once you have your machines listed you can determine which machines are to be used as Neuron ESB servers and which machines are to designated for MSMQ by selecting, or de-selecting, the check box under in the appropriate column.
- Servers for RabbitMQ are listed on the RabbitMQ tab of the deployment group. When using RabbitMQ you must list all the servers that are part of the RabbitMQ clustered node set. If you are not using RabbitMQ in a clustered node set then only one RabbitMQ server should be listed on this tab. You never want to use the guest account, which is the default administrative account for RabbitMQ. The guest account is limited in that it cannot access remote installations of RabbitMQ. To address this you will first need to install the RabbitMQ Management Portal (https://www.rabbitmq.com/management.html). This will allow you to create a new administrator account which has permissions to access remote instances of RabbitMQ. Once you have created a new administrator account, you need to instruct Neuron ESB to use that account when interacting with RabbitMQ. Using vHost in RabbitMQ also provides a bit of flexibility as you can create a vHost for each deployment group which in turn allows you have multiple deployment groups share the same RabbitMQ node, while having their own isolated exchanges and queues.
- Endpoint hosts can also make use of deployment groups, from the deployment group tab of the endpoint host itself. Here you can select machines in the deployment group to use as primary machines for the endpoint host, and those to use as failover machines should the primary machines be unreachable. Having multiple primary machines will instruct Neuron ESB to use the servers in a round robin style execution, moving between machines to spread the work load out over all the primaries.
- Environmental variables are powerful entities that allow you to dynamically control many aspects of your Neuron ESB solution based on the deployment group. They are name value pairs, that contain string only values, and are leveraged in many areas of Neuron ESB such as adapter endpoints, service endpoints, business processes, workflows and even the Neuron ESB database connection. A good example of what an environmental variable can do for a solution is this: If you are building a solution that reaches out to a service, and that service is deployed to the development, QA and production environments, the URL for that service will not be the same in all environments. Using an environmental variable you can associate the correct URL with the environment (deployment group) to which it belongs. Then inside the service endpoint, instead of putting in a URL you can bind the environmental variable that you created to the URL property. So when you move your solution from development to QA, the Neuron ESB instance will automatically use the URL for QA as defined in the environmental variable, rather than the URL for development, without you having to make a manual change to the URL.
- Environmental variables are stored as XML files in the EnvironmentVariables foled of the Neuron ESB solution. All information pertaining to the environmental variable can be found here with the exception of the value for that environmental variable. As each deployment group will have a different value for the environmental variable, the values are stored, encrypted, in the xml file for the deployment group. Only the value for that deployment group is stored in the deployment group xml. This means that if you are deploying an environmental variable from one environment to another, you must deploy both files.
- While maintaining environmental variables via the Neuron ESB Explorer is incredibly easy, all values are in plain text and so anyone can see sensitive information if they have access to the Neuron ESB Explorer. An alternative to using the Neuron ESB Explorer is to add the environmental variables to the esbservice.exe.config file. To do this you must add the neuron.environment section to the configSections and then you can add variables to the neuron.environment section of the config file. As this method is used by a single instance of Neuron ESB, you would only add the values for that instances deployment group and not for the other deployment groups in the solution. These values can be scripted into the file during a release process and file based security can be used to ensure that no unauthorized users have access to the files contents.
- Once you have defined your environmental variables you need to bind them to the entities for which they apply. Almost every entity in Neuron ESB has a bindings expressions dialog, in which you can set a property to use an environmental variable. Additionally you can access environmental variables from the language editors in both business processes and workflows, as well as in the HTTP client utility available to both business processes and workflows.
- The Neuron ESB solution can be deployed to a new environment either via copy and paste deployment, or via the import/export feature of the Neuron ESB explorer. Copy and paste deployment is a quick and easy way to move the solution from one environment to another, but comes with a couple drawbacks. Repository documents can not be copy and paste deployed, as the meta data for these files is contained in the esb_configuration.xml document of the solution. Like wise dependencies are not automatically detected and deployed so it is up to operations, or the person performing the deployment, to ensure that these dependencies are deployed properly. The import/export feature of the Neuron ESB explorer provides you the ability to deploy your solution, by exporting it to a .esb package file, which can then be imported on in the target environment. Through the import/export system you can deploy every aspect of the solution for a full deployment, to include repository files, or you can select specific entities of the solution to deploy for a partial deployment. Dependencies for the entities selected are automatically detected by Neuron and you are offered the option to include them in the export as well.
- The export function of the Neuron ESB explorer is accessed via the file menu. When selected a dialog window will appear showing all the entities in the solution, separated into the appropriate categories such as Topic or Publisher/Subscriber. You can select specific entities to export, or click the select all button to select every entity in the solution. Once you have selected the entities you wish to export, click the export button to create the .esb package file. Clicking the save button does not produce a .esb file but rather a .rsp file. A .rsp file is one that contains a list of entities as selected. This allows you to create .rsp files for certain business flows, identifying which entities are part of that business flow, and can then be used via the command line version of export to export only those specific entities.
- The import function of the Neuron ESB explorer is accessed via the file menu. Once selected you file explorer window will be brought up so that you can select the .esb file that you would like to import. Selecting the .esb file will bring up the import dialog window where you can select the entities that you would like to import, or you can click the select all button to select all entities that are included in the .esb file (if the .esb file only contains certain entities of solution then only those entities would be imported).
- Both the import and export functions of the Neuron ESB Explorer can also be accessed via the command line using the ExportConfig.exe or the ImportConfig.exe. In regards to the ExportConfig.exe you can export either a solution, or specific entities from the solution. To export a full solution you simply need to provide path to the directory of the Neuron ESB solution and the path to the location where the .esb file should be created. If you want to export only specific entities you can provide the type of the entity, the name of the entity, the path to the directory of the Neuron ESB solution and the path to the location where the .esb file should be created. You may also use .rsp files to export the entities registered contained within.
- The ImportConfig.exe can import either an entire .esb file or just specific entities from a .esb file. To import an entire .esb file simply provide the path to the .esb file and the path to the location of the Neuron ESB solution to which the .esb file entities should be imported. To import only specific entities from a .esb file you simply need to provide the entity type, entity name, path to the .esb file and the path to location of the Neuron ESB solution to which the .esb file entities should be imported.
- Neuron ESB supports multiple instances installed on the same machine. This allows users to separate solutions into intelligent components, rather than stuffing everything into a single solution, allows solutions to share messages if using MSMQ queued topics configured with the same topic name, and is a great way to take CPU or thread intensive endpoints and assign them to a dedicated host. To install multiple instances on the same machine, simply install Neuron ESB a second time giving the instance a different name.
- However, when installing multiple instances on the same machine there are some things that you must take into consideration. As Neuron installs each instance with the same default ports all solutions running on the machine must either be configured to use port sharing, or must have their own unique set of ports defined. Solutions not intended to share messages, but using the same MSMQ server must have uniquely named topics, as MSMQ does not identify the instance just the topic name, unlike RabbitMQ which uses a concatenation of the instance and topic names. Client connector URLS must be unique full addresses.
- Here we have an example of a single machine deployment with no high availability. Everything is contained on the same machine, but there is no redundancy and should the machine go down everything goes down.
- This is an example of a single machine deployment with no high availability, similar to the previous slide. The difference here being that MSMQ or RabbitMQ is installed on the machine as well to allow for durable messaging.
- Here we have a multiple machine deployment scenario. However, as MSMQ/RabbitMQ is only on a single machine, same with the Neuron ESB database there are still single points of failure that could take the entire system down.
- This is a more optimal scenario. Here we have multiple machines running Neuron ESB, with clustered MSMQ servers and a SQL cluster, eliminating the single point of failure and providing high availability to the enterprise.
- Here we have what would be considered the most ideal scenario Multiple machines running Neuron ESB, with mirrored RabbitMQ servers and a SQL cluster, all fed by a load balancer.