To help kick off the K2 blackpoint Beta, K2 has started up a game of “collecting points” and winning some cool prizes.  Search high and low in blog posts, web pages, web casts, conferences, advertisements, etc. and log your finds at the official K2 blackpoint site.

Clues for where to find the points are posted at the K2 Underground.

I’ll be on the hunt, hopefully gathering enough points for that 30″ monitor grand prize.

You don’t actually need the Excel 2007 client installed in order to create and deploy Excel workbooks that can be used in Excel Services in MOSS 2007.  In order to use Excel Services, you *do* need MOSS Enterprise 2007.  And workbooks used by Excel Services *do* need to be in Excel 2007 format, but as long as you have the Office 2007 Compatibility Pack installed, you can use Excel 2003 to save your workbook in a compatible Excel 2007 format.

Named Areas
One of the capabilities provided by Excel Services is displaying a specific range of cells or a specific chart on a web part page in Sharepoint.  The behavior and implementation of how you setup these named areas is slightly different between Excel 2007 and Excel 2003.  With Excel 2003 it provides a default name for each chart that is created.  This looks like “Chart 1″, “Chart 2″, etc.  You can override this name by selecting the chart object and entering a new name in the Name Box field, which appears by default in the top left portion of the screen. 

Note that the trick to selecting the chart object so that you get this Name Box populated with the actual name of the chart is to hold down the Ctrl key while clicking the chart.  Otherwise you’ll end up selecting a particular element of the chart (e.g., Chart Area, Plot Area, etc.).  This is slightly different behavior than Excel 2007, and it drove me nuts trying to figure this out.

To get a range of cells to be a named area, simply select the range of cells and type in a name in the Name Box.  To change the name you need to select the identical range of cells before the Name Box will populate with your name to change.  Again, not obvious.

Save As Excel 2007 Workbook
Once you’ve done this, simply save your Excel workbook in the Excel 2007 Workbook format with the Save As menu item.

You can then upload this workbook file into your Sharepoint document library, like any other file you might want to make available in a library.  I won’t go into details on Trusted File Locations, but you do need to have your document library setup as trusted in Sharepoint Central Admin in order for Excel Services to display your workbook in the web part or a web page.  Also note that there are a variety of unsupported features and requirements that you need to keep in mind when preparing your workbook for Excel Services consumption.

Sidebar - Excel 2007 Publish Option
Excel 2007 provides you with a an alternative approach to making your workbook available to Excel Services.  It has the idea of “publishing” your workbook to Excel Services.  You’ll see a new menu item for this in the Excel 2007 client.

When you select this option you basically get the same Save As dialog, but with a couple of extra options.  One of which is the Excel Services Options button.

Clicking this button presents a dialog where you can restrict which specific worksheets, named range of cells, or specific charts you want to make available for viewing in Excel Services.

In the text of this dialog it reiterates that what you are specifying is really only restricting what is seen in the browser view of the document.  A user with privileges to open the workbook in their Excel client will be able to see the entire contents.  All that Excel is really doing when you specify these options is adding some metadata to the file so that Excel Services knows what to show in the browser view of the workbook.  So don’t think of this as a high level of security control over the contents.  However, you actually can restrict users to only opening the workbook in the browser view by only granting them View Only access in Sharepoint (instead of Read, for example).

This Excel Services Options dialog is also used to specify specific cells that you want to make available as Parameters in Excel Services.

‘Show’ and ‘Parameters’ - Not Features in Excel 2003
Note that these two features in the Excel Services Options dialog are two features you will not be able to support if you’re using Excel 2003 to create your workbooks for Excel Services.  So, if that’s important to your solution, then you’ll need to upgrade to the Excel 2007 client.

Excel Web Access Web Part
Once you have the workbook saved in the document library you can make it available on a Sharepoint page using the Excel Web Access web part.

Then modify the web part properties to specify the specific Excel 2007 file, and the named item/area.

The Named Item field corresponds to the Named Area within the Excel workbook, and will restrict what is actually shown in the web part on the page.  You can use multiple instances of the Excel Web Access web part on the same page if you want to display multiple charts or multiple cell regions.

