Randolph Cabral’s Weblog

…beauty is just a dimmer switch away…

Archive for the ‘Programming’ Category

Business Objects Enterprise 11.5 Shared Secret…Shhhh!

Posted by Randolph Cabral on Thursday, May 29, 2008

I had to blog about this because I’m sure many of you who need to deal with the BOE XI .NET APIs will find this one useful.  Also because I know I’m going to need this info again at some point and I figure this is the best place to memorialize this knowledge.  In this post, I’ll specifically talk about my experience in enabling trusted authentication to the BOE server using ‘secEnterprise’ security with the BOXI .NET APIs.  A note for Java developers – I think most of the code samples should work with the exception of the use of concrete types.  Most of the types are replaced with interfaces in Java and the naming convention is such that you should be able to add an ‘I’ to the beginning of the type names.  Why they didn’t do this for .NET is a mystery to me.

The first thing we need to do is open the secEnterprise folder on both the client machine and on the server.  The path is as follows – [Drive:\Business Objects Installation Folder]\BusinessObjects Enterprise 11.5\win32_x86\plugins\auth\secEnterprise.  Here you should find a single file named secEnterprise.dll.  If you don’t see this file, or folder, you are going to need to install the BOE XI R2 SP2 client tools.  The one I installed is dated 3/6/2007.  Once installed, the above mentioned files and folders should be present.  Once located, it’s time to add a new text file and name it “TrustedPrincipal.conf”.  Using your favorite plain vanilla text editor (I use notepad) add a line that reads, “SecretPassword=[word or phrase without spaces using 0-9, A-Z, and a-z characters only]”.  Obviously, the word/phrase must match on the client and server installations. NOTE:  If the server already has this file and a password/phrase is already present, do not change it!  I recommend copying the server value to your client file.  But, if you’re feeling macho and absolutely need to change it, a reboot of the server may be required to flush the old value from cache.

Now, the following code sample will allow you to “impersonate” any user that has been granted access to the BOE server using the trusted principal method.

  SessionMgr sess = new SessionMgr();

  TrustedPrincipal tp = sess.CreateTrustedPrincipal(“John.Doe”, “YourBoxiServerName”);

  EnterpriseSession esess = sess.LogonTrustedPrincipal(tp);

With a little bit more code, we can use the current thread to detect the security principal and parse the user name so we can pass it in as a method argument.

  string identName = System.Threading.Thread.CurrentPrincipal.Identity.Name;

 

  if (string.IsNullOrEmpty(identName))

    throw new System.Security.SecurityException(“Not logged in!”);

 

  int startIdx = identName.IndexOf(‘\\’) + 1;

  string username = identName.Substring(startIdx, identName.Length – startIdx);

 

  SessionMgr sess = new SessionMgr();

  TrustedPrincipal tp = sess.CreateTrustedPrincipal(username, “YourBoxiServerName”);

  EnterpriseSession esess = sess.LogonTrustedPrincipal(tp);

One last thing to note is that I’m referencing a combination of version 11.5.3300.0 and 11.5.3700.0 of the CrystalDecisions assemblies.

Well, that’s it.  I hope someone out there finds this post helpful. 

Advertisements

Posted in BOXI .NET SDK, C#, General, Programming | Tagged: , , | 1 Comment »

Exploring N-Tier Architecture with LINQ to SQL (Part 3 of n)

Posted by Randolph Cabral on Thursday, May 8, 2008

Part 3 – Creating Business Entities from Data Entities

In part one of this series we looked at how LINQ to SQL entities are structured by analyzing its members and mappings.  We concluded that that they aren’t suitable in a model where we would derive from them because doing so would hide the LINQ to SQL mappings from the query provider.  Creating a translation layer to handle loading and tracking of business entites would be too monumental a task to take on.   Clearly that’s not an option either.  Ideally, we want to encapsulate the data entities in business entities without sacrificing code re-usability.  Fortunately, we have a neat pattern that we can use to do just that and it’s called object composition.

