I am inheriting a project which I am migrating from 2006 to 2010.
From what I understand, when I deploy a BizTalk solution from Visual Studio, the required ports should have stubs created automatically in the application.
Currently no ports are being created when I deploy. Is there a configuration option I'm missing for this, or am I incorrect in my understanding and have to send up all the ports manually?
Send/Receive Ports will only be created automagically if you have an Orchestration/s that has a Send or Receive Port configured with its Binding as 'Specify Now' - this approach bakes the port configuration into the Orchestration and is then created when you deploy:
You will also see really funky Receive Port names following the deployment:
and Receive Location names:
This is the wrong approach IMHO - Send and Receive Ports should be created, configured and bound manually via the BizTalk Administration Console once you have deployed your solution. This way, you separate your service (orchestrations etc.) from your configuration bindings, which may change with each environment. Furthermore, you don't have funky port names in production that will need to be deleted :-)
I would recommend scripting the deployment once you have sufficient knowledge of BizTalk - this will also include importing configuration bindings once you have deployed your BizTalk assemblies (Orchestrations, Schemas, Pipelines etc.)
Related
I am struggling to find a way to register multiple gateways. I have a local instance of my SQL server and have created a gateway to access to it from the AML Studio workspace. It works fine but now I would like to access to the same SQL server instance from another workspace. So the question is: how to register a new gateway without removing the previous one?
I followed this documentation.
Does the following explanation mean that there is no way to do that?
You can create and set up multiple gateways in Studio for each workspace. For example, you may have a gateway that you want to connect to your test data sources during development, and a different gateway for your production data sources. Azure Machine Learning gives you the flexibility to set up multiple gateways depending upon your corporate environment. Currently you can’t share a gateway between workspaces and only one gateway can be installed on a single computer.
It is quite limiting as connecting to the same server from multiple workspaces may be sometimes crucial.
Well, finally I have found a way to bypass this limitation. From this documentation I have found that:
The IR does not need to be on the same machine as the data source. But staying closer to the data source reduces the time for the gateway to connect to the data source. We recommend that you install the IR on a machine that's different from the one that hosts the on-premises data source so that the gateway and data source don't compete for resources.
So the logic is pretty simple. You provide access to your local server to another machine on vpn and install your gateway there. Important: I have set up the firewall rules on the server before, to be able to establish the connection remotely.
I have a BizTalk Server 2010 installed in windows server 2008 R2. When i publish wcf service through wizard and try to run the service on browser, it returns an error :
The Messaging Engine failed to register the adapter for
"WCF-BasicHttp" for the receive location
"/OrderProcessingDescription/OrderProcessService.svc". Please verify
that the receive location exists, and that the isolated adapter runs
under an account that has access to the BizTalk databases.
Also account used in the application pool is a member of the BizTalk Isolated Host Users group.
One thing which is not installed in Windows Server 2010 is Domain Controller. Please let me know if I need to install it .
please see the following thread to check the actual error:
Link to thread
Answer from thread:
To solve this issue check the application pool security user account
in the IIS. Add that user account into the BizTalk Isolated Host Users
group. Or change the application pool to the pool which user is
already a member of the BizTalk Isolated Host Users Group.
The domain controller feature actually has very little to do with this and the feature is likely not to be installed on your BizTalk server.
Since you are using the publishing wizard:
Ensure that there is an app pool available which is linked to a BTS Isolated host account (you seem to have done this).
Ensure that the app/virtual directory created by the wizard in IIS for the basicHttp endpoint is configured to use this app pool.
Ensure that the corresponding receive port is created, and enabled (look in the BizTalk admin console).
Also ensure that the BTS host process for the receive port is running.
Has anyone experienced running multiple collaborating applications on Heroku? For example, an admin application to manage another application; or a stats server observing another application?
On Amazons' EC2 platform you can use security groups to restrict access to servers, creating a virtual network between your application or server instances. Is there any such way to do this on Heroku? If so, can you open UDP as well as TCP connections?
Thanks
Robbie
The comment from #elithrar is correct. To talk between applications you either need to define an API, or used shared resources. For example you can have 2 applications connect to the same database by manually copying and pasting the DATABASE_URL from one app to another. This has the downside that should we need to roll credentials (very rare) your manually copied configuration will break.
The same pattern can be used with any add-ons, such as https://addons.heroku.com/redistogo or https://addons.heroku.com/iron_mq to share a message bus or queue between two applications.
I've downlaoded the nsoftware sftp adapter for Biztalk.
I created a few send & receive ports within Biztalk admin just to see if it works, and it does.
I now need to build an orchestration with an sftp send port and sftp receive port.
I've added a reference to the adapter dll and included it in the project, but I'm not sure how to wire it up to my 2 ports in the .odx file.
Can anyone shove me in the right direction?
The only reason you'd have a project-level reference to the adapter DLL is if you need to use the property schemas for the nsoftware adapter; otherwise, the way you'd use it is the same way you'd use any other BizTalk adapter:
Declare your logical ports in your orchestration. Make sure you mark them as "Specify Later" (or direct/dynamic, if you're doing more advanced scenarios).
Build your orchestration as usual
Deploy
Go to the BizTalk administration console and create receive locations/send ports as necessary specifying the nsoftware SFTP adapter. You'll be able to enter all the adapter configuration settings there.
If you could share any more details about what you're trying to do, maybe I could offer more specific advice.
What are some good articles/ resources to understand how load balancing is configured with Biztalk --- both in terms of inherent abilities of the product as well as employing NLB (network load balancing with Windows 2003 or later editions)?
EDIT: I am specifically interested in the impact of application protocol on load balancing? For example, how two instances of Biztalk server handle TCP/IP connections when the other party (to which Biztalk makes a connection request) doesn't allow more than one connection, etc.
The obvious resource is MSDN - There is a section entitled Planning for High Activity that covers most of the concepts and will give you the right terminology to then go looking for other resources on the web. As with a lot of Microsoft server products, MSDN also has lots of white papers covering specific BizTalk scenarios.
Most good BizTalk books also include a section on load balancing concepts (Professional BizTalk Server 2006 has an example).
Beyond that, there are several key concepts that you may find helpful, particularly around the use of terminology (some of BizTalk's usage can be misleading).
Load Balancing
BizTalk Server is, by the nature of its architecture, load balancing. What that means is that if you have more than one BizTalk Host connecting to a MessageBox database, the messages within the database will be spread evenly across the hosts participating in the BizTalk group. (with caveats around just what BizTalk processess have been configured to run in each Host).
There is also the concept of Network Load Balancing which is Microsoft Network Load Balancing Services or any equivalent service. In BizTalk this applies at the web level, for receive adapters using the HTTP protocol (e.g. the HTTP adapter, the SOAP adapter and WCF HTTP adapters). This load balancing is not actually a BizTalk service but is instead a load balancing layer provided on top of the BizTalk isolated host adapters to ensure high availability of the web resources. It is configured the same as any other NLB service.
Clustering
When clustering is mentioned in BizTalk it is used to refer to one of two things - clustering at the SQL layer to provide high availability and failover, and BizTalk Host Clustering.
SQL Clustering - this is simply (though it isn't simple to do, just say) a matter of providing a SQL server cluster that runs the BizTalk server databases, allowing for database failover. This is not a BizTalk specific technology.
BizTalk Host clustering - in this case a BizTalk Server Host is marked as being clustered when creating it inside BizTalk. This is a BizTalk specific setting that essentially states that one and only one instance of the host will be running at a time, and that by extension all the resources within this host will also only have a single instance. It is primarily intended for usage for adapters like the FTP and MSMQ adapters that behave incorrectly when more that one is allowed to run at the same time.
This edit is in response to the OP's comment asking for further details. Hopefully this make things clearer. If you have more questions about specifics I can possibly answer them but this pretty much exhausts my theory knowledge about high availability environment configuration. I'm primarily a BizTalk dev and solution designer, when it comes to network intricacies there are people where I work who fill in the nitty gritty detail and implementation of these designs.
Network Load Balancing for HTTP Based Adapters
The key point I was trying to express here was that Network Load Balancing in the context of BizTalk is no different for any other Network Load Balancing scenario.
BizTalk has two type of hosts, In Process and Isolated. In Process hosts are individual BizTalk services running on servers (with one host instance per server). Isolated hosts are actually delegates to a web server (IIS) that handle all HTTP based adapters (the HTTP adapter and the SOAP adapter plus certain configurations for the WCF adapter)
When you introduce Network Load Balancing to a BizTalk environment what you are doing is intoducing it at the web server layer, for the Isolated host hosted adapters.
Here is the MSDN page for the introduction to NLB. One of the key points about NLB is expressed in the page in the following quote:
Network Load Balancing allows all of
the computers in the cluster to be
addressed by the same set of cluster
IP addresses (but also maintains their
existing unique, dedicated IP
addresses).
By setting up NLB you allow multiple isolated host servers to handle internet traffic directed at a single dedicated IP address. The NLB configuration farms out the work.
Clustering BizTalk Adapter Handlers
In my answer above I stated that certain BizTalk adapters behave incorrectly when allowed to run within multiple BizTalk Host Instances. This is very adapter specific in terms of the why, so the best expansion on that answer I can give is the following quote from the MSDN documentation, dealing with the FTP adapter specifically.
For most of the BizTalk integrated
adapters, high availability can be
achieved by creating multiple adapter
handlers to run on BizTalk host
instances on different BizTalk servers
within a BizTalk group. FTP adapter
receive handlers should not, however,
be configured to run in multiple
BizTalk host instances simultaneously.
This recommendation is made because
the FTP receive adapter uses the FTP
protocol to retrieve files from the
target system and the FTP protocol
does not lock files to ensure that
multiple copies of the same file are
not retrieved simultaneously when
running multiple instances of the FTP
receive adapter.
As they say, the FTP adapter utilises the FTP protocol which does not lock files. Because BizTalk is natively a highly parallel system, if you allowed multiple BizTalk hosts to host an instance of the FTP adapter you would end up with multiple copies of the same FTP message received into your BizTalk system. What BizTalk clustering does is ensure that any clustered BizTalk hosts will run on 1 and only 1 host instance. By placing your FTP receive handler inside a clusterd host, you ensure that:
you will always have an FTP adapter running so long as a BizTalk host is running
you will never have more than one FTP adapter running.
Additionally you can use a BizTalk clustered host to reduce load on a system. For example, a BizTalk SQL adapter receive location that has been configured to poll, will poll on all host instances. While this would not necessarily cause multiple message instances, it could cause undue load on the SQL server you poll, or even create deadlock scenarios depending on the design of the called stored procedure, so clustering the SQL Adapter receive handler can be a good idea.