I’ll provide another post in the future that demonstrates how to hook up Sharepoint filters to dynamically control the named area shown.

If you create a Report Center site in Sharepoint 2007 and use the Reports Library document library which is created by default, then any Excel workbooks you view from that library are displayed in the Excel Viewer web page by default.  Simply clicking on the Excel workbook within the document library opens the Excel document using the Excel Web Access web part in a full web page.

If you are using your own custom library to contain Excel workbooks for viewing via Excel Services however, you won’t get this behavior by default.  Instead, when clicking on the workbooks in the document library they will be sent down to the client PC and subsequently opened in the Excel client.

You can still accomplish viewing the workbooks in the web page viewer by clicking the drop down menu associated with the workbook file and choosing View in Web Browser.

This may not be your desired preference though, and you can override this default behavior.  The key is in the Advanced Settings section of the document library that houses the workbooks.  Select the “Display as a Web page” option here to have the workbooks displayed in the web page viewer by default.

K2 will be announcing their new product offering, named K2 blackpoint, tomorrow at Microsoft TechEd.  K2 blackpoint will be a new SKU, which is a subset of the K2 blackpearl offering.  It will be targeted for Sharepoint developers who want to easily build more sophisticated workflows and process driven applications than what you can do with Sharepoint out-of-the-box workflows, Sharepoint Designer, and Windows Workflow Foundation (WF).  It will also be an entry point for those wanting to test the waters with K2, and will provide an upgrade path to the more complete K2 blackpearl product offering.

The components you get with K2 blackpoint:

K2 Studio
K2 will be reintroducing the standalone designer concept that K2.net 2003 had with the new K2 Studio (which was previously blogged about and previewed).  There will be no dependency on having Visual Studio for constructing workflows.  The new K2 Studio provides an Office 2007 like application (complete with ribbon like interface) for dragging, dropping, and clicking workflow processes.

K2 Studio is targeted towards less developer-focused individuals, and will have very similar wizard driven steps for configuring the processes as in K2 blackpearl, but will not have the ability to drop into code or modify WF schedules.  Designing workflows will also include a set of stepwise Guides (which are extensible and customizable) for assisting the user in composing their workflows on the design surface.

Process Portals
K2 blackpoint will include Process Portal functionality (which was also previously previewed on K2 Underground).  This will take the place of the Workspace for the K2 blackpoint product, and will provide a set of Sharepoint web parts for centrally managing/monitoring/reporting on workflow processes.  You set up a Process Portal via Sharepoint Central Admin, and can either instantiate a new site, or extend an existing one.

Sharepoint Integration
As mentioned earlier, the primary drive behind K2 blackpoint is Sharepoint integration.  While K2 Studio will not have a specific SmartObject designer, you will have the ability to create SmartObjects from Sharepoint libraries and lists via Sharepoint menus.

These Sharepoint SmartObjects can then be consumed within processes authored in K2 Studio.  Other types of SmartObjects will not be accessbile, but you always have the option of integrating with line-of-business systems via web services.

Other points of Sharepoint integration include having all of the Sharepoint Event templates (e.g., Sharepoint Publishing, Sharepoint Lists Items, Sharepoint Search, etc.), integration with Sharepoint users and groups, integration with Sharepoint content types and workflows, and integration with Sharepoint events.

Other
Other functionality includes:

(*) Out-of-Office integration with Outlook/Exchange, allowing redirection of tasks
(*) Extensibility via ADO.NET data provider
(*) Extensibility of custom templates, wizards, etc.
(*) Out-of-the-box reports, and ability to customize SSRS reports
(*) Graphical representation of processes in progress
(*) Future release will include a Silverlight based design canvas in addition to the K2 Studio designer

Some notable exclusions:
(*) No BDC integration
(*) No built-in report designer

K2 blackpearl
As mentioned before, one of the goals with blackpoint is to serve as a starting point for those interested in the K2 products.  There will be an upgrade path available for moving from K2 blackpoint to K2 blackpearl.  All of the workflows authored in K2 Studio and running on the K2 blackpoint server should work as-is when moving to K2 blackpearl.  It should also be worth noting that the K2 Studio, Process Portals, Out-of-Office integration, etc. will be a part of K2 blackpearl releases.

