read more...

I came across this interesting video called "meet the design team" for C# 4.0. After the successful launch of C# 3.0 the design team is already on its way to build the next generation of the language and set the agenda for what is required of it. From the discussion the salient points I can gather are:

Power of dynamic: You know the thing about languages like javascript and VB that you don't have to define everything before hand, like in statically typed languages like C# and its predecessors and you program and define as you go along. Well, the that is the power of dynamic languages. They don't enforce a whole lot of structure on you when writing your programs because they don't care about the program being perfectly typed and thoroughly structured, rather their focus is on the program flow so that you can achieve what you plan to do in the least amount of time. Simple.

Power of functional: If you have worked with any "declarative" language and chances are that you have, then you would know what power functional languages give you. Every developer these days has worked with SQL which is a declarative language and and C# programmers have been exposed to the new LINQ model which is also pretty declarative. The thing about declarative is that instead of writing the program as a series of steps, like a flowchart, where you convert your intent into a well defined structure, you just go ahead and express your intent and say be and it is. Like for example when writing and SQL statement you don't specify "how" it will execute and use indexes and generate temporary tables or loop through a table for every matching row, you just say it should do all that and it does.

Power of concurrency: A point that Anders makes towards the end of the session referring to the Moore's Law, which states that computing power will double every eighteen months, is that the increase of power has taken a shift from more megahertz to more processors because we have kind of reached a limit for how small and fast can we make a processor. So, we are just putting in more of them to meet the demand. Now to effectively adapt to this new trend the languages must have some constructs that allow the programmer to express his "intent" regarding concurrency.

Watch and enjoy.

C# 4.0: Meet the Design Team

While looking for a method to programmatically generate PDF I came across the possibility of using SQL Server Reporting Services for the job. It actually has a number of possible rendering options, among them are "XML, NULL, CSV, IMAGE, PDF, HTML4.0, HTML3.2, MHTML, EXCEL, and HTMLOWC".

The problem with generating PDF is that there are two components to the document, the format and the data. The format part is the real pain that on has to deal with, date can then simply put in placeholders. SSRS simplifies this by allowing you to generate the PDF report by first creating the report, using some data from the database, in its own designer. Once the report is designed you can use the web services exposed by reporting services to save it any of those formats.

The SSRS web service can be found at http://server/reportserver/reportservice.asmx

After adding this service reference you will find the following nifty function for rendering the report in any format you like.

public Byte[] Render(
   string Report,
   string Format,
   string HistoryID,
   string DeviceInfo,
   [Namespace].ParameterValue[] Parameters,
   [Namespace].DataSourceCredentials[] Credentials,
   string ShowHideToggle,
   out string Encoding,
   out string MimeType,
   out [Namespace].ParameterValue[] ParametersUsed,
   out [Namespace].Warning[] Warnings
   out string[] StreamIds);
   Member of [Namespace].ReportingService

According to the documentation the parameters are defined as following:

Parameters

Report

The full path name of the report.

Format

The format in which to render the report. This argument maps to a rendering extension. Supported extensions are XML, NULL, CSV, IMAGE, PDF, HTML4.0, HTML3.2, MHTML, EXCEL, and HTMLOWC.

HistoryID

Optional. The unique identifier of a report history snapshot to render for the specified report. The identifier is based on the date and time the report history was created.

DeviceInfo

An XML string that contains the device-specific content that is required by the rendering extension specified in the Format parameter. For more information about device information settings for specific output formats, see Device Information Settings.

Parameters

Optional. An array of ParameterValue[] objects that represent the report-specific parameters.

Credentials

Optional. An array of DataSourceCredentials[] objects that contains the data source credentials.

ShowHideToggle

Optional. The Show/Hide toggle ID.

Encoding

[out] The encoding used when report server renders the contents of the report.

MimeType

[out] The MIME type of the rendered report.

ParametersUsed

[out] An array of ParameterValue[] objects representing the query parameters, if any, that are stored along with the report. This parameter returns a value only if the report being rendered is a report history snapshot.

Warnings

[out] An array of Warning[] objects that describes any warnings that occurred during report processing.

StreamIds

[out] The stream identifiers. These IDs are passed to the RenderStream method. You can use them to render the external resources (images, etc.) that are associated with a given report.

Return Value

A Byte[] array of the report in the specified format. For more information about this data type, see "Byte Structure" in the .NET Framework documentation.

The following piece of code may be used to generate a PDF of the report you created.