Do the names Erich Gamma, Richard Helm, Ralph Johnson, and John Vlissides ring a bell?  Do you know what I’m referring to when I say, “GoF”?  Yes, you guessed it.  The Gang of Four and their book, Design Patterns: Elements of Reusable Object-Oriented Software.  In the book, they cite several important design techniques such as programming to an interface and object composition.  The one we’re interested in right now is object composition.  Take for example a business requirement where every customer record must have address data for billing and shipping.  Because the requirements for the Customer object only require a couple of addresses we can model the relationship with object composition using an Address class.  The code sample below illustrates how we would write the Customer class using this pattern.  Notice that there are two public Address properties which represent billing and shipping data as separate object instances.

public class Address

{

  public string Street { get; set; }

  public string City { get; set; }

  public string PostalCode { get; set; }

}

 

public class Customer

{

  public Address BillingAddress { get; set; }

  public Address ShippingAddress { get; set; }

}

With a little tweaking, we should be able to apply this pattern to reuse the LINQ to SQL entities within our business classes.  In the following code sample, we start by writing a business layer customer class called CustomerBus with an internal constructor that accepts a LINQ to SQL entity reference.  A private member that composes the LINQ to SQL Customer class keeps the reference in a safe place.  Now here’s where we deviate a little from the composition pattern.  Rather than adding a public property to expose the LINQ to SQL class, we’ll add public properties that expose each of the LINQ to SQL entity properties instead.  Doing this gives us more granular control in dealing with the data entity properties.  For example, we can change the names of the exposed properties, hide certain properties, and create custom domain specific validation logic for those properties we choose to expose.

//Business class

public class CustomerBus

{

  //Internal constructor that accepts LINQ entity reference.

  internal CustomerBus(Customer linqEntity)

  {

    LinqEntity = linqEntity;

  }

 

  //Private LINQ entity reference

  private Customer LinqEntity { get; set; }

 

  //Sample property that exposes a LINQ entity property

  public string CustomerID

  {

    get

    {

      //Expose the LINQ entity property

      return LinqEntity.CustomerID;

    }

    set

    {

      //Add domain specific validation logic here if desired.

      LinqEntity.CustomerID = value;

    }

  }

 

  …

}

 

Associations

Let’s take a look at how we would create relationships using this model.  One advantage of keeping a reference to the LINQ to SQL entity is that we have access to the relationships in the data layer.  Remember, our business entities can be constructed with the LINQ to SQL entities passed in as an argument to the internal constructor.  We can use the existing relationships created by LINQ to SQL in the data layer for free.  Our job just got a lot easier because all we need to worry about now is promoting the LINQ to SQL entity to a business entity.  Subsequently, we’re going to need to expose the LINQ to SQL entity member by declaring the property as “internal”.  This exposes the member to the other business entities in the assembly safely.  We’ll need this so we can read the LINQ to SQL entity to customize the add and remove logic in our collections.

//Business class

public class CustomerBus

{

 

  //Changed from private to internal.

  //And added custom getter and setter

  //LINQ entity reference

  private Customer _linqEntity = null;

  internal Customer LinqEntity

  {

    get

    {

      if(_linqEntity == null)

        _linqEntity = new Customer();

 

      return _linqEntity;

    }

    set

    {

      _linqEntity = value;

    }

  }

 

  …

Simply exposing the EntitySet<T> member from the data layer is not desirable in this case because that would expose the LINQ to SQL entities.  Support for customized add and remove logic to handle the EntitySet<T> reference requires a specialized collection class.  Our new collection class derives from System.Collections.ObjectModel.Collection<T> which implements many of the behaviors we need to manage the contained entities.  By deriving from Collection<T>, we get all of its functionality for free.  Next we can create a custom constructor that accepts the EntitySet<T> reference and declare it internal to the assembly.  We want to do this so that new collections of this type can only be instantiated from within this assembly to ensure that all instantiated objects are connected to a context.  The constructor will be responsible for promoting the LINQ to SQL entities to business entities and adding them to the collection.  Next we can add the specialized add and remove methods that hide the base class implementations to support management of the EntitySet<T> reference.  Now adds and removes are tracked by a context and can be processed as a batch.  Cool!

//Specialized business collection for OrderBus class

public class OrderBusCollection : Collection<OrderBus>

{

  //Internal constructor that uses the EntitySet<T> to hydrate itself

  internal OrderBusCollection(EntitySet<Order> entitySet)

  {

    EntitySet = entitySet;

    foreach (var linqEntity in EntitySet)

    {

      var entity = new OrderBus(linqEntity);

      base.Add(entity);

    }

  }

 

  private EntitySet<Order> EntitySet { get; set; }

 

  public new void Add(OrderBus entity)

  {

    EntitySet.Add(entity.LinqEntity);

    base.Add(entity);

  }

 

  public new void Remove(OrderBus entity)

  {

    EntitySet.Remove(entity.LinqEntity);

    base.Remove(entity);

  }

 

  public new void RemoveAt(int index)

  {

    Remove(this[index]);

  }

}

At this point, we can add the custom collection members to the business class as seen in the following code sample.  The custom “lazy” getter implementation ensures that we load the collection once it is requested and keeps a reference to the instance for future reference.  Now we have a working model that deals with the LINQ to SQL entities behind the scenes allowing for presentation code to interact purely with business entities.  Additionally, we can implement business-specific logic in the business classes in the form of validations or custom behaviors.

//Business class

public class CustomerBus

{

  //Association to orders

  public virtual OrderBusCollection Orders

  {

    get

    {

      if (_Orders == null)

        _Orders = new OrderBusCollection(LinqEntity.Orders);

 

      return _Orders;

    }

  }

  private OrderBusCollection _Orders = null;

 

  …

Yes, I know it’s lot of code to have to write by hand.  But this is one of those busy tasks that can clearly be remedied with a custom code generator.  I’m currently working on one that I will make available in a future post.  Until then, there will be a lot of code to write.  The result of writing the code is clear.  We’ve created a business entity layer that abstracts the data entities away and gives us a nice place to add domain logic.  Another point of consternation might be with the pervasive use of the LINQ to SQL entities in the business layer.  This is one case where I feel the benefit of having those entity references localized in each business class outweigh the challenges that might be introduced with changes in the data tier.  We can somewhat isolate those issues with a custom code generator which should take most of the pains away.  The code generator I’m working on declares each business class as a partial class.  This will allow us to keep our custom implementation separate from anything that was automatically generated by the code generator.

In the next post, we’ll revisit the BusinessContext class to give it functionality to attach newly constructed business objects.  We’ll also take a look at the result of our efforts so far with a sample web application that uses our new business layer and take a peek at SQL Profiler to check out how our changes impact LINQ to SQL’s query provider.

Posted in C#, Domain Model, LINQ to SQL, Object Oriented Programming, Programming, Software Architecture | Tagged: , , , , | 6 Comments »

You’re Not A “Real Programmer”

Posted by Randolph Cabral on Wednesday, April 30, 2008

I recently met up with a fellow programmer buddy of mine who has been working for a software development group that has gone through several managers recently.  Each manager, varying in both development and management experience, had varying ideas on how to approach the requirements for a specific project.  Frequent turn over in management continued to complicate things.  Eventually, they found a manager that was willing to stick it out.  Unfortunately, his management style doesn’t exactly create a creative environment where developers can thrive. 

The group has been charged with converting an existing windows forms client application for the web.  After exhaustive research into which web technology platform they wanted to develop on the manager decided to go against the tide and force the group to implement the new web application in C++.  Any developer in the group who expressed a difference in opinion was quickly shut down with the manager hinting at the notion that “real programmers” code in C++.

I have no problem with C++, but given that the requirements call for a web application, I’m going to have to respectfully disagree.  And what’s wrong with managed code anyway?  I guess only those who know how to manage resources manually are “real programmers”.  Many successful enterprise applications, both for the web and for windows, are written in Java or C#.  There are plenty of open source web development frameworks written for Java that increase productivity incredibly.  Similarly, ASP.NET with C# creates a powerful way to programatically access HTML controls. 

In other words, we have power tools now that help us with the construction process.  Don’t get me wrong, there’s still a valid and relevant use for the handsaw.  Building a house is not one of those uses.

Posted in C#, General, Object Oriented Programming, Programming, Software Architecture | Tagged: , , , | 1 Comment »