BizTalk

Task Oriented Programming

Tim Huffam — Mon, 08 Sep 2008 12:10:06 GMT

For some time I've been wondering if there's a better way to program business logic. Years ago I used to write COBOL, then moved onto a 4GL, bla bla bla... and today I find myself well entrenched in OO with Microsoft's .Net. Development times don't seem to be much better these days - and the complexity of things seems to have mushroomed.

We went from barely-a-3GL to 4GL back to 3GL plus an explosion of things you need to consider. We started with procedural code then moved to OO and seem to have got stuck there. But somehow I think we need to revise our use of OO. Business logic is predominantly procedural code - even if written in OO; it starts, follows a process, performing stuff until finished eg Customer.UpdateCreditLimit()

OO is really good for modelling things - as per the classic OO examples of a bicycle or car. And thus they model business things quite well too - like an Invoice or a Customer.

However, I've found that the more object oriented the code gets - the less productive, maintainable and flexible it becomes. Not saying leave OO - far from it - it's brilliant. It's just that we need to learn when to say 'when'. The use of patterns has helped a huge amount - but these can also caused similar problems - when being applied where they aren't really needed - resulting in overly complex software (read: inflexible and unmaintainable and unproductive). It's a fine line - and it's not easy to get the balance.

A major break through in this area is LINQ. This has meant we have less clutter in our apps catering for ORM (brilliant). This has resulted in code very similar to the old 4GL days (essentially 4GLs were just SQL based code anyway) - where all you care/code about is the business logic - caring not a jot about how or where a Customer or Order got created - and in this age of SOA - that becomes more important (as a Customer could come from many different sources - local RDBMS, company ERP, external CRM etc). I guess you could say LINQ allows you to focus your code to be more domain specific (not saying it's a DSL).

I have been playing with workflows for donkeys of years and found that although the individual workflow systems themselves can range from very simple to incredibly complex - the individual tasks they perform need not be. This had lead me to start thinking about applying this principle to code design at a reasonably low level.... what if we developed tasks as objects. Each task has just one job (I've heard some people say this is how objects 'should' be coded anyway). It has properties that can be get/set. Keeping things dead simple, eg:

public class AdderTask
{
    public int Addend1 { get; set; }
    public int Addend2 { get; set; }
    public int Result { get; set; }
    public AdderTask(int addend1, int addend2)
    {
        Addend1 = addend1;
        Addend2 = addend2;
    }
    public AdderTask Execute()
    {
        Result = Addend1 + Addend2;
        return this;
    }
}

To run this you'd simply do this:

int result = new AdderTask(1, 2).Execute().Result;

Exposing the task's properties means you can build up get and set statements - and because the Execute method returns the task object itself you can easily use it in a single line as if it was a method on it's own - or retrieve it's property values after the Execute (these tasks would easily be adapted to work within a workflow system).

This style lends itself to expanding; rather like building blocks, you can build large workflows out of these task oriented blocks. The workflows themselves coded just like these tasks - whereby all the business logic resides within the Execute() method.

Adding LINQ to the mix takes this to the next level - allowing you to build software that is simple to develop and understand.

I've been building a sizable system using this technique and I'm finding that I'm converting code developed using standard OO practices over to this methodology as it makes code more easily reused - but most importantly: easier to read and maintain.

In summary:

All input and output parameters should be implemented as properties (getter and setter accessors).
Provide a constructor that accepts all required parameters. A default constructor (with no parameters) is optional (I've found I never need these - but if you were to use these tasks in a workflow system they may need this).
Provide an Execute() method that takes no parameters and returns the object instance eg return this;
The object should clean up after itself.

Other notes:

Originally I created a similar type of class for workflows - but I found that these ended up being no different in concept to tasks. Likewise I've found that some tasks needed to call other tasks - so I've ended up just implementing everything as tasks. On reflection this is actually quite valid - because, as I found when building large orchestrations using Biztalk, workflows become atomic tasks themselves when used within the context of a large orchestration (which may run many workflows and external tasks) - and the orchestration, from a highlevel could also be considered an atomic task.
I've found using System.Transactions.TransactionScope great for scoping transactions around many tasks when creating a macro task that runs many sub tasks.

Suggestions/comments very welcome - I'd like others to expand or comment on this.

Tim

VS Collection Manager location. Registering/enabling html help collections.

Tim Huffam — Wed, 12 Jul 2006 20:52:00 GMT

Use the Collection Manager to enable/disable which html help collections are available to your Visual Studio IDE (dynamic help etc).

For VS.NET 2003 use: ms-help://MS.VSCC.2003/VSCCCommon/cm/CollectionManager.htm

For VS2005 use: ms-help://MS.VSCC.v80/dv_vscccommon/local/CollectionManager.htm

For more info see the FAQ at the Helpware Group's web site.

HTH

Tim

Case insensitive XPath

Tim Huffam — Wed, 05 Jul 2006 23:01:00 GMT

XPath statements are case sensitive. To get around this use the following example to convert all data to lower case before performing the equality check:

/bookstore/book[translate(@category, 'ABCDEFGHIJKLMNOPQRSTUVWXYZ', 'abcdefghijklmnopqrstuvwxyz') = '" + searchtext.ToLower() + "']

Thanks very much to Harish for this!

Error (m_safeCertContext is an invalid handle.) when accessing a client certificate using .NET 2.0/VS2005

Tim Huffam — Tue, 18 Apr 2006 01:58:00 GMT

This error (m_safeCertContext is an invalid handle.) occurs when you try to access a client cert (or a member of the cert) from a ASP.NET 2.0 application developed using VS2005 eg:

X509Certificate cert = new X509Certificate(Request.ClientCertificate.Certificate);
string certSerial = cert.GetSerialNumberString();

The error is thrown because no valid certificate is found. This can be caused by either:

A problem with the cert. A common reason for this in a development environment is one of the cert properties differing from that of the environment eg cert common name does not match the site name. I guess this would also occur if the cert had expired.
The cert did not get passed to the request.

If the cert has not been passed to the request. Then it's probably because you've not setup the website to be able to accept certs. To do this you need to do the following:

Host the project from IIS - not the thin web server that is bundled with VS2005.

From within VS2005 select File - New Web Site.
Select the Location of HTTP then enter the path eg: http://localhost/MyWebSite. Note that you don't have to use HTTPS just yet (I find it easier for development to use HTTP then when deploying to UAT or Production to use HTTPS).

Code up a test form.
Go into IIS Admin - right click on the new app (MyWebSite) and select Properties.
On the Directory Security tab, click Edit... under 'Secure communications'.
Make sure 'Accept client certificates' is checked.
When you run your app - make sure you use HTTPS in the url eg: https://localhost/MyWebSite

Here's another article about this.

HTH

Tim

Log4Net - writing to windows event log with ASP.NET

Tim Huffam — Wed, 12 Apr 2006 19:48:00 GMT

I found that there were a couple of things required to get this working - over and above the samples shown here.

To initialize Log4Net and to tell it to load it's configuration from the web.config file add the following line to the Application_Start method within Global.aspx:
log4net.Config.XmlConfigurator.Configure();
To make sure all unhandled exceptions are logged add the following line to the Application_Error method within Global.aspx:
    Log.Fatal("An uncaught exception occurred", this.Server.GetLastError());
For this to work you'll need to define the Log member eg:
    private static ILog Log = LogManager.GetLogger(MethodBase.GetCurrentMethod().DeclaringType);
will also need to add the following so you can access the Log4Net and reflection classes:
    using log4net;
    using System.Reflection;
Add code in your app to write logs - this is done the same way as step 2 (define a Log member and use one of it's log writing methods eg Log.Info(), Log.Warn(), Log.Error() and Log.Fatal(). These writing methods take a string and/or and exception as input parameters.
Register your app with the event log. You can do this either with an installer or manually (ie code it using the System.Diagnostics.EventLog.CreateEventSource() method).
Add nodes within the app config file to configure Log4Net. Note that params LogName and ApplicationName are optional (although I couldnt get it to work without at least specifying the ApplicationName - as that's what you register with the eventlog) The following is an example from a web.config (note that both the configSections and the log4net section are directly beneath the root configuration node - ie not within system.web):

Additional Resources:

Tom Gilki has written a good article explaining basic use of Log4Net found here.
If you are having security problems writing to the event log have a look at MS's solution here or my solution here.
Scott Colestock has a great article documenting how to use Log4Net with Biztalk here (a lot of useful info here even if you're not using Biztalk).

HTH

Tim

How to determine assembly and .NET CLR runtime versions at runtime.

Tim Huffam — Tue, 28 Mar 2006 03:14:00 GMT

This really very simple, once you know how....

To get the version of the currently running assembly:

System.Reflection.Assembly assembly = System.Reflection.Assembly.GetExecutingAssembly();
System.Reflection.AssemblyName assemblyName = assembly.GetName();
Version assemblyVersion = assemblyName.Version;

To get the version of the CLR runtime:

Version CLRVersion = Environment.Version;

Serialization: How to serialize and deserialize using C# .NET

Tim Huffam — Thu, 09 Feb 2006 01:59:00 GMT

Serialize (convert an object instance to an XML document):

// Assuming obj is an instance of an object
XmlSerializer ser = new XmlSerializer(obj.GetType());
System.Text.StringBuilder sb = new System.Text.StringBuilder();
System.IO.StringWriter writer = new System.IO.StringWriter(sb);
ser.Serialize(writer, obj);
XmlDocument doc = new XmlDocument();
doc.LoadXml(sb.ToString());

Deserialize (convert an XML document into an object instance):

//Assuming doc is an XML document containing a serialized object and objType is a System.Type set to the type of the object.
XmlNodeReader reader = new XmlNodeReader(doc.DocumentElement);
XmlSerializer ser = new XmlSerializer(objType);
object obj = ser.Deserialize(reader);
// Then you just need to cast obj into whatever type it is eg:
MyClass myObj = (MyClass)obj;

HTH
Tim

Turning off .NET security

Tim Huffam — Thu, 01 Dec 2005 21:03:00 GMT

When you're developing .NET apps the .NET security can be a right pain in the butt, so to avoid any more head aches you can simply turn it off by using the caspol utility eg:

caspol -s off

While this is somewhat overkill (much like cutting your toe nails with a sythe), it certainly gets you up and running in no time. However the problems come when you start moving from your dev platform, onto testing & prod environments. But hopefully with you'll implement a more thorough approach.

This works fine for .NET 1.0/1.1, however for .NET 2.0 they have changed this so you can no longer ditch security in such a wide sweeping fashion. Here they still allow 'caspol -s off' however it is only effective while the cmd shell is open. Another method for .NET 2.0, is via the .NET Configuration tool - just update the security settings for the zone you use.

HTH
Tim

"Error 1308. Source file not found" occurs when installing MSDN Library

Tim Huffam — Tue, 18 Oct 2005 21:57:00 GMT

This error occurs if you try to install the MSDN library using a network or localdrive install - where you've copied the content of the CD's/ISO's into separate directories, eg:

c:\msdn_2005Oct_disc1
c:\msdn_2005Oct_disc2
c:\msdn_2005Oct_disc3

To solve this problem, copy the contents of all dirs into 1, eg just copy the Program Files directory from all other disc dirs (in this example (c:\msdn_2005Oct_disc2 & c:\msdn_2005Oct_disc3) into the first disc dir (c:\msdn_2005Oct_disc1).

Then re-run the install frmo the first disc dir (c:\msdn_2005Oct_disc1).

HTH

Tim

Config error: Failed to deploy Biztalk system assembly... DefaultPipelines.dll

Tim Huffam — Thu, 07 Jul 2005 10:49:00 GMT

When running the config wizard for BizTalk2004 (on windows 2003) the following error occurred:

Failed to deploy Biztalk system assembly "C:\Program Files\Microsoft BizTalk Server 2004\Microsoft.BizTalk.DefaultPipelines.dll". Unspecified exception: Unable to generate a temporary class (result=1).
error CS2001: Source file 'C:\WINDOWS\TEMP\dbqvusoe.0.cs' could not be found.
error CS2008: No inputs specified.

The solution is to give the 'NETWORK SERVICE' user read and write access to the c:\windows\temp directory.

Thanks to Asbjørn for this : http://www.biztalkug.com/Newsgroups/setup/88013.aspx

HTH

Tim