Saturday, March 24, 2012

Testing Access Services

This is part of my series on testing SharePoint service applications: http://matthewchurilla.blogspot.com/2012/02/testing-service-applications-in.html

There is a good article on MSDN for setting up a basic web database using Microsoft Access: http://msdn.microsoft.com/en-us/library/ff402351.aspx.  This article will walk you through the basics of creating a few access tables, publishing your database to SharePoint and then adding data into the database.  The site even has a sample database you can use to do your testing(http://archive.msdn.microsoft.com/Release/ProjectReleases.aspx?ProjectName=odcac2010h2&ReleaseId=3921).  I like to use this sample database as a starting point for my testing once I have started with this database I like to perform the following actions on the stock database just to get a better test of the available functionality.


  1. Use web form to add a supplier: Microsoft
  2. Use web form to add a supplier: Apple
  3. Use web form to add a supplier: Google
  4. Use web form to add a part for supplier: SharePoint, Microsoft
  5. Use web form to add a part for supplier: Office, Microsoft
  6. Use web form to add a part for supplier: Windows, Microsoft
  7. Use web form to add a part for supplier: iPhone, Apple
  8. Use web form to add a part for supplier: iPad, Apple
  9. Use web form to add a part for supplier: GSA, Google
  10. Use web form to add a part for supplier: AdSense, Google
  11. Use web form to add a part for supplier: Blogger, Google
  12. Switch back to Access and ensure that data is populated back into the database.
  13. Create a new report to test reporting.
    1. Show all fields from all tables
    2. Add "Supplier Name" to the report
    3. Remove Column "Supplier"
    4. Remove Column "ID"
    5. Add a Group on "Supplier Name"
    6. Your final report should look like this.
    7. Synchronize the report back to the web
  14. View the report in SharePoint





At this point you have performed a basic test of Access Services.  If everything outlined here worked you can be fairly confident your service is installed and working properly.  We will keep the database site published for now we might use it in future articles.  

Tuesday, March 13, 2012

Document Management with SharePoint and CRM

Microsoft Dynamics CRM is a great application for managing customer, sales, and marketing data but it is not a very good document management system.  Fortunately Microsoft has another product named SharePoint that is a great document management and storage system and now with the new version of CRM you can link entities to SharePoint so you can store related documents in SharePoint and utilize the great document management features provided by that software platform.  In this blog posting I am going to give an overview of the integration possibilities between Microsoft Dynamics CRM and Microsoft SharePoint.

First off let us take a brief look at the Document Management section of the Microsoft Dynamics CRM Settings to see what is available to us. 


  1. Document Management Settings – This option allows you to do the base configuration for Document Management.  This is where you go to configure which entities in the system document management is enabled for and where you can specify the primary document management location if you choose to have one. 
  2. Install List Component – This option points you to instructions for downloading and installing the SharePoint list component that you can install as a sandboxed solution for sites that you wish to enable enhanced document management on.
  3. SharePoint Sites – This section lists all of the sites that are linked to CRM but unfortunately it is only useful for sites that have the SharePoint List Component installed on them.   If you are not using the list component adding sites to this section will not have any effect in other parts of the system.
  4. SharePoint Document Locations – This choice is a great place for administrators to reference.  Listed in this section you will find every location that is linked to from CRM.



Starting at the top let’s examine the document management settings section.   The primary listing on this page allows you specify which entities you would like to enable document management on.  A number of these are enabled by default however you can enable document management for any stock or custom entity that exists in the system.  There is a second option present on this screen and that is an option that lets you specify a SharePoint 2010 site URL to enable automatic folder creation; this provides you the capability to automate your document management with a SharePoint 2010 site that has the List Component installed on it.  We will re-visit this later when we review the 2010 only features. 

Next we are going to take a quick look at how things look once you have document management enabled so you have a good feel for how linked document libraries will behave.  So without further ado...
Here is a sample view of how a site will look when linked via an absolute URL.  Notice how this is just an embedded view of the SharePoint Document Library, because of this, you are capable of doing anything in this embedded view you could do normally in SharePoint.  The downside is it makes for a busy screen because there is a lot going on visually and the two different UI styles clash a little bit.




