Thinking about WS* and REST

Thinking about WS* and REST

In a previouspost I highlighted a great webcast by Scott Hanselman on OData and discussed the metaphor he used to explain OO and SO (the Librarian Service). I’d like to continue discussing that webcast and this time turn my attention to REST and WS*. To paraphrase Scott’s explanation,” SOAP is great for (that kind of) […]

Learning BizTalk Server: How to start?

On BizTalk Server General forum I sometimes see people asking how to start learning BizTalk. Responses to these questions vary a little and links are provided to numerous resources, but what would be a good starting point? In my view the Microsoft BizTalk Server site and BizTalk Server Developer Center are good starting points. A successful  learning path for BizTalk Server depends on:

  • Knowledge of .NET and Visual Studio (BizTalk artefacts);
  • Knowledge of SQL Server since BizTalk depends on SQL Server (see BizTalk Architecture picture below);

For publish/subscribe, see patterns/practices article and understanding BizTalk Server 2009.

  • Invest in time and money, a good training from experienced professionals can speed up the process of learning BizTalk. Spend time to build up routine and experience.

Knowledge of .NET and Visual Studio

Development for BizTalk Server is done through Visual Studio. Visual Studio has templates for BizTalk artefacts like orchestration, pipelines, schemas and maps, so a BizTalk solution can be created (design time) and deployed to the BizTalk runtime. Besides artefacts .NET development can be done in creating pipeline components, custom functoids, custom adapters, and .NET helper classes to aid in orchestrations. As a BizTalk professional Visual Studio is your friend and required to build BizTalk solutions.

Knowledge of SQL Server

BizTalk Server depends on SQL Server and Microsoft BizTalk Server databases and their health is very important for a successful BizTalk Server messaging environment. How to achieve this is explained in How to maintain and troubleshoot BizTalk Server databases and if you review that article it will become obvious that you need SQL Server knowledge.

Invest in time and money

When you start learning BizTalk you will need to invest in time and get hold of some budget to get training, books (Amazon, see list here), software (MSDN) and hardware (you need at least a laptop/desktop with enough memory, disk and processor power). Learning can be done at a local training facility or you can go to Quicklearn and Pluralsight. If you do not have enough resources as in software/hardware you still can learn/experience BizTalk through BizTalk Server Virtual Labs.

I have explained the success factors for a successful learning path for BizTalk and if you have the necessary prerequisites as in software and a machine (laptop/desktop) you can start cracking. Best way to proceed is to build your own BizTalk environment with the installation guide in your hand (I assume you start with the latest version available, currently BizTalk Server 2009) .

A BizTalk development environment can best be installed and configured on a Virtual PC or Hyper-V (see this post BizTalk Virtual Machines with Windows 2008 R2 Hyper V). As soon as you have your environment available, download the BizTalk help file and follow the tutorials  described in there(which can be viewed online too or downloaded). Through self study you setup your own environment, do tutorials, try virtual labs and read books. If that is not enough you can get training:

QuickLearn offers BizTalk training classes and Pluralsight also offers BizTalk training classes ranging from introductory to advanced. If you’re just getting started, you might want to check out their self-paced BizTalk Developer Fundamentals class. Finally, visit QuickLearn’s Technical Library for resources and articles on BizTalk.

Besides that, there are several good resources available online:

ESB Toolkit

It is possible that after gaining experience- and building/strengthen your knowledge in BizTalk you want to take it a step further by learning the ESB Toolkit. If you have your BizTalk environment available you can download and then install and configure ESB Toolkit 2.0 (targeted for BizTalk 2009, while version 2.1 is target for new BizTalk 2010). For reading you can start with a whitepaper by Jon Flanders. In general you will find a lot of resources at BizTalk Server Development Center -> BizTalk ESB Toolkit 2.1.

I hope with this post it will be clear to people how to start with learning BizTalk Server. Although you my find it a long learning path, you will find that there are plenty of resources at your disposal.

Technorati: BizTalkBizTalk Server 2009

Great Azure Security Resources

If you have questions about security and Windows Azure, there’s a really good compilation of resources available here.

There’s a lot of great content there about all things security-related about Azure, and developing secure apps on, and leveraging, the Azure platform.