private void RenderTest_Click(object sender, System.EventArgs e)
        {
            RSWebReference.ReportingService rs = new RSWebReference.ReportingService(); 
            rs.Credentials = System.Net.CredentialCache.DefaultCredentials;

            Byte[] result; 

            string encoding;
            string mimetype;
            ParameterValue[] parametersUsed;
            Warning[] warnings;
            string[] streamids;

            result = rs.Render("/SampleReports/Company Sales","PDF",null,null,null,null,null,out encoding,out mimetype,out parametersUsed,out warnings,out streamids); 
                        
            Response.ClearContent();
            Response.AppendHeader("content-length", result.Length.ToString());
            Response.ContentType = "application/pdf";
            Response.BinaryWrite(result);
            Response.Flush();
            Response.Close();
        }

If the reporting service is not satisfying your requirements or you simply don't have reporting service available then you can use on of the following libraries to generate PDF through your own code: C# open-source PDF Libraries

Render Method on MSDN

PDF Generation KB

In this installment we will look at the tracking capabilities built into WF. Tracking basically allows you to "log" all the actions your workflows are performing. This includes both the standard trace messages which signal different things such as activities completing, state changes, rule executions exceptions and custom messages placed by the user.

Setting up the WF tracking is quite simple, you just have to add a service to the runtime. Like persistence, there is a ready made service for tracking which can we easily incorporate and should suffice for most cases. Let's add that service now to begin exploring the tracking capabilities.

We have added the service to our program but we haven't yet setup the database for it. To do that pick up the two script files from C:\<WINDOWS DIR>\ Microsoft.NET\Framework\v3.0\Windows Workflow Foundation\SQL\<LANGUAGE DIR> and run them in the SQL Server database we created previously or in a new database if you like.

The WF runtime does its tracking using what is called a tracking profile. The tracking profile is simply a definition of what needs to be tracked. This tracking profile can be created using the object model or simply as an xml file which can be saved in the database. The default profile from the database looks like this:

<?xml version="1.0" encoding="utf-16" standalone="yes"?>
<TrackingProfile xmlns="http://schemas.microsoft.com/winfx/2006/workflow/trackingprofile" version="1.0.0">
    <TrackPoints>
        <ActivityTrackPoint>
            <MatchingLocations>
                <ActivityTrackingLocation>
                    <Activity>
                        <Type>System.Workflow.ComponentModel.Activity, System.Workflow.ComponentModel, Version=3.0.0.0, Culture=neutral, PublicKeyToken=31bf3856ad364e35</Type>
                        <MatchDerivedTypes>true</MatchDerivedTypes>
                    </Activity>
                    <ExecutionStatusEvents>
                        <ExecutionStatus>Initialized</ExecutionStatus>
                        <ExecutionStatus>Executing</ExecutionStatus>
                        <ExecutionStatus>Compensating</ExecutionStatus>
                        <ExecutionStatus>Canceling</ExecutionStatus>
                        <ExecutionStatus>Closed</ExecutionStatus>
                        <ExecutionStatus>Faulting</ExecutionStatus>
                    </ExecutionStatusEvents>
                </ActivityTrackingLocation>
            </MatchingLocations>
        </ActivityTrackPoint>
        <WorkflowTrackPoint>
            <MatchingLocation>
                <WorkflowTrackingLocation>
                    <TrackingWorkflowEvents>
                        <TrackingWorkflowEvent>Created</TrackingWorkflowEvent>                       
                        <TrackingWorkflowEvent>Completed</TrackingWorkflowEvent>
                        <TrackingWorkflowEvent>Idle</TrackingWorkflowEvent>
                        <TrackingWorkflowEvent>Suspended</TrackingWorkflowEvent>
                        <TrackingWorkflowEvent>Resumed</TrackingWorkflowEvent>
                        <TrackingWorkflowEvent>Persisted</TrackingWorkflowEvent>
                        <TrackingWorkflowEvent>Unloaded</TrackingWorkflowEvent>
                        <TrackingWorkflowEvent>Loaded</TrackingWorkflowEvent>
                        <TrackingWorkflowEvent>Exception</TrackingWorkflowEvent>
                        <TrackingWorkflowEvent>Terminated</TrackingWorkflowEvent>
                        <TrackingWorkflowEvent>Aborted</TrackingWorkflowEvent>
                        <TrackingWorkflowEvent>Changed</TrackingWorkflowEvent>
                        <TrackingWorkflowEvent>Started</TrackingWorkflowEvent>
                    </TrackingWorkflowEvents>
                </WorkflowTrackingLocation>
            </MatchingLocation>
        </WorkflowTrackPoint>
        <UserTrackPoint>
            <MatchingLocations>
                <UserTrackingLocation>
                    <Activity>
                        <Type>System.Workflow.ComponentModel.Activity, System.Workflow.ComponentModel, Version=3.0.0.0, Culture=neutral, PublicKeyToken=31bf3856ad364e35</Type>
                        <MatchDerivedTypes>true</MatchDerivedTypes>
                    </Activity>
                    <Argument>
                        <Type>System.Object, mscorlib, Version=2.0.0.0, Culture=neutral, PublicKeyToken=31bf3856ad364e35</Type>
                        <MatchDerivedTypes>true</MatchDerivedTypes>
                    </Argument>
                </UserTrackingLocation>
            </MatchingLocations>
        </UserTrackPoint>
    </TrackPoints>
