biztalk

I have been bitten by a poorly architected solution. It is not thread safe! I have several shared classes and members in the solution, and during development all was cool... BizTalk has sunk my battle ship. We are using a custom BizTalk Adapter to call my assemblies. The Adapter is calling my code and running things in parallel, so I assume it is using multiple threads all under the same AppDomain. What I would like to do is make my code run under its own AppDomain so the shared problems I have will not muck with each other. I have a very simple class that the BizTalk adapter is instantiating

I am looking into architectural patterns, Enterprise Services Bus (ESB) precisely. Upon reading this article Enterprise Integration , and with little to no experience I am wondering if BizTalk has is a ESB or is it just a EAI (Hub/Spokes or Bus)? I found this NServiceBus and Biztalk , describing BizTalk as a central message broker. Taking other ESB frameworks into account (NServiceBus and Rhino Service Bus). These frameworks have no central point to process messages. Is Biztalk a EAI rather than an ESB? Many thanks BizTalk is punted by Microsoft as having ESB capabilities - see the BTS ESB

I am developing a solution which involves reading messages from an Azure service bus queue using the BizTalk SB-Messaging adapter. I am using the BizTalk Deployment Framework to deploy the application without user input. Some adapters have an option to acquire credentials for external systems using the Single Sign-On database (option 'Use SSO'). The SB-Messaging adapter doesn't have this feature, and requires that either ACS (Access Control Service) or SAS (Shared Access Secret) credentials for the service (in this case a queue) are entered in the UI. BTDF can also set them by entering them in

In my limited experience with BizTalk it seems that BizTalk projects and Visual Studio version are somewhat locked to each other. For example, you can't open a BizTalk 2010 project in Visual Studio 2012, you have to have BizTalk 2013 components installed on your development machine in order to do so. So, my question is this, will Visual Studio 2013 support BizTalk 2013 projects (or even possibly BizTalk 2010 projects for that matter) or will we be stuck using VS 2012 for BT projects? Edit: I had previously added an answer as follows: Sheesh, I don't know what Google search terms I was using

Is there a way to automate the turning on or off of a Receive Location in BizTalk? It seems like there should be some kind of API or some such for this kind of thing. I would prefer to work in C#, but WMI or some kind of script would work too. Besides ExplorerOM, as you've found out, you can also enable/disable receive locations (and control send ports) using WMI. I have a sample PowerShell script that shows how to do those things here , if you're interested. I found a solution. It appears that the Microsoft.BizTalk.ExplorerOM.dll is what I wanted. Here is an excerpt from the BizTalk

I have an assembly that may be used by more than one process at a time. If I am using a static class, would the multiple processes all use the same "instance" of that class? Since the processes are separate, would these be running under difference Application Domains, hence have the static "instances" separate? The pudding in the details here is that the assembly is being used by a custom BizTalk adapter that my be set to process the messages in parallel batches. That is what I am calling "multiple processes" above. Multiple threads would share an instance. For this reason a static class can

I'd like to create a MSBuild project that reflects the project dependencies in a solution and wraps the VS projects inside reusable targets. The problem I like solve doing this is to svn-export, build and deploy a specific assembly (and its dependencies) in an BizTalk application. My question is : How can I make the targets for svn-exporting, building and deploying reusable and also reuse the wrapped projects when they are built for different dependencies? I know it would be simpler to just build the solution and deploy only the assemblies needed but I'd like to reuse the targets as much as