A particularly interesting read is Windows Azure Security Overview, which talks about security from the Azure-side (fabric controller, facilities, network, everything!). This is more than most people need to know, but if you ever wondered what goes on under the hood, you’ll find this of interest.

See the compilation page, read and learn more at http://msdn.microsoft.com/en-us/library/ff934690.aspx.

DictionaryAdapter is Love (Part 1)

Nestled deep within the Castle Project repository, there is a wonderful library maintained by Improving Enterprises’ own Craig Neuwirt which can forever change how you deal with the assortment of Key/Value pair structures in our programming life.  That library is called DictionaryAdapter, or more properly Castle.Components.DictionaryAdapter and the source can be found at : http://github.com/castleproject/Castle.Core

So how does this library work?  Let’s take a quick tour around, shall we?

So you’ve got a Dictionary

        static void Main(string[] args)
        {
            var dict = new Dictionary<string, object>()
                {
                    { "UserId", 1234567 },
                    { "UserFirstName", "Tim" },
                    { "UserLastName", "Rayburn" }
                };
        }

We deal with dictionaries like this all the time in .NET, the easiest example of which is ASP.NET Session but many others exist.  Now lets assume that we wanted to access this information in a structured way.  That is to say, instead of writing something like:

        public static string UglyWayToGetUserFirstName(Dictionary<string, object> dict)
        {
            string userFirstName = "UserFirstName";
            if (dict.ContainsKey(userFirstName)) return dict[userFirstName] as string;
            return null;
        }

I instead want to write code which access the information using a strongly typed interfaced like this:

    public interface IUserData
    {
        int UserId { get; set; }
        string UserFirstName { get; set; }
        string UserLastName { get; set; }
    }

Which would produce code like this:

        public static string CleanWayToGetUserFirstName(IUserData data)
        {
            return data.UserFirstName;
        }

How do I do that?  DictionaryAdapter to the rescue.  Add a reference to Castle.Core, and a using statement for Castle.Components.DictionaryAdapter and then the following code will work:

        static void Main(string[] args)
        {
            var dict = new Dictionary<string, object>()
                {
                    { "UserId", 1234567 },
                    { "UserFirstName", "Tim" },
                    { "UserLastName", "Rayburn" }
                };

            IUserData data = new DictionaryAdapterFactory().GetAdapter<IUserData>(dict);

            Console.WriteLine(CleanWayToGetUserFirstName(data));
            Console.ReadLine();
        }

Simple, eh?  But there is much more coming.  As you can see, there is a default convention that matches the property name of our interface to the key in the dictionary.  Lets assume that you’re the type of person who believes having the word User in front of each property on the interface is a bad idea, but keeping it on the keys which lack the context of being IUserData makes sense.  No problem, enter aliasing.  Modify your interface like so:

    public interface IUserData
    {
        [Key("UserId")]
        int Id { get; set; }

        [Key("UserFirstName")]
        string FirstName { get; set; }

        [Key("UserLastName")]
        string LastName { get; set; }
    }

And now your  interface main method (no longer using our rather useless CleanWayToGetUserFirstName example above) can be refactored like so:

        static void Main(string[] args)
        {
            var dict = new Dictionary<string, object>()
                {
                    { "UserId", 1234567 },
                    { "UserFirstName", "Tim" },
                    { "UserLastName", "Rayburn" }
                };

            IUserData data = new DictionaryAdapterFactory().GetAdapter<IUserData>(dict);

            Console.WriteLine(data.FirstName);
            Console.ReadLine();
        }

That’s a good introduction to the basics of DictionaryAdapter, but there is a lot more depth here that I hope to cover in future posts.

Covast 2006 SYNTAX schema issues

Some time ago, with a client using BizTalk 2006 and Covast Accelerator 2006, we suddenly had the following issue popping up in their event log:

There was a failure executing the send pipeline: “Covast.BizTalk.Pipeline.EDI.CovastEDISendPipeline, Covast.BizTalk.Pipeline.EDI.Default, Version=5.0.0.0, Culture=neutral, PublicKeyToken=68bef120a46b49ad” Source: “Covast EDI Assembler” Send Port: “sp_MySendPort” URI: “D:\BTS2006\DumpLocation\%MessageID%.edi” Reason: Message translation failed: (2217) Unknown error (-2217)

