Integrating to the max...BizTalk Style

It's been a long time since my last post. Hereby a partial explanation for that, with the note that this blog will remain active for the purpose of being a resource for historical references. My IT career started with programming, and adventures within holland, as well as overseas. When I realised programming is something you can specify, I figured that providing added value is crucial for a long term career and decided to focus on process centric roles. I started with webservice integration and eventually from that to process integration using BizTalk. The great feeling when discussing high level processes and implementing solutions within days, even highly scalable and interfacing with LOB systems is great. After several years of implementing solutions like these, I started questioning if all of this work was justified by the business case, if the solution was actually contributing, if the choices had been valid. In other words, I needed to understand the choices made. When

In My post ‘ Service Bus Management ’ I pointed out a way of implementing a DTAP strategy for managing the Service Bus environment. There’s now a great post available from Microsoft which goes into more detail about other aspects of managing the Azure subscriptions and other artefacts which is quite useful when setting up your Azure environments. Follow this link to the ‘Azure Implementation Guidelines’ HTH, Sander

Tags van Technorati: NuGet In my previous post I described a way to use NuGet for packaging libraries, often used in projects. This post is an addendum to my post ‘enter 2014 with NuGet’ look at the additional features possible. In this post i’m looking into Visual Studio features (project templates) and the NuGet package feature PowerShell . I’ve been working on an API (see my next posts, Service Bus Series - ‘the case for service bus’), and during the development I wanted to make sure that explaining the API to another co-worker was a nicer experience than just going through the code. To ensure that the developers could easily connect and understand the usage of the API, I decided to create sample projects using templates. Templates are a great way to provide the user with a sample project from within Visual Studio. I wanted more… and with the features available in NuGet packages, i’ve found a way that worked for my scenario. I’ve been using the principles; Each project in Visu

The new Azure Portal (in preview) is really great. Bundles a lot of the functionality that is sometimes hard to retrieve Azure Health (e.g. BizTalk Services / Service Bus) Billing information View your resources (at this moment only Resource Groups / WebSites / Team Projects / SQL Databases / MySQL Databases) Notifications (the alert functionality) The concept of ‘Journeys’ (preselection filters you’ve implicitly placed so that you can quickly look at the dashboard the way you want) Some screenshots to show how much more insight this provides… Azure Health   Billing information View your resources (at this moment only Resource Groups / WebSites / Team Projects / SQL Databases / MySQL Databases) Notifications Journeys (preselection filters you’ve implicitly placed so that you can quickly look at the dashboard the way you want)   The portal brings a lot of features together that had to be done using different areas, like the billing portal, which only showed a few bi

  [UPDATE] Sample solution available on OneDrive ( https://onedrive.live.com/?cid=5eaaef40eefdaddb&id=5EAAEF40EEFDADDB%21109 ) A solution consists of projects, projects uses components, components are of a specific version, changing the components thus requires a versioning strategy….which one are you using? All solutions which are architected into several tiers, have a form of layering with (which I hope) an abstraction of re-usable components. A project which is used to implement automated order approvals (AOA), with a requirement to implement logging, and retrieve something out of the database will likely have the minimum of 3 projects Solution AOA Project - AOA.Core Project - AOA.DataProject Project - Common.Logging Let’s assume, that the Logging library is also used by another solution: BOB Solution BOB Project – BOB.Core Project – BOB DataProject Project - Common.Logging When the requirements of logging change, and the project BOB needs a specific change due t

Is this your project approach? Azure Project X == Azure Subscription X Azure Project X Budget == Azure Billing Alert on Azure subscription X Azure Project X Monitoring == setup (SCOM) Azure monitoring Azure Project DEV == prepared to support the application after Go-Live? Azure Subscriptions http://blog.kloud.com.au/2013/07/30/good-practices-for-manag… Azure Billing http://msdn.microsoft.com/en-us/library/windowsazure/dn47977… Azure SCOM http://blogs.technet.com/b/dcaro/archive/2012/05/03/how-to-monitor-your-windows-azure-application-with-system-center-2012-part-2.aspx Regards, Sander