by community-syndication | Mar 20, 2012 | BizTalk Community Blogs via Syndication
In my last post, I talked about the BizTalk AppFabric Connect for Services functionality for BizTalk. As you start to make your services accessible through the cloud you may find that you hit an error when you try to access the endpoint. You might also find that your endpoint doesn’t show up in the Windows Azure Portal.
In my case, I saw this error, in the screen shot below, when I clicked on the URL for my service in the AppFabric portal.
Then I saw that I had the following error in the Event Log.
I knew why the error in the Event Log was showing up. I have Windows Server AppFabric installed and had configured my service to Auto-Start. What I didn’t know was why I was getting the underlying error of not being able to reach watchdog.servicebus.windows.net. After doing a lot of searching on-line I couldn’t find anything that could solve the problem.
So, after talking to a member of the dev team who created the wizard functionality we found a fix. It turns out you will get this error when the service can not communicate with Azure. Since I had a proxy server in the mix, the fix was to add an entry in the config file in order for communications to flow through the proxy server. When the wizard completed it created a set of artifacts in IIS including a config file. Open that config file and we will add the entry below and place it just before the system.web section.
…
<connectionString />
<system.net>
<defaultProxy useDefaultCredentials="true">
<proxy proxyaddress="[your proxy address here]" />
</defaultProxy>
</system.net>
<system.web>
…
Enter your proxy address and you should see this error go away.
Blog Post by: Stephen Kaufman
by community-syndication | Mar 20, 2012 | BizTalk Community Blogs via Syndication
Last week I spoke at the Twin Cities Connected Systems User Group Meeting. The title of my presentation was Integration with Windows Azure – Connecting to the Cloud. During my presentation I talked about ways to expand on-premise applications to the cloud as well as how to connect cloud applications back to on-premise resources. As part of my presentation I talked about the functionality provided through the BizTalk AppFabric Connect for Services. There were a number of people that hadn’t heard of it so this entry talks about what it is and how it can be used.
So, as you build your composite applications, or just look to extend your current application, you may want to take advantage of the benefits offered by extending your application to Windows Azure. This will let you leverage your existing on-premise artifacts, and LOB systems, in order to expose them and extend their reach to external clients in a secure manner.
Microsoft released the BizTalk Server 2010 AppFabric Connect for Services as a new feature for BizTalk 2010 which provides functionality to expose your BizTalk artifacts (schemas and Orchestrations) as WCF Services exposed through the Windows Azure cloud. This new functionality is exposed through changes to the BizTalk WCF Service Publishing Wizard. When you run this wizard you will see a number of new screens in addition to the screens that you are already familiar with.
To expose BizTalk services to Windows Azure, specifically Windows Azure ServiceBus, you will need to have a few prerequisite components installed.
First, of course, you must have BizTalk 2010 and the BizTalk development tools installed on the machine where the AppFabric Connect for Service feature will be used.
Next, you must have the Windows Azure AppFabric SDK (1.0 or later) installed.
Lastly, there are benefits of having Windows Server AppFabric installed. While this is not a requirement, it makes configuration setting easier (such as Auto-Start).
After all the pre-requisites have been installed, you will need a Windows Azure account and you will need to create a namespace for the Service Bus in the Azure Portal.
Once this is done then you can start the wizard and walk through each of the screens. The wizard walks you through selecting the type of endpoint (service or metadata) – as it did previously. The next screen will be a new screen which will fork between the functionality of the old wizard (exposing web services on-premise only) or to sprinkle in the new screens to allow you to expose the services to the cloud. This screen presents a single checkbox asking if you want to add a Service Bus endpoint. It also reminds you that you need to have a ServiceBus service namespace. Select the checkbox (otherwise there is really no need to keep reading this post). The next five screens are the same as the screen in the original wizard (select either schemas or Orchestrations, select the assembly, select the public ports, assign the target namespace (and remember to check allow anonymous access)). One thing that I found very helpful is that the wizard will take all of the selected ports and merge them into a single WCF service. The last two screens are specific to the configuration of the Service Bus.
The first is the Endpoint Configuration.
There are a number of options that will effect the output of the wizard. The first is the Relay Binding option and you have three choices – BasicHTTPRelayBinding, NetTcpRelayBinding, and the WS2007HttpRelayBinding. The Service Namespace is the namespace that you created in the Azure portal. I am sure that this goes without saying but what you enter here must match with the name you created in the Portal.
The Enable Discover checkbox lets the services you are exposing be publicly discoverable through the ATOM feed page created by Azure for your Azure Service Bus account.
Lastly, the Enable metadata exchange on cloud tells the wizard to create the metadata endpoint in the cloud so that external clients can generate a proxy for your service.
The next screen takes the authentication information that you can find on the portal site.
You will need to enter the Issuer Name and Key. When you created the namespace in the Azure ServiceBus the issuer name defaults to owner. Enter both the Name and Key into the text boxes. The first checkbox controls whether the consumer needs to authenticate using to the relay service to consume the endpoint. The second checkbox controls the same but for the metadata endpoint. Since you are charged per access to your endpoints you may want to set these to prevent unauthorized access.
Click Next and Finish to complete the wizard. Once it is finished you will have a new Receive Port/Location and a site in IIS. However, there are still a number of important steps that need to be done in order for your service to work.
If you created a service based on an Orchestration then you need to bind the port to the orchestration in the BizTalk Administrator. You will also need to Enable the Receive Location and Enlist the Orchestration.
Next we move to IIS. We need to have an Application Pool that is configured to use the .NET Framework 4.0 with the Pipeline set to Integrated. Set the site to use the Application Pool by right clicking on the site that was created. In the popup menu, select Manage Application and then click on Advanced Settings. When the Advanced settings dialog box appears change the Application Pool to use the one you just created.
Lastly, we need to start our service. If you are running IIS 7.5 (Windows 7 or Windows Server 2008 R2) then you can configure Auto-Start. If you are running a different OS version then you will need to start the services using the on-premise endpoint with a local client. Once the service is started it will make contact with Windows Azure and register the service. One thing to note is that this is the first time in the entire process that your service has communicated with Azure.
If you have Windows Server AppFabric installed then configuring Auto-Start if very simple. To do this, right click on your site and select Manage WCF and WF Services in the popup menu, then click the configure item in the fly out menu. When the dialog box appears, select Auto-Start from the left hand side and then click the Enabled radio button.
You are now ready to test your endpoint. Point your browser to .servicebus.windows.net">.servicebus.windows.net">http://<servicebusnamespace>.servicebus.windows.net. You should see the ATOM feed page and your service should be listed. You can click on the service and you should see a new page with your service and MEX endpoint. You can now consume this endpoint the same is if it were on-premise.
Blog Post by: Stephen Kaufman
by community-syndication | Mar 20, 2012 | BizTalk Community Blogs via Syndication
A small oversight (at least in my mind) in the ESB Portal quicklyproves to become a major irritant after using it for awhile. The default sort order on the faults page is by severity, which if you’re like me, is almost never the logical choice when viewing the page. I would much rather be seeing […]
Blog Post by: Johann
by community-syndication | Mar 19, 2012 | BizTalk Community Blogs via Syndication
After working several years with the Castle Monorail MVC framework, I decided to try ASP.NET MVC to see if it had caught up to Monorail. The transition seemed to go rather smoothly, but one area where I was surprised to find how clumsily it was handled, was the management of JavaScript files. Basically, if some […]
Blog Post by: James Curran
by community-syndication | Mar 19, 2012 | BizTalk Community Blogs via Syndication
The stories continue with the BizTalk Community Series that bring BizTalk community members to the foreground. The eight story will be on Jean-Paul Smit. He created one of the productivity enhancing tools for BizTalk solutions; the BizTalk Software Factory. He is also like me an active member of the Dutch BizTalk User Group. I had a little chat with him a while ago and this is his story.
Jean-Paul Smit lives with his girlfriend and 2 sons of 8 and 10 years old in Hoofddorp, The Netherlands. Since 1997 he has worked with Microsoft products and from 2004 with BizTalk Server. In 2008 he started his own consultancy company to help customers with their integration issues. At the moment he works as a solution architect on the application integration team of a government agency in the Netherlands. Jean-Paul is a BizTalk MCTS and SOA Certified Professional.
Jean-Paul has a broad expertise, yet his focus is on architecture and development in the application integration and cloud area. He has worked in both the developer and architect role on small and large projects. To support the community he started the BizTalk Software Factory project on Codeplex a few years ago. With that tool you can start developing guided and consistent BizTalk solutions, so Jean-Paul is quite familiar with Visual Studio extensions.
Jean-Paul is very curious about the direction that BizTalk is going in the near future. There is a lot of activity in the Azure area with the Service Bus EAI/EDI initiative. BizTalk is a very traditional platform and he wonders when and if customers will move towards Azure for their integration activities. On the other hand he knows BizTalk is a traditional platform, so it will be around on-premise for several years.
A part of Jean-Paul’s spare time is reserved for studying, researching new technology, writing blog posts and articles. At the moment he is working on an article about the Azure Service Bus EAI/EDI (which is published now) and on achieving the SOA Schools SOA Architect certification (which he has done by now, congrats). Besides that he spends as much time as possible with his kids, because they grow up so fast!
Jean-Paul likes mountain biking a lot and depending on the time available he spends between 2 and 8 hours a week on a bike. In 2011 he decided to spend even more time on a mountain bike and achieved 2 major goals by finishing the long distance of the Salzgammergut Trophy in Austria and the Grand Raid in Switzerland. As he states I quote: “Biking in the mountains is awesome!”
His message for the readers of this and other BizTalk related blogs is to keep investing time in BizTalk, also by following this and other blog sites, because he think BizTalk will be around for quite some time.
I would like to thank Jean-Paul for his story and contributions to the community.
by community-syndication | Mar 19, 2012 | BizTalk Community Blogs via Syndication
or BugLoSE for short.
I have started a BizTalk user group within Logica aimed at educating the Swedish-speaking part of the company I work for, on how to use my favorite product.
The first meeting will be held online this Thursday (the 22nd) at 12 CET. It will be about BizTalk and clustering; a semi-advanced topic that seems to be quite high in demand.
Following a regular bi-weekly basis, we will continue to host these event online and cover different topics.
If you are a Logica employee, contact me if you would like to attend or have any questions.
Blog Post by: Mikael Sand
by community-syndication | Mar 18, 2012 | BizTalk Community Blogs via Syndication
From Monday through Wednesday of this week, I’ll be at Microsoft’s Convergence conference in Houston, Texas. This is Microsoft’s annual conference for the Dynamics product line, and this year I’ll be attending as a speaker. I’m co-delivering a session entitledManaging Complex Implementations of Microsoft Dynamics CRM. I now have a bit of experience with this […]
Blog Post by: Richard Seroter
by community-syndication | Mar 15, 2012 | BizTalk Community Blogs via Syndication
DON’T DO IT!!! (well, not unless you’re just trying to see this for yourself). Changing the “log on as” credentials for a BizTalk Host Instance service in the services MMC doesn’t change the account that is registered against the Host Instance in the BizTalk databases. If you take a look in the BizTalk Administration Console […]
Blog Post by: Johann
