Integrating to the max...BizTalk Style

  Dear Customer, Upcoming maintenance will affect single instance deployments of Windows Azure Virtual Machine….”impact single instance deployments of Virtual Machines that are not using availability sets…” When do i have problems? in the weekend ? Nope…during the week! What is my problem, roles, temporary storage, reboots? Temporary storage? http://social.msdn.microsoft.com/Forums/windowsazure/en-US/d0665a80-89fe-4ea9-b136-7ba1fb5d37fe/maintenance-singleinstance-reboot-temporary-disk-d Unclear! Roles “Please note that Cloud Services using Web or Worker roles aren’t impacted by this maintenance operation. “ No! Reboots “Single instance virtual machine deployments that are not in availability sets will reboot once during this maintenance operation. “   So….i need an availability set! Aiai…do i have one? Go to your virtual machine, ‘Configure’ and determine if any availability sets are mentioned   If this is not the case, we need to create an availability set,

  This is the last post in the ESB Series which i’ve been doing; Hopefully this has showed some ways of using the ESB Toolkit, and ways of extending it so that it is more suited for various scenarios. This post will close the gaps i left open in earlier posts. In the end, i have hopefully demonstrated some common scenarios which are possible with the ESB Toolkit. My final thought on this subject is that the ESB toolkit is targeted to work in a more abstract/generic way, which is a good thing. After using the ESB Toolkit I think it is a nice addition to BizTalk, but I only recommend to use it when the problem demands for this type of a solution. There is a learning curve involved, it works differently as classic BizTalk, and means that you have to define your solution differently, sometimes it even makes the components more complex. In the end, it will bring flexibility, maintainability and allows re-use, however this requires an investment. The ESB Toolkit is not a golden hammer,

  The WCF-WebHTTP is designed to support REST , with support for the verbs GET, POST, PUT, and DELETE. We can use the POST verb to replace the HTTP adapter functionality, and use WCF custom behaviors to tailor the adapter to our needs. This post explains how I migrated the HTTP adapter and why I decided to look at this approach. This should give a summary of how to do this. Problem with the HTTP Adapter 1) Error handling The BizTalk HTTP adapter hides away the logic of HTTP status codes, thus an error is handled in the adapter. Returning a custom error in a request response call, which calls a solicit-response HTTP port is therefore quite challenging, and at this moment I have not found a way to do this, except abandoning the Messaging only approach. 2) Flexibility The HTTP adapter is somewhat limited in functionality, yes you can use a custom pipeline, client/server certificate authentication and stuff, but adding custom behavior is limited; HTTP vs WCF-WebHTTP Adapter

  This video is a must see ‘ Service Bus Deep Dive’ together with the presentation . Clemens explain all the Service Bus capabilities, which can be used in various scenarios, and most importantly, are being used in various scenarios which he explains as well. As most of the explanation in his video is also covered in the presentation, I’ve tried to make notes (again: PERSONAL notes), of what I think is something to highlight. These notes are grouped per main category in the presentation Service Bus Service bus will remain available in 2 flavors, the Server and Cloud version. The focus will be on delivering functionality in the Cloud version first, after which bugfixing, takes places and eventually a code merge to the Server version. - Cloud functionality (released frequently) - On Premise (released once 1 year – end of the year) Brokered messaging - Flow rate is roughly determined (throughput \ # subscriptions)     - e.g. 2000 throughput     - subscriptions == number of copies

  An Itinerary determines the business flow, when the business flow is interrupted we would like to be able to restart a process. When can do this with the ESB Portal, but this portal is not always the way to go (I will post more on that in the do’s and don’ts).   If we look at the options we have to resubmit a message in the ESB Toolkit context, we can;     I am now talking about the last option – Restart the Itinerary at step X;     Note: The ESB Portal allows you to resubmit a message, however, always starting from step 1.     The Itinerary is a fancy DSL diagram, and can be exported to Xml as which it is used inside the ESB Toolkit;     You can export to Xml and directly into the Database (depending on what you prefer for your release management);     So based on the component described in the orchestration on-ramp I thought that it should be possible to not only resubmit a message from any process, but also from any step! This can be useful to ‘manually fi

  I had a windows Live ID linked to my MSDN subscription, when changing jobs my former employer motion10 was so kind to keep the subscription active for a short period, allowing me to migrate my subscription to my new employer Caesar . Hereby the steps for this process to succeed The first requirement is that the bill has been paid Determine the current and new subscription ids Contact Microsoft support (from within the portal) Choose the subscription for which the ticket is created Choose the type of support call (subscription transfer-migration) The new subscription must be bound to the same Live ID for the migration to work The destination subscription may not contain any artefacts, so be careful with an Active Directory as this is created and active for all your subscriptions linked to your LiveID In my case the Active Directory was causing an issue, fortenately, the backend team is prepared for this type of migration “I will now go ahead and wo