Tag: BCS

SQL Saturday Charlotte

SQL Saturday #174 in Charlotte has been announced for Saturday October 27th and is shaping up to be a great event.  The overall focus will be on Microsoft BI and with the strong BI focus there will also be a number of SharePoint related sessions available.  I will be presenting a session on SharePoint’s BCS in order to demonstrate additional ways to connect your SharePoint environment to your line of business (LOB) systems.

Event and registration details can be found on the site:  http://www.sqlsaturday.com/174/eventhome.aspx

Hope to see many of you there!

User Profiles – Driving Business Process

The workflow features first introduced in WSS 3.0/MOSS in 2007 and enhanced in the 2010 offerings present an opportunity for organizations with SharePoint to start to automate the coordination of their business processes.  While many have been working with it, one of the limitations I have seen is that everything is localized to a particular site or process.  In many cases there are configuration or user attributes managed in a local list that can be used as a data source. 

Manage the Data Centrally

One technique that is not widely used, but could greatly enhance the capabilities and manageability of the workflows as a whole would be to utilize the User Profiles more to house and maintain information relating to the users.  By managing it centrally it can be used by all processes throughout the organization.  For user maintained properties, it provides a central and secure mechanism for them to maintain it.  For system maintained properties, synchronized from an external system through AD or the BCS (HRIS, CRM, etc) there are already mechanisms in place to manage this.

In SharePoint Designer 2010 there is a new action that supports a lookup for a user’s manager.  This would be a critical component to support approval workflows obviously, but for most business processes there are other attributes that are also needed.  Some could be based on default user profile fields like Location or Hire Date, but others are likely to be custom to the organization.  Custom properties could include employee IDs, department charge codes, division identification, etc.  [Note: See User Profiles – Creating Custom Properties for a walk through] 

How to Access the Data

Typically the information is accessed via the API with UserProfileManager or the UserProfileService web service (/_vti_bin/userprofileservice.asmx).

InfoPath – From InfoPath you can identify a DataSource through a Web Service call pointing to the UserProfileService.  [Note: See Itay Shakury’s blog for full walk through]

Visual Studio Workflows – In visual studio with the full ASP.NET capabilities it is easiest and most effective to use the UserProfileManager to access the profile and all properties.

SharePoint Designer Workflows – With the exception of the manager lookup action that was added, SharePoint Designer workflows will need either a custom or third party action that can interact with the User Profiles. 

I am currently working on a simple action that I will blog about and post to CodePlex.

Other Uses – Delegation of Authority

This process could also be used to provide a mechanism for maintaining additional, more complex properties.  An example would be something like Delegation of Authority which allows a person of authority to be able to delegate (or pass) that responsibility to another person.  SharePoint does not handle this at all out of the box.  A series of fields could be defined to support this; Start Date, End Date, Delegate.  This information could be read into the discrete processes with management being centralized in the User Profiles.

The limitation with this model is that the User Profiles are not like a list and do not support advanced business rules.  If that is required a separate system would need to be build, but I would recommend you try and keep it centralized and not built into the specific process.


By leveraging the User Profiles as a central repository that can support your organization’s processes you will simplify the management of the information and make it much easier to reuse in a consistent manner across the many processes. 

Exposing Custom Web Services to the BDC

I recently had a lot of trouble getting some data exposed to the BDC.  I found the documentation pretty light and leading to a pretty frustrating experience.

In my case there are three scenarios:

Return All Records, No Finder – This one is pretty easy and it is clear that you need to return a collection of records. 

Return One Record, Specific Finder – This one is pretty simple as well and it is clear that you will get back a single record.

Return One Record, Finder – This one was the cause of all my trouble.  It seemed to me that if you are only expecting a single record then it could be defined as such.  Using BDC MetaMan I was able to generate a definition for all three types, and then able to import the definition into the BDC. 

Whenever I tried to use show the data BDC List web part I kept seeing an error.  In the ULS logs I found the following:

System.InvalidOperationException: Backend system adapter returned a structure incompatible with the corresponding metadata (MethodInstance, Parameter or TypeDescriptor)    

I of course concentrated on checking data types and matched up the web service to the definition file to make sure things were in line.  They matched perfectly, so this proved to be quite the hurdle.  Finally on MSDN I caught a reference to the error “a structure incompatible with the corresponding metadata” and making sure the Collection was specified correctly.  Even this reference did not specify that a collection was required.  We made a quick change to the web service’s returned data type and everything started working. 

So the moral of the story is… when using the BDC with anything but a Specific Finder it requires a Collection/Array to be returned.

%d bloggers like this: