July 1, 2010 at 11:24 AM

On 23 april I took the WCF 4.0 beta exam 71-513.

86 questions plus questions review...

In my opinion, the questions covered every feature (including the new ones).

To me, the REST questions were the most difficult, maybe because this is the feature I use least on projects. If you want to pass, don't forget to study the new 4.0 features!

Today I received a mail from Microsoft that I passed the exam :)

 

Peter Borremans

Posted in:

Tags:


June 21, 2010 at 2:26 PM

If you're interested in all the content that was prensented at TechEd US a couple of weeks ago the place to go to is http://www.msteched.com/2010

Certainly one to watch is Integrating LoB Systems (SAP, Mainframe) with the Cloud Using Microsoft BizTalk Server and the Windows Azure AppFabric http://www.msteched.com/2010/NorthAmerica/ASI305

And as we had last week Jon Flanders on an AppFabric training here with CODit in Brussels we can verify if AppFabric is what he promised us a few years ago :-) Framework and Microsoft BizTalk Best Practices with an Eye Toward Oslo http://www.msteched.com/2008/NorthAmerica/techtalk_41

Posted in: AppFabric | Azure | BizTalk

Tags:


By sam
June 17, 2010 at 9:37 AM

Since the latest release of the Windows Azure Development Kit (June), Azure provides support for .NET 4 applications, which is a real important step from the point of adoption, I believe.

 

The first thing we wanted to try was to host a XAMLX Workflow Service in a web role on Azure.

Example workflow service

I created a standard Workflow Service that accepted two parameters, on  one operation (Multiply) and returns the result of the multiplication to the client.  This service was called Calc.xamlx.

 

These are the steps I followed to make my service available.  I added the exceptions, because that’s typically what users will search for J

 

Enable visualization of errors

 

Standard behavior of web roles, is to hide the exception for the users, browsing to a web page.  Therefore, it is advised to add the following in the system.web section of the web.config:

 

<customErrors mode="Off"/>

 

Configure handler for Workflow Services

 

The typical error one would get, when just adding the Workflow Service to your web role and trying to browse it, is the following:

 

The requested url '/calc.xamlx' hosts a XAML document with root element type 'System.ServiceModel.Activities.WorkflowService'; but no http handler is configured for this root element type. Please check the configuration file and make sure that the 'system.xaml.hosting/httpHandlers' section exists and a http handler is configured for root element type 'System.ServiceModel.Activities.WorkflowService'.

 

We need to specify the correct HTTP handler that needs to be used for XAMLX files.  Therefore, we link the workflow services and activities to the correct Workflow Service ServiceModel handler.

 

To solve this, the following needs to be added to the web.config.

 

<configuration>
       <configSections>
             <sectionGroup name="system.xaml.hosting" type="System.Xaml.Hosting.Configuration.XamlHostingSectionGroup, System.Xaml.Hosting, Version=4.0.0.0, Culture=neutral, PublicKeyToken=31bf3856ad364e35">
                   <section name="httpHandlers" type="System.Xaml.Hosting.Configuration.XamlHostingSection, System.Xaml.Hosting, Version=4.0.0.0, Culture=neutral, PublicKeyToken=31bf3856ad364e35"/>
             </sectionGroup>
       </configSections>
       <!-- Removed other sections for clarity -–>
       <system.xaml.hosting>
             <httpHandlers>
                    <add xamlRootElementType="System.ServiceModel.Activities.WorkflowService, System.ServiceModel.Activities, Version=4.0.0.0, Culture=neutral, PublicKeyToken=31bf3856ad364e35" httpHandlerType="System.ServiceModel.Activities.Activation.ServiceModelActivitiesActivationHandlerAsync, System.ServiceModel.Activation, Version=4.0.0.0, Culture=neutral, PublicKeyToken=31bf3856ad364e35"/>
                    <add xamlRootElementType="System.Activities.Activity, System.Activities, Version=4.0.0.0, Culture=neutral, PublicKeyToken=31bf3856ad364e35" httpHandlerType="System.ServiceModel.Activities.Activation.ServiceModelActivitiesActivationHandlerAsync, System.ServiceModel.Activation, Version=4.0.0.0, Culture=neutral, PublicKeyToken=31bf3856ad364e35"/>
             </httpHandlers>
       </system.xaml.hosting>