</TrackingProfile>

As you can see the workflow tracking profile allows you to trace specific workflows using their type as the matching criteria, plus you can specify if all derived types should be tracked as well. In this case the type Activity has been chosen with derived types, meaning all activities would be tracked. Second, you can track activity execution states and third you can track workflow states. As, for user generated messages they can be anything and produced from anywhere.

Lets create a simple workflow that we want to track.

In every code activity we print a message on screen and each delay is of 2 seconds. Lets execute this twice and see what it generates in the database.

After the execution of the workflow, lets explore the generated data from top down that is by looking at the workflow first and then the activities within them. If you open the table Workflow you will see a row like this:

This table uniquely lists the workflows that we are tracking. The next level is at the instance of this workflow, for which you should open WorkflowInstance:

This table list the individual instances of the particular workflow tracked. There is a field called WorkflowTypeId which links it back to the previous database identifying the workflow type. At the next level we see what events get generated at each workflow instance level:

As you can see there are two sets of event lists, representing each instance of execution, and there are fields that link it back to the previous tables. As you can see the progression of data captured, you should be able to relate further information to it. For example, if we open the tables Activities the data should be obvious to us:

At the next level:

include another reference table in here:

and the table next lists down every state the activity went through:

I'll leave the database details at this level, so you can explore further.

In this installment we will be looking at consuming and exposing web services through Workflow Foundation. Needless to say that any modern framework should have the ability to easily interface with web services as more often then not it would either be hosted by a web service or using some.

Let's start with how can you use web service from WF. To consume a web service we need to first create one, use the template provided in visual studio to create a hello world web service. Change the function to accept a parameter called name and say hello to that name.

Now create a sequential workflow that looks like this:

In the first code activity we will get a name from the console and put it in a local property. The value of this property will be bound to the function we are calling in the InvokeWebService activity. The return value is placed in another local property which the second code activity will print.

Calling web services is as simple as that. When you provide the url for the web service a proxy class is generated as usual and a web reference added.

Now let's come to exposing web service through WF. Yes, it is possible to expose your workflows directly as web services with some visual studio magic. WF designer provides you with three activities, one that allows you to receive the incoming request, the second lets you send a response back to the client and third one alternatively allows you to send back SOAP faults. Think of this web service that you create with WF as a single function in a usual web service implementation where you enter the function with a request and exit with a response or exception. Although it is possible to receive multiple requests and return multiple responses but it is much easier to understand it in such a unit like manner.

Start by dropping a WebServiceInput and WebServiceOutput activity in the workflow. When you get the properties of the input activity, you see the need of an interface and method which these activities will expose. As opposed to previous uses of interfaces to create external services this would just be a plain old interface.

Specify this interface and method in the two activities only that they now need two properties to save the incoming name value and outgoing greeting message. Define these properties and select them here. Once that is done we put in a code activity to make the response message from the incoming name.

Let's put in a fault activity as well. But we can either return a response for a request or a exception so they have to be put in a exclusive branch. For that let's put a If-Else and put the condition in that if the name is empty it throws the exception that name should be specified. When you put the service fault activity it needs a Fault property to bind to. This needs to be a Exception type of property. Define it and assign it to this activity. We need to instantiate this property to some exception value as well, so for that modify the code activity and add the following line:

The workflow should look something like this:

Till now we have defined the necessary element to define a web service not the web service itself. Let's do that now by right clicking the project and selecting Publish as Web Service. It may prompt you if the workflow is an application rather than a library. Once published, another project will be added to you solution which actually contains the proxy code for a web service that invokes your workflow and provides it with incoming name and returns the resulting output.

In the web.config you will notice an http handler:

This http module is basically part of the workflow runtime which allows you to do necessary session management for workflow webservices. From previous post you might remember that to send any message to a workflow it is necessary that we talk to it using its unique id. This unique id is available for session management and is stored on the client side in a cookie. So if the client sends a request back with the same id in the cookie then it is considered to be a request for an already running instance of the workflow otherwise a new one is created. All this could be done manually if required without using the built in wizards of visual studio. Select the web service as the startup project and run it.

Lets create a client for it and call this web service. I did it by creating another project in the same solution, adding a web reference to the running service and then selecting this client project as the startup one. Call the method from the service with a name:

It should return the response. Now call it with an empty value:

It should throw an error which says what we specified as the exception description. This ends the post on consuming and exposing web service with WF workflows. In the next post we will learn about workflow persistence, keep reading.