The source of the problem was Covast.
Somehow, it was no longer able to perform valid assembling and disassembling (both were failing).

After a lot of digging and research I finally came to the “Covast EDI Accelerator 2006 Reports” screens, hidden deep within the BizTalk Administration Console HAT 🙂

When you double click the interchange which was in error, you saw the following error:

The format of the document has not been configured

Finally, did let me to the source of the problem.

Someone at the client fiddled around with one particular ASC file trying to add some extra segments to the schema to accompany a change in one of their flows. No harm done, but unfortunately when re-generating the XSD, he also regenerated the SYNTAX schema and deployed.

The result was that there were now 2 SYNTAX schemas deployed within BizTalk and Covast doesn’t know how to handle that.
Reverting back to the old version of the flow fixed the error and after that we just removed the SYNTAX schema from the project, rebuilt and deployed and now it worked.

Reason for posting this is that at the time, neither search engine could come up with a decent answer, so hopefully someone benefits from this post.

Let us know in any case!

 

Pieter

 

Implementing a workflow service for inbound LOB operations

Consider the following scenario – I want to write a workflow that gets instantiated when certain changes happen in LOB (say a new row is added to a table) and then does some processing with the altered data. In the current release of Microsoft BizTalk Server, Add Adapter Service Reference (AASR) generates LOB activities only for outbound operations. For inbound operations (polling, notification, etc), AASR only generates the contract and configuration information along with a dummy service implementation. This blog explains how to create such a workflow service and host it in IIS.

I will use a Typed Polling scenario for WCF SQL adapter to illustrate the steps involved for a one-way operation.

Generate service – Create a new “WCF Workflow Service Application”. Run AASR and select the appropriate inbound operation. You can delete the dummy service implementation since that’s no longer required. Let’s assume the generated contract looks like

[System.CodeDom.Compiler.GeneratedCodeAttribute(“System.ServiceModel”, “4.0.0.0”)]
[System.ServiceModel.ServiceContractAttribute(Namespace=”
http://schemas.microsoft.com/Sql/2008/05/“, ConfigurationName=”TypedPolling_Foo”)]
public interface TypedPolling_Foo {    
        [System.ServiceModel.OperationContractAttribute(IsOneWay=true, Action=”TypedPolling“)]
        void TypedPolling(TypedPolling request);
}

Configure the activities – Since this operation is one-way, we will delete the “SendResponse” activity and also remove the co-relation handle from the “Receive” activity (in the properties for the “Receive” activity, select CorrelationInitializers and delete the handle) and optionally from the “Variables” as well. Apply the following configuration to the activity (obtained from the above contract)

  • OperationName – TypedPolling
  • ServiceContractName – {http://schemas.microsoft.com/Sql/2008/05/}TypedPolling_Foo
  • Action – TypedPolling
  • Check CanCreateInstance

 

 

  • Content – Select “Message”
    • Message data – create a variable of type TypedPolling and specify that
    • Message type – TypedPolling

 

 

 

If the operation is two-way, i.e. needs to return a response, SAP RFC call for example, there are some differences. You shouldn’t remove the “SendResponse” activity and the correlation handle. The configuration of the “Receive” part stays the same as described above. For the “SendResponse” part, apply the following configuration.

  • Action – Set this to the ReplyAction in the OperationContractAttribute.
  • Content – Select “Message” and set the “Message type” to the return type and “Message data” to a variable of that type

 

 

Process the input – The workflow can now use the variable (Message data) to get the contents of the poll and do whatever processing it needs to do with that data

Update the config – Modify the “service” name in the configuration file to the name of the workflow class (do not include the namespace), which essentially implements the service

    <system.serviceModel>
      …
      <services>
        <service name=”Workflow1″>
          <endpoint address=”mssql://localhost//mytestdb?InboundId=Foo” …

Deploy the service – At this point the service is ready to be hosted.  You can use VS 2010 to deploy it to IIS. From the project properties –> Web, select the “Use Local IIS Web Server”, specify a URL, create a virtual directory and then build the project. However, since the service endpoint is using a custom binding which IIS does not understand, we will need to “Auto-Start” it. This is a new feature in IIS 7.5 and is explained here. While the blog explains it in the context of Service Bus Endpoints, it applies to this scenario as well.

 

Sandeep Prabhu,
BizTalk Server Team