More information on the product, the beta information, and pricing is available on the K2.com blackpoint page.

I blogged earlier on Mouse Gestures in K2 blackpearl.  Anthony Petro from K2 sent me some additional information about configuring the gestures.  In the \bin\configurationmanager.config file of your blackpearl install folder there is a <wizards> section where all of the wizards are configured.  Here you can register a Mouse Gesture to trigger the startup of a wizard.  For example, for the Default Activity wizard you will find the following configuration code:

<wizards>
  …
  <wizard text=”Default Activity” … >
    <settings>
        …
        <add key=”MouseGestures” value=”A,O” />

In looking at the default configuration in this file, the default Mouse Gestures appear to be:

A, O - Default Activity
C - Default Client Event
M - Mail Event
P - InfoPath Client Event
S - Default Server Event (Code)
W - Default Server Event (Workflow)

In my previous post I also indicated it would be interesting to see this gesturing approach carried into other designers in Visual Studio.  It appears someone has already worked on this integration in the Mouse Gestures Add-In for Visual Studio out on CodePlex.  The add-in utilizes the more generalized Mouse Gestures for .NET component, which can be used to add mouse gesturing to any .NET application you write.   When I have time, I’ll be digging into these more.

In the K2 blackpearl Designer for Visual Studio you can use mouse “gestures” to populate the design canvas, instead of dragging/dropping elements from the toolbox.  For example, you can draw an “S”, and have it get converted into a new Default Server Event on the process canvas.

A more useful application of the gesturing technique is adding a Line between activities by simply drawing the line from one activity to another.

To use this technique, you first right-click the canvas.  The mouse turns into a ink pen like pointer.  You then draw with the mouse (or pen on a Tablet PC) and release the right-click when done.  The drawn letter will convert into one of the elements from the toolbox, or execute a wizard corresponding to one of the elements.   I couldn’t find this gesturing approach documented anywhere, and after playing with it for a little while I discovered the following gestures and corresponding toolbox element:

A,H,W - Default Server Event (Workflow)
C - Default Client Event
D,F,P - InfoPath Integration Process
M - Mail Event
O - Default Activity
S - Default Server Event (Code)

I found this whole gesturing approach much easier to use on a Tablet PC with a pen vs. trying to draw with a mouse - especially anything with curves.  The gesturing is pretty picky about how you draw the letters.  In fact I’m not sure D, F, and P are all really letters intended for the InfoPath Integration Process.  I may have just happened to draw them all similar to a “P”.  It seemed to follow more of a Graffiti convention to scribing letters than a handwritten one.  There were times when I tried to draw an “M” in a handwriting style where it would run the InfoPath Integration Process wizard instead of creating a Mail Event.

I’m not sure how much I’ll remember the gestures and make use of this when authoring K2 processes, except for when drawing lines between activities.  I do think this is a fascinating UI approach, and can achieve some great efficiencies given the right scenario.  I’d love to see other Visual Studio designers make use of this (e.g., draw buttons on a Windows Form design canvas with a “b”).

A co-worker received the following error message when attempting to deploy a report from Visual Studio to a Sharepoint document library setup for Integrated Mode with SSRS.

“A connection could not be made to the report server…”

The message was followed by some additional information that indicated “Client found response content type of ‘text/html; charset=utf-8′, but expected ‘text/xml’.” as well as some additional HTML tags.  The error dialog was rather ugly.  Other developers working on the same solution with other reports were not having this problem.

The gist of the problem was that the developer’s PC did not have SQL Server 2005 Service Pack 2 installed.  Once the Service Pack was installed the error went away and the report could be deployed.

Here’s an easy tip for formatting XML in Visual Studio which apparently isn’t very well known.  There are times I find myself using Visual Studio to view/edit an XML file, and the source XML is tightened with no line breaks (for whatever reason) after the nodes.  Below is one example.

