brantcarter

Sharepoint is the perfect example of why you need to be careful in branding. Microsoft has made this mistake before (think .NET) so you think they would have learnt their lesson; but apparently not.

http://blogs.technet.com/lliu/archive/2006/03/22/422916.aspx

Instead of leveraging the Sharepoint name; they now want you to call it MOSS (I kid you not). IMO this ends up doing more harm than good; you end up hurting not only the Office brand but the SharePoint brand becomes a horrible mess.

• Initial (formal) mention: Microsoft® Office SharePoint® Server 2007


• Initial (informal) mention: Microsoft Office SharePoint Server 2007


• Second mention (lengthy content: more than 250 words): Office SharePoint Server 2007


• Second mention (short content: e-mails, etc. – though having the “Office” prefix is still strongly preferred): SharePoint Server 2007


• Acronym (long form – must be defined in conjunction with initial mention of the product name): MOSS 2007


• Acronym (short form – must be defined in conjunction with initial mention of the product name): MOSS

I thought that the whole Sharepoint Portal Services (SPS) vs the Windows Sharepoint Services (WSS) thing was terribly confusing; not only from a naming but also from a feature perspective.

# posted by Brant : 9:24 AM

I must have missed the announcement from PDC (that can happen when you don't actually go to the conference); so I was quite pleasantly pleased to learn about this little nugget that Microsoft is adding to SharePoint.

The Business Data Catalog is an integration component that allows business to expose business schemas to Sharepoint. Sharepoint can then index and display that data in various lists and entities. It looks pretty sweet.

BUT

1. The configuration of this beast is a total nightmare. To get a fairly simple schema requires thousands of lines of XML code to be HAND WRITTEN. At the conference I after watching them insert "snippets" I had to call out the emperor as having no clothes. The response was they were hoping for ISVs to "take the challenge" of writing their own tools. Oh brother.

2. The indexer / search doesn't work for enterprise data. I guess I shouldn't be suprised given this is a hard problem to solve.

Since the BizTalk 2004 install seemed a bit complex I figured I would just skip to 2006 and start from there. Here is a synopsis of how things went.

- Total time was about 3 hours
- I had a major SNAFU with my virtual image; some of the SQL files that needed to get run somehow got corrupted (this took me a while to figure out)
- I had to install SQL 2005 since it won't run on SQL-2000 without SP3
- The installation is fairly painless PROVIDED you get all the pre-requisites correct.
- I am not 100% convinced I still know what I got installed; since I picked the defaults for almost everything. There are probably a half-dozen components that I need to get familiar with.

I posted some reasons why Enterprise Search is hard; it looks like Google is going to try and tackle this problem as well.

Searching ERP systems seems pretty easy on the surface; just point your search engine at your data and presto-chango you have a search app. Google even sells a product that is designed for this. The big problem is that you often don't want people looking at data they aren't supposed to; and filtering out their security rights is often a complex endeavour.

The simpliest approach is to let the indexer look at everthing in your database and then filter out when the user tries to open the record. This works well except that this can lead to a poor user experience and can even expose sensitive information.

Consider this scenario:
You have 10,000 contracts you want to index; you point your indexer at it and it indexes the whole lot. Then you have a user; who only has permissionto see 100 of those contracts and he/she wants to do a search. The search results display the entire list and only when the user clicks on it to open it does it do the check.

Problem 1: The first 100 results could all be contracts the user can't see; now the user has to filter through the result list.

Problem 2: The user could determine certain contract qualities by searching for $1,000,000 and now see all the contracts worth that amount. This is a pretty serious violation of the application level security checks.

One product that seems to get this is Automony. They can integrate your applications "ACL" into their search engine and filter out results prior to displaying them to the user.

I was disapointed to learn at Office DevCon that the new fancy search that is shipping with Sharepoint 2007 WON'T be able to handle this type of filtering. This severly limits is usefullness for enterprise application integration. For a list of feature they are including you can look here

I was all setup to install BizTalk 2004 in a new playground area; then I went and dowloaded the Quick Start Guide then read the first paragraph:

You will go from FDISK to a “Hello World“ BizTalk Orchestration Sample In just about 5 hours

Ya, just 5 hours! no thanks. On to BizTalk 2006

I use Excel a fair bit in the solutions I develop for our customers; a couple of weeks ago a co-worker finally cracked a mystery that had been dogging us for a while. As with many mysteries the problem seems obvious when you know the solution and I thought I would share it here.

Problem: When creating Excel List Validations; the drop-down will often show blank lines.

Example:


As you can see the list from Item2 has blank rows in it.

Solution: The solution to the problem is two fold; first in this case I defined the ranges for both these lookups on the same sheet (which is very common); and the way I defined then was to just click on the row header and name the entire column as a range. The problem is that Excel will default the size to the largest range defined on that sheet. The solution is to resize your range after you populate it. Resizing a range isn't trivial process either!

Here is the code that does the trick: I found the code here

The key point is that range.Resize returns a new range; it doesn't resize the range you speficy; thus you need to add it back to the Names collection of your workbook.

Protected Sub ResizeRange(ByVal SheetName As String, _ 
                          ByVal RangeName As String, _
                 Optional ByVal NewRowCount As Long = 0, _
                 Optional ByVal NewColumnCount As Long = 0)
   Dim sheet As Microsoft.Office.Interop.Excel.Worksheet = ThisWorkbook.Worksheets(SheetName)
   Dim range As Microsoft.Office.Interop.Excel.Range = sheet.Range(RangeName)
   If NewRowCount = 0 Then
      NewRowCount = range.Rows.Count
   End If
   If NewColumnCount = 0 Then
      NewColumnCount = range.Columns.Count
   End If

   ThisWorkbook.Names.Add(Name:=RangeName, _
                          RefersTo:="=" & SheetName & "!" & _
                          range.Resize(NewRowCount, NewColumnCount).Address, _
                          Visible:=True)
End Sub

This has to be one of the most confusing features. Have you ever tried to delete a named range that you defined? I have and it took me forever to find out how to do it.

Normally when I define a range I just type the name in on the worksheet as below:



However Excel won't allow you to delete the range without hunting through the menu items; and it is hidden under Insert | Names | Define (as you probably didn't guess; to delete a range you need to "Insert it".



This takes you to a dialog where you can delete the range.

Note I also found this nifty little tool for managing names in Excel. Named ranges are very handy for lots of reasons; one of the most common uses I run into is when I want to validate a cell against a list of items. I will cover that in a future post.