</configuration>

 


Enabling metadata exposure of the workflow service

 

To enable consumers of our workflow service to generate their proxy classes, we want to expose the WSDL metadata of the service, by providing the following configuration section in the web.config.

 

Notice the simplicity of configuration, compared to WCF3.5.  Making use of the default behaviors, allows us to only specify what we want to override.

 

<system.serviceModel>
       <serviceHostingEnvironment multipleSiteBindingsEnabled="true" >
             <serviceActivations>
                    <add relativeAddress="~/Calc.xamlx" service="Calc.xamlx"  factory="System.ServiceModel.Activities.Activation.WorkflowServiceHostFactory"/>
  
          </serviceActivations>
       </serviceHostingEnvironment>
       <behaviors>
             <serviceBehaviors>
                    <behavior>
                           <serviceMetadata httpGetEnabled="true"/>
                    </behavior>
             </serviceBehaviors>
       </behaviors>
</system.serviceModel>

 

Testing and publishing

After successfully testing locally in the Azure Development Fabric, I uploaded and deployed the package, using the new Tools in Visual Studio to my Azure test account.

Sam Vanhoutte, CODit

Posted in: AppFabric | Azure | WCF | Workflow

Tags:


By sam
June 4, 2010 at 6:04 AM

Yesterday’s post showed the usage of the new BizTalk mapper activity in Workflow Services and how it made these workflows more declarative and drastically reduced the amount of assignment code that was typically required without this new feature.

Another interesting BizTalk feature that is made available in AppFabric workflows is the LOB (Line of Business) connectivity.  This functionality gets installed with the new BizTalk WCF LOB Adapter pack.

This post will show how this feature is used in the Workflow designer.  I will be using the SQL LOB adapter, because that’s the easiest to demonstrate.  (No SAP or Oracle test system available at this time).  I continue on the workflow that was created in the previous post.

Metadata generation

1.       Right-clicking the workflow project, will show the Add Adapter Service Reference… menu item. 
 

 

2.       This shows the familiar Add Adapter Service Reference dialog box.  (Don’t you all agree this tool still looks too much of ‘Form1/Button1’ app? J).  After selecting the sqlBinding and providing the ServerName and DataBaseName, the connection was made.

3.       This showed all the available metadata for this connection.  It is possible to select stored procedures or tables that will be used in the process.

 

4.       Since the LoanRequest needs to be inserted in the database table, the Client contract type was specified and the correct table (LoanRequests) and operation (Insert) were selected.

 

Using the LOB activity.

 

1.       After clicking OK and performing a rebuild on the project, a new custom activity was added to the Workflow Designer toolbox.  Each operation (Insert, Update …) that was selected results in a specific activity that is part of a category with the database object name.

2.       Dragging this activity on the canvas, shows that the following parameters can be specified on the shape.

 

3.       I only declared the variable ‘saveLoanResult’ that represents the records that should be added to the database.   This variable was linked with the Rows parameter of the InsertActivity shape and is an Array of LoanRequest objects.

4.       The InsertResult parameter would return the result of the database activity, but this parameter is optional, so I did not link it with a variable here.

 

5.       The BizTalk mapper activity was added right before the InsertActivity shape.  Here, I defined a mapping between the loanRequest and the databaseInsert.

6.       Compiling the project and executing the workflow, resulted in a new record in my database table.
 

 

 

Conclusion

The power of connectivity and adapter is now made available to the AppFabric platform in a standardized and user-friendly way.  It is now also easy to connect to various LOB systems, databases and host systems (using the BizTalk Adapters for Host Systems). 