<?xml version=”1.0″?>
<BrowserInfo><Browser><Name>Microsoft Internet Explorer</Name><Path>“C:\Program Files\Internet Explorer\iexplore.exe”</Path><Resolution>0</Resolution><IsDefault>True</IsDefault><DDE><Service>IExplore</Service><TopicOpenURL>WWW_OpenURL</TopicOpenURL><ItemOpenURL>“%s”,,0xffffffff,3,,,,</ItemOpenURL><TopicActivate>WWW_Activate</TopicActivate><ItemActivate>0xffffffff,0</ItemActivate></DDE></Browser><InternalBrowser><Resolution>0</Resolution><IsDefault>False</IsDefault></InternalBrowser></BrowserInfo>
     

You can use the Format Document (Ctrl+E, D) command from the Edit->Advanced menu to nicely format your XML document:

This results in a much nicer formatting of the hierarchical information:

<?xml version=”1.0″?>
<BrowserInfo>
  <Browser>
    <Name>Microsoft Internet Explorer</Name>
    <Path>“C:\Program Files\Internet Explorer\iexplore.exe”</Path>
    <Resolution>0</Resolution>
    <IsDefault>True</IsDefault>
    <DDE>
      <Service>IExplore</Service>
      <TopicOpenURL>WWW_OpenURL</TopicOpenURL>
      <ItemOpenURL>“%s”,,0xffffffff,3,,,,</ItemOpenURL>
      <TopicActivate>WWW_Activate</TopicActivate>
      <ItemActivate>0xffffffff,0</ItemActivate>
    </DDE>
  </Browser>
  <InternalBrowser>
    <Resolution>0</Resolution>
    <IsDefault>False</IsDefault>
  </InternalBrowser>
</BrowserInfo>

When deploying a custom SSIS Connection Manager component you need to ensure the DLL assembly is deployed into the GAC (C:\Windows\Assembly) as well as the \DTS\Connections folder.  This is true even when deploying to a non-developer PC, such as a test server or production server.

The documentation found in the SQL Server Books Online seems to indicate you need to copy the DLL to the \DTS\Connections folder so that the BIDS designer can locate the custom components to use when authoring a package.  This is true, but a little misleading.  In my experience the assembly needs to be copied to the \DTS\Connections folder even on servers where the packages will just be executing.  The documentation does provide some help on how to find the specific path the assembly needs to be copied to, including the registry key which contains the full path to the \DTS folder.

Note, I did not find this to be the case for custom SSIS Data Flow components.  Placing the DLL in the \DTS\PipelineComponents folder was only necessary on the developer PC when designing the package.  Just copying it to the GAC was sufficient for servers which execute the packages using the custom data flow components.

For our SSIS custom components (custom connection managers, custom data sources, custom data transformations, etc.) we have them deployed into the GAC and copied into the appropriate \DTS folder so that they become available in the design tools to be dropped on a design canvas.  This is accomplished via the Build Events in Visual Studio:

We also use TFS and TeamBuild for daily builds.  We run unit tests on our database stored procs and functions, and on our custom business assemblies.  No unit testing on SSIS components yet, but I am interested in what’s happening in this space.  The problem we ran into with TeamBuilds on the SSIS custom components is that we didn’t want/need the build events to occur.  In fact our TeamBuilds failed because the paths couldn’t be resolved.

To resolve this I opened up the project files and modified the PreBuildEvent and PostBuildEvent tags to include a condition checking if the build was occurring within Visual Studio or not.  The tags look like this now:

<PropertyGroup>
  <PreBuildEvent Condition=”‘$(BuildingInsideVisualStudio)’==’true’”>“$(DevEnvDir)..\..\SDK\v2.0\Bin\gacutil.exe” /f /u “$(TargetPath)”
del “C:\Program Files\Microsoft SQL Server\90\DTS\PipelineComponents\$(TargetFileName)”</PreBuildEvent>
  <PostBuildEvent Condition=”‘$(BuildingInsideVisualStudio)’==’true’”>“$(DevEnvDir)..\..\SDK\v2.0\Bin\gacutil.exe” /if “$(TargetPath)”
xcopy “$(TargetPath)” “C:\Program Files\Microsoft SQL Server\90\DTS\PipelineComponents”</PostBuildEvent>
</PropertyGroup>