And here is a sample screenshot of how linked document libraries look for sites that have the SharePoint List Component installed on them, notice how the document library has a more integrated look and feel to it this exposes all of the document management capabilities of SharePoint to the user through a more seamless CRM user interface.
The last thing I want to point out is that you are able to link more than one document location to each entity.  You are capable of having many locations which will allows you to separate documents into different locations based on similar properties.

Next let’s move on to linking CRM entities to SharePoint document libraries.  For those of you with SharePoint 2007 this will be the only integration option available to you.  However this functionality is not only available to just 2007 users; if you are operating in an environment where you cannot install the SharePoint 2010 List Component you can still use Document Locations to connect SharePoint 2010 and CRM.  Document Locations are rather primitive because they just embed an HTML viewer in the CRM page that simulates browsing the linked document library in a web browser.
When you add a Document Location and don’t have any Site Locations defined that have the SharePoint 2010 List Component installed you will be presented with an “Add Document Location” dialog box that will only be capable of linked via an absolute URL to a target document location.  In order to do these just give your document location a name and enter the full SharePoint URL you wish to link as a document location. 
Now let’s look at the SharePoint 2010 List Component; this item allows you to directly link document libraries from SharePoint 2010 into CRM.  I will not go over installing this component on a SharePoint site because this process is well documented elsewhere (http://www.microsoft.com/download/en/details.aspx?id=5283).  Once you have installed the list component on a site you will have a few new capabilities available to you. 
First you will now be able to set an automatic folder creation site.  When you enable this feature you will be prompted on whether you want to structure your folders by accounts or contacts.  Whenever you enable this feature entities that are related to the based on entity will have all of their documentation consolidated in the same folder structure within SharePoint.  For example if you had an account named Account 1 that had an opportunity named Opportunity 1 then you would end up with a folder structure that was something like “Account 1\opportunity\Opportunity 1” similarly if there was a quote named Quote 1 the folder would be named “Account 1\quote\Quote 1”.  If you don’t select to group items based on entity it will group everything within a new document library named after the entities that are contained within it.  Once you have enabled automatic folder creation the first time someone visits the document section of an entity they will be prompted to create a new folder in the appropriate location.  Personally I don't like to enable automatic document library creation, I feel that this removes some of the flexability of the system but this could be very convient for some organizations.  Below are some screen shots of how this appears in the CRM interface.

The second thing you will now be able to do is add sites into the SharePoint sites list.  Adding sites here is a good way to allow users to create folders.  When you have sites listed in the SharePoint Sites list users will now have a second option when adding a new document location.  This option allows the user creating a new document location to specifiy a new folder under an existing site that you have added to the SharePoint Sites List. 
The last section we need to visit is Document Locations and it is a very good section.  The Document Locations option enables you to view every link between CRM and SharePoint so it is a great place to review for duplicate connections and to ensure that the integration is being used properly.  You will notice in this final screen shot the difference between how absolute URL links are displayed compared to Document Locations that are setup based on a base SharePoint Site and relative references from there.
And that completes this posting on Document Management for Microsoft Dynamics CRM.  I hope you are a little more informed now. 





Monday, March 5, 2012

Configuring Secure Store

This is part of my series on testing service applications: http://matthewchurilla.blogspot.com/2012/02/testing-service-applications-in.html

We will be working on testing service applications and in order to do this properly we will need to configure the secure store service.  We are configuring this service to test the ability of service applications to access external data sources.  If you don't care about accessing external data sources from your service applications then you can skip configuring the secure store service and any future tests that involve it.

In order to not reinvent the wheel Microsoft already has some documentation on configuring most service applications and I will link to it when possible.  Here is the document for configuring the secure store service application: http://technet.microsoft.com/en-us/library/ee806866.aspx.  The steps you will want to perform in order to have a properly configured service application.

  1. Generate a New Key
  2. Create a new Target Application.  I used the parameters to the right.  Be aware setting the members to All Authenticated Users is not recommended this will allow any user to authenticate to external data sources that use the target application ID.  But since this is for testing purposes we are going to use it to make things easy.
  3. Set credentials on the target application.


Once you have a target application setup you will be able to use this application in other service applications to test data access to external data sources.