What is not clear at this point is how the licensing will work for these AppFabric features.  But more information about that can probably be expected by the time of the public release.

Sam Vanhoutte

 

Posted in: AppFabric | WCF | Workflow

Tags: , ,


By sam
June 2, 2010 at 4:00 PM

Introduction

As described in the following wiki white paper on the social technet site (http://social.technet.microsoft.com/wiki/contents/articles/biztalk-appfabric-better-together.aspx) there is a nice new feature that gets installed through the released beta of BizTalk 2010.  Two capabilities of BizTalk Server are made available to WF 4.0!  This is about the BizTalk mapper and the Line of Business adapters (like SQL, Oracle, SAP…).

These features are also described in the blog post of Richard Seroter: post of Richard Seroter, (http://seroter.wordpress.com/2010/05/24/using-the-new-biztalk-mapper-shape-in-a-windows-workflow-service/). 

This is a first article in a series of three that is about these features.  Three articles will be posted in the coming days:

1.       Using the BizTalk mapper in Workflow

2.       Using the LOB Adapter functionality in Workflows

3.       Performance impact of the mapper shape, compared to code mapping.

The BizTalk mapper used in workflow services.

It happens a lot that data structures that are exposed through web services are different from the contracts and object types that need to be consumed by that service. 

During one of the demos I gave lately, I showed how an AppFabric workflow service was used to compose and consume three different other web services.  Allthough the customer really liked the pattern and the performance, he felt it was a bit too technical and too much code was involved to instantiate the web service requests and objects for the different services.  They were right (I needed to use too much assign shapes and different variables).

Luckily, we have a good answer to this at this moment, through the BizTalk mapper workflow activity.  It makes these workflows more model-driven and less code-oriented.

Installing the activities

It is important to know that the activities are only available in the Workflow designer toolbox, when installing the BizTalk LOB Adapter pack!  They are not part of the BizTalk 2010 installable and it looks like the installer of the adapter pack is checking if BizTalk 2010 is available to see if he should make the activities available.

Sample workflow service

The scenario I’ll be working out in this post is the exposing of a service that will call another web service.  This service will implement some specific logic and will also hide and abstract the actual names and contracts of the 'backend-service’.  The functionality we provide through this service is a loanrequest, where a consumer can request a loan and gets response with a result. 

The exposed contracts  

[DataContract]
    public class LoanRequest
    {
        [DataMember]
        public string CustomerName { get; set; }
        [DataMember]
        public long Amount { get; set; }
        [DataMember]
        public int Duration { get; set; }
        [DataMember]
        public LoanPart[] Parts { get; set; }
    }
    [DataContract]
    public class LoanPart
    {
        [DataMember]
        public LoanPartType PartType { get; set; }
        [DataMember]
        public long Amount { get; set; }
    }
    [DataContract]
    public enum LoanPartType
    {
        [EnumMember]
        Standard = 0,
        [EnumMember]
        Budget = 1,
        [EnumMember]
        Green = 2
    }
    [DataContract]
    public class LoanResponse
    {
        [DataMember]
        public double Intrest { get; set; }
        [DataMember]
        public double Variance { get; set; }
        [DataMember]
        public bool Approved { get; set; }
        [DataMember]
        public string Description { get; set; }
    }

 

Designing and beginning the workflow service

1.       After adding a new workflow service, I changed the action and namespace on the ReceiveRequest activity. 

2.       I also defined two variables: loanRequest and loanResponse that apply to their corresponding DataContract message types.  These are linked to the ReceiveRequest and SendResponse activities.

Adding a service reference to the ‘backend service’.

1.       Right-clicking the project and selecting Add Service Reference, pops up the dialog where I am linking to the WSDL of my web service.
 

2.       After a rebuild of this project, a new custom activity is added to my toolbox that can be used to call the web service operation.  If my web service would have had multiple operations, multiple activities would have been added, one for each operation.  They totally hide the implementation of doing this web service call.

 

3.       Now, two new variables get defined that represent the request and response to the backend service.  (notice the uppercased host-like names J)
 

4.       Dragging the LOANSIM activity to the designer canvas allows us to link the variables to the Activity Parameters of this web service operation call.

 

Use the BizTalk mapper activity to map request and response variables

1.       The Mapper activity is available in the BizTalk category in the Workflow Toolbox.  I just dragged two instances of this activity to the canvas, just before and after the LOANSIM activity.

2.       Once the mapper is dragged to the canvas, the input and output data types need to be configured, using the type picker dropdown.  This will be used to define the BizTalk map inputs and outputs.

 

3.       After this, the correct variables need to be linked and configured to their corresponding parameter.

 

 

4.       Clicking the Edit button on the activity, allows us to automatically generate a new BizTalk map that will use these types or we can reuse an existing map.

5.       Creating a new map, results in a new Biztalk mapper being opened.  Various schemas are being generated and added to the project in a specific sub folder.  The nice new BizTalk mapper can be used to make the mapping between both objects.  If required, custom XSLT functionality can also be used for this.

 


6.       The above logic has been done for both the request and the response messages.

 

 

Resulting workflow

The resulting workflow looks like the following:

 

Conclusion

The AppFabric + BizTalk better together story is a compelling offering that brings the BizTalk features closer to the AppFabric and Workflow runtime.  Considering that WF will be more and more important in the future of BizTalk and AppFabric, I believe this is a good step forward and we might see more of these things happen in the future.

Does this make AppFabric a free BizTalk Server?  No, it can be used to implement various scenarios that were done in BizTalk previously, but it still does not provide the rich management, deployment capabilities.  We still cannot accept flat file messages or EDI.  There is no pub/sub or direct binding.  Yet?

 

Sam Vanhoutte,-


By Stijn
April 28, 2010 at 5:18 PM

We gladly inform you that the "Beta 2 Refresh for Windows Server AppFabric" has been released on april 26th 2010.

This build supports the recently released .NET Framework 4 and Visual Studio 2010 RTM versions.

For more information we refer to http://blogs.iis.net/appfabric/archive/2010/04/26/windows-server-appfabric-beta-2-refresh-for-visual-studio-2010-net-4-rtm.aspx

Are you interested to extend your knowledge of the AppFabric technology?? Then sign up to attend "CODit Deep Dive Training into AppFabric" (http://www.CODit.eu/DeepDiveIntoAppFabric) training which will be presented by Jon Flanders.

Posted in: AppFabric

Tags:


April 21, 2010 at 3:34 PM

In this post I will talk about setting up a trace for the WCF-Adapter. This post should be a good addition to some previous posts I made about the WCF-Adapter.

Communicating with SAP through WCF : Send and Receive Ports

Communicating with SAP through WCF : Generate SAP schemas

1.  Tracing within the Adapter

 

Add the following to the configuration section of your BizTalk configuration file, BTSNTvc.exe.config which is present under <system drive>:\Program Files\Microsoft BizTalk Server 2006:

 

<system.diagnostics>

    <sources>

      <source name="Microsoft.ServiceModel.Channels" switchValue="Warning">

        <listeners>

          <add name="eventlog" />

        </listeners>

      </source>

      <source name="Microsoft.Adapters.SAP" switchValue="Warning">

        <listeners>

          <add name="eventlog" />

        </listeners>

      </source>

    </sources>

    <sharedListeners>

      <add name="eventlog" type="System.Diagnostics.EventLogTraceListener" initializeData="APPLICATION_NAME"/>

      </sharedListeners>

    <trace autoflush="false" />

  </system.diagnostics>

This will enable Warning level tracing (Errors + Warnings).  Replace APPLICATION_NAME with the name of your application as you want it to appear in the event viewer. Now you can see the errors and warnings - even the ones that were thrown to SAP.

If not possible to write to event log or if too bulky, then alternatively, you can put the following instead of the listeners “event log” if you want to log to a file. You will then need the tracing viewer (see below):

 

<add name="xml" type="System.Diagnostics.XmlWriterTraceListener"

   traceOutputOptions="LogicalOperationStack"

          initializeData="C:\log\WCF\AdapterTrace.svclog" />

ATTENTION: Trace files can become huge. Remember to stop tracing once issues have been solved.

2.  Tracing the Adapter and the LOB Application

To diagnose issues that you suspect are related to the LOB application, you must enable tracing for communication between the adapter and the LOB application. Adapters also depend on LOB tracing (client/server side) to access this information. The SAP adapter enables adapter clients to turn on tracing within the SAP system by specifying the "RfcSdkTrace" parameter in the connection URI. You must specify this parameter to enable the RFC SDK to trace information flow within the SAP system. For more information about the connection URI, see The SAP System Connection URI.

This parameter is specified in the SAP binding URI of the BizTalk WCF adapter:

 

Additionally, you can also create an RFC_TRACE environment variable that sets the level of tracing for the RFC SDK. RFC_TRACE is an environment variable defined by SAP and is used by the RFC SDK. If this variable is not defined or is set to 0, the RFC SDK tracing level is bare minimum. If the variable is set to 1 or 2, the tracing level is more detailed.

 

RFC_TRACE = 2
RFC_TRACE_DIR =
C:\log\LOB

Note: Irrespective of whether the RFC_TRACE environment variable is set, the RFC SDK tracing is enabled only if setting the "RfcSdkTrace" parameter to true in the connection URI (see in STEP 2). The value of this environment variable solely governs the level of RFC SDK tracing. If RfcSdkTrace is set to true, the message traces between the adapter and the SAP system are copied to the “system32” folder on your computer. To save the RFC SDK traces to some other location, you can set the RFC_TRACE_DIR environment variable. For more information about these environment variables refer to the SAP documentation.

3.  Viewing the Traces

You can use the Windows Communication Foundation (WCF) Service Trace Viewer tool to view the traces. For more information about the tool, see "Using Service Trace Viewer for Viewing Correlated Traces and Troubles" at http://go.microsoft.com/fwlink/?LinkId=91243 .

Enjoy!

Glenn Colpaert 

Posted in: BizTalk | WCF

Tags: , , ,


April 20, 2010 at 4:38 PM

A few weeks ago I had to create a flow that receives messages from SAP with a specific IDoc release number. The SAP system was a 620 release and the IDoc was 46C release.
So to start with, I generated the schema for the 46C release and deployed that on my BizTalk box.

When we sent an IDoc to BizTalk, we got following error :

The segment or group definition E2EDP01006 was not found in the IDoc metadata. The UniqueId of the IDoc type is: IDOCTYP/3/ORDERS05//620. For Receive operations, the SAP adapter does not support unreleased segments.

So this message stated that SAP was sending a 620 IDoc. After a discussion with an SAP developer, we found out that the DOCREL field in the EDI_DC40 header had the value 620 while we where expecting to receive 46C.

The way that the new SAP adapter works in BizTalk is that when he receives an IDoc from SAP, he will check all the segments that are sent to see if it is a valid IDoc. Since the segment E2EDP01006 is not present in IDoc release 620, this is a normal error. This validation occurs in the adapter, so even before the message reaches BizTalk. So even if you have the correct schema deployed (like in my case) you will still get the error.

While searching for a solution we found 3 ways to solve this.

1.  Always use the latest IDoc release

This is the most obvious one off course. Just ask an SAP developer to send the latest release of the IDoc to BizTalk and you will be able to receive it. (The latest release will be the same as the system release)

This is also the option we choose at the time. It was the fastest solution we could both support.
But we still spent a little bit time to investigate the other options.

2.    Receive “untyped” flat file IDocs.

This means that you need to generate the flat file schemas for the IDoc instead of the typed xml schema. You have to make sure that you set the GenerateFlatfileCompatibleIdocSchema field to true in the “Consume adapter service” window.(If you want to receive multiple IDocs via the same receive port, make sure you install the KB977528 hotfix)

This has the limitation that you need to use the flat file assembler in your receive pipeline. If you want to receive alot of different types of IDocs with the same receive pipeline, you will have to put a flat file disassembler in there for every IDoc type.

 

3.    Change the SAP output module

SAP has 2 ways of exchaning IDocs with other systems.

  1. Application Link Enabling (ALE)

ALE was created to exhange IDocs between SAP R/3 systems and/or R/3 and external systems.

  1. Electronic Data Interchange (EDI)

This interface is used to communicate with non R/3 systems.

Since BizTalk can act as an R/3 system, the standard way we received IDocs was via ALE. But when you use ALE, the DOCREL field will always contain the system release number.So if you use ALE as the output module, you can only receive the latest IDoc release know inside the system.The EDI interface works in a different way, that makes sure that the DOCREL field is filled in correctly. Since we already chose to go for the first solution, we did not test this at runtime.
But The SAP developer told us that this should do the trick as well.

Tim D'haeyer, CODit

 

Posted in: BizTalk

Tags: , , ,


By sam
April 7, 2010 at 2:50 PM

CODit invited 'the legendary' Jon Flanders to Belgium for a deep-dive AppFabric and .Net 4.0 workflow training.  This training is open for customers and partners all over EMEA.  The training has limited seats available and registrations are on a 'first come / first served' schedule.

This training will be a level-300 training and will be organized on June 15-18, 2010.

This is the agenda of the 4 days training:

Day 1

  • Introduction to Windows Server AppFabric Monitoring and Hosting
  • Introduction to Windows Workflow Foundation 4.0
  • Building Declarative Services using WF 4.0 and WCF

Day 2

  • Hosting Services with Windows Server AppFabric
  • Configuring Windows Server AppFabric Services
  • Windows Server AppFabric Management

Day 3

  • Monitoring Services using Windows Server AppFabric
  • Making your services robust and manageable
  • Advanced Workflow Topics

Day 4

  • Introduction to Windows Server AppFabric Caching
  • What's new in WCF 4.0
  • Introduction to Windows Azure AppFabric

For more details and subscription, please visit the training page: http://www.codit.eu/deepdiveintoappfabric

Posted in: AppFabric

Tags: , ,


March 23, 2010 at 3:29 PM

I had some fun in converting my build/deploy scripts. These scripts are made to build and deploy a BizTalk project with one click on your local development machine to avoid to much clicking. The scripts are making use of MSBuild.

On my current project, the development BizTalk Servers are remote machines, the scripts were still working fine, except adding an assembly to the GAC on the remote machine caused some problems.

The first step to add an assembly is finding the right MSBuild task to do this. I'm using the MSBuild extension pack, this extension pack contains a GAC task (makes use of Gacutil.exe). The task is used as follows:

 <MSBuild.ExtensionPack.Framework.Gac TaskAction="AddAssembly" AssemblyPath="$(asseblyPath)" RemoteAssemblyPath="$(remoteAssemblyPath)" MachineName="$(Server)" Force="true" /> 

As taskaction, I choose 'AddAssembly', specify a local and remote assembly path and a machine name (the remote server). If your user account does not have the necessary privileges to add the assembly to the remote GAC, you can specify a remote user/password combination.

Although this looks ok, this is not enough...

The remote machine is a server, without the .NET 2.0 SDK installed. The gacutil.exe tool is shipped with the .NET 2.0 SDK. We could install the .NET 2.0 SDK but it is enough to deploy gacutil.exe on the remote server.

This still did not work...

One final thing should be done! The GAC MSBuild task does not know where to find gacutil.exe. To fix this, we must add the path to gacutil.exe to the PATH environment variable.

If these three steps are done, we can GAC our assembly on the remote machine....

 

Peter Borremans

Posted in:

Tags: , , ,