In this article I describe how I used BizTalk 2013 beta (just upgraded to RTM on my Dev machine), its WCF-WebHttp adapter, an ASP.Net web application, a couple of API’s and Windows Azure to keep BizTalk Events up to date.
Since I started maintaining BizTalk Events in May 2012, I monitor a number of websites, to find out if any new BizTalk related events are organized.
As this is quite time consuming and not a very efficient way to be notified of any upcoming events, I started working on developing methods to make my life easier.
EventBrite
A couple of BizTalk/Connected Systems User Groups use EventBrite. At this website organizers of events can register their events for free (as long as the event is free) and keep track on the (number of) attendants. As EventBrite exposes ReST services, I considered this a great way to start automating my work on BizTalk Events!
Designing the solution
Knowing I could use the API of EventBrite and knowing an API for Google calendar is available, was a good start.
But beside being able to use those API’s, I had some more requirements:
1. It must be possible to check for new/updated events automatically, without me having to kick off anything
2. Instead of simply ‘importing’ the events from EventBrite directly into the BizTalk Events calendar, I want to approve each event, before I have it show up in the calendar.
3. I want to be notified per mail in case new/updated events are ready for approval.
4. It must be possible to generate tweets for notifying the BizTalk Events followers of the new/updated events
5. The solution must be easily extendable, ensuring other resources to be incorperated afterwards.
I ended up with the following design:
In short an explanation:
I’m using the Scheduled Task adapter, to kick off the process of quering EventBrite. The adapter triggers an orchestration once per day, but it can also be triggered manually by dropping a file on a Receive Location.
The orchestration queries the EventBrite ReST service and also takes care of storing the events found in a SQL Server database. Based on that database, the orchestration keeps track on how many new and/or updated events were discovered. If any new and/or updated events were found, a notification email is being sent to my Mail account. So far the involvement of BizTalk.
When I receive that notification, I visit a web application which enables me to approve (or ignore) the events. By approving an event a new calendar entry is made in the BizTalk Events calendar. It the moment it’s not yet possible to automatically tweet the announcement of new events, this will be added later.
Hosting in Windows Azure
Both the BizTalk solution and the web application are hosted in Windows Azure. The main motivation for this decision are the following:
– all resources I need are on the internet, nothing’s on premise
– I don’t want to host a server at home
– I don’t want to start my notebook every time I want to update BizTalk Events.
On Azure I created a ‘extra small’ Virtual Machine (shared core, 768MB) to keep things cheap. This VM is based on Windows 2012, SQL Server 2013 and BizTalk 2013 beta, so basically this is just a default image from the Windows Azure Gallery. The SQL Server database, which contains the stored events and some other tables, is also created in that VM. Next I created an Azure website, where the web application for approvals is hosted.
The WCF-WebHttp adapter
To consume the EventBrite ReST services I used the new WCF-WebHttp adapter. Although, in BizTalk 2013 beta, the adapter has some shortcomings, my requirements were not that specific, so I it could easily work around the shortcomings. Read about the the WCF-WebHttp adapter and its shortcomings in the following articles:
– Consuming JSON endpoint with BizTalk 2010 R2 REST WCF-WebHttp adapter
– Exploring REST Capabilities of BizTalk Server 2013 (Part 1: Exposing REST Endpoints)
– Exploring REST Capabilities of BizTalk Server 2013 (Part 2: Consuming REST Endpoints)
– Yes Richard, You Can Use Ampersands in the BizTalk REST Adapter (And Some ASP.NET Web API Tips)
Connecting the Azure website to the database
The Azure website needs to be able to connect to the database for CRUD operations. Therefore the following steps must be taken:
– add an EndPoint to the VM
– create a SQL Authentication user
– grant rights to the SQL user
– create the connectionstring
Add an EndPoint to the VM
The database in which the EventBrite events are stored, resides on the VM that contains the BizTalk installation. The Azure website is used for approval of the events and therefore needs to be able to access that database, so you need to setup an EndPoint to that VM.
With such an EndPoint you create a mapping between a Public IP Port to a Private IP Port. Although not advisable, you can map Public IP Port 1433 (SQL Server’s standard port) to Private Port 1433. But by doing so, you make it easy for hackers to access your database (although they don’t have security credentials), so it’s better to take a random number between 1024 and 65535 and configure that as the Public IP Port.
Read this article on how to setup such an EndPoint.
Create a SQL Authentication user
As Windows Authentication is not supported in Windows Azure, the website needs to use SQL Authentication, to access the database. Therefore you first need to create a user in SQL Server.
USE Master
CREATE LOGIN [sa.sqlserver] WITH PASSWORD N'<choose a safe password>' DEFAULT_DATABASE=[<Name of default database>]
GO
Grant rights to the SQL user
After having created the user, you need to grant it the needed permissions.
USE [<name of default database>]
CREATE USER 'sa.sqlserver'
GO
ALTER USER [sa.sqlserver] WITH DEFAULT_SCHEMA=[dbo]
GO
Create the connectionstring
We now have all the needed information to create the connectionstring, which looks like this:
Data Source=<Name of the VM>.cloudapp.net,<Public IP Port from EndPoint>; user=<SQL User>; password=<Password from SQL User>
The future
Now that integration with EventBrite is in place, I’ll continue to integrate with other resources. You can think of resources like RSS feeds and standardized emails.
Pingback: Scott Banwart's Blog › Distributed Weekly 200