Sunday, May 27, 2012

Dundas Chart/Gauge for SharePoint: common scenarios

This post will contain a few common problems/scenarios with Dundas Chart/Gauges for SharePoint, solutions to which are not easily found. You will need to dig around a little bit to get these answers and the Knowledge Base on Dundas site is not very helpful.
Scenario#1) Hyperlink: How would you make each bar a hyperlink, generated dynamically (as shown in the screenshot below)?


Tooltip and Hyperlink on each Bar



The code snippet below tells you how to. Simply paste the code using the Code Editor, and replace it with your particular columns from the datasource. The Hyperlinks will be generated when the chart loads.


   1:  foreach (Series series in chartObj.Series) 
   2:   
   3:  { 
   4:   
   5:   foreach (DataPoint dp in series.Points) 
   6:   
   7:   { 
   8:   
   9:    if (dp.YValues[0] == 0) 
  10:   
  11:    { 
  12:   
  13:     dp.ShowLabelAsValue = false; 
  14:   
  15:    } object o = dp["URL"]; 
  16:   
  17:    if (o != null) 
  18:   
  19:     { 
  20:   
  21:      string value1 = o.ToString(); 
  22:   
  23:      dp.Href = "" + value1 ; 
  24:   
  25:      dp.MapAreaAttributes = "Target=_Blank"; 
  26:   
  27:     } 
  28:   
  29:    } 
  30:   
  31:  }
  32:   

Scenario #2) Tooltip: How would you display a tooltip on each Bar of your Chart Series? It is pretty sraigthforward. Connect you chart to a Data Source, and as you go through the wizard, make sure you pick a column coming from your datasource selected in the Tooltip field, as shown in the screenshots below:



Column Selected from the DataSource on the Tooltip Field

Scenarios #3) Read Querystring Value from Url: If you need the Dundas Chart to read a Querystring Value from the Url, here are the steps:


1) Throw a Querystring Url Filter Web Part on your page. Then complete it's customization as you would for any other web part, as shown in the screenshot below.


Querystring Filter Web Part
Querystring Filter Web Part - Edit Mode

2) Once the configuration is complete, connect it to the Dundas Chart Web Part that you would like to send the Filter Values to, just like you would do for any other web part that is getting its value from a Querystring filter web part (sample screenshot below).


Read Value from Querystring Filter Web Part

3) Once the value has been read, you could send it to the data source, using the Connect to Data Wizard in the Dundas Chart, like in the following example, I am calling a stored proc to the backend database, while passing Country as a parameter read from the Querystring Filter web part by the Dundas Chart Web Part.



Send Querystring Value to stored proc

Scenario #4) Hide and Show Dundas Charts based on Querystring value:
What if you want to hide dundas charts based on a Query string value, For example, if you want to prevent a chart from showing empty in case someone lands on a page without a querystring string value, which is neccesary to load data on the chart.

The following code snippet will show you how to accomplish this need. Make sure it is pasted in the Code Editor's PostInitialize method.

   1:  if(chartObj.Page.Request.QueryString["CountryCode"] != null)    
   2:  { 
   3:  string s = chartObj.Page.Request.QueryString["CountryCode"];    
   4:  int i = int.Parse(s);    
   5:  if (i != 304 && i != 308)  
   6:  {  
   7:  ChartWebPart wp = (ChartWebPart)chartObj.Parent;    
   8:  wp.ChromeState = System.Web.UI.WebControls.WebParts.PartChromeState.Minimized; 
   9:  wp.ChromeType = System.Web.UI.WebControls.WebParts.PartChromeType.None; 
  10:  chartObj.Visible = false; 
  11:  } 
  12:  else 
  13:  { 
  14:  chartObj.Visible = true;   
  15:  ChartWebPart wp = (ChartWebPart)chartObj.Parent; 
  16:  wp.ChromeState = System.Web.UI.WebControls.WebParts.PartChromeState.Normal; 
  17:  wp.ChromeType = System.Web.UI.WebControls.WebParts.PartChromeType.None;   
  18:  } 
  19:  } 
  20:  else  
  21:  {
  22:  ChartWebPart wp = (ChartWebPart)chartObj.Parent; 
  23:  wp.ChromeState = System.Web.UI.WebControls.WebParts.PartChromeState.Minimized; 
  24:  wp.ChromeType = System.Web.UI.WebControls.WebParts.PartChromeType.None; 
  25:  chartObj.Visible = false;  
  26:  } 

Sunday, May 13, 2012

Custom SharePoint Application with Mobile, Offline Requirements

Technical Requirements:  needed to design a web app  with the following Technical Requirements: 

1) A Web App that can be used to perform CRUD operations on data, which could consist of several tables with parent-child relationships and some independent tables such as Master tables that drive data types used in the parent-child tables OR, the same hierarchy could be replicated to SharePoint lists. That was one decision to be made as we though through the design (Decision #1).


2) The app must support offline editing of data through iPads, because many aspects of data entry are done in places with no connectivity to the Internet and the iPad camera needs to be leveraged for taking pictures and uploading them as attachments to data records. This required us to make a decision on which third party app to use for offline support or build our own mobile app (Decision #2).


3) Users must be able to generate Reports and Dashboards. We needed to determine the Reporting platform for this product (Decision #3).


4) Users must be able to set Alerts on the data.
5) The solution needs to be delivered quickly (4-8 weeks).

6) The data volume is not expected to be very large ( probably range between few thousand to ten thousand records).

Solutions Considered

1) ASP.NET Web App with a Relational Database: One way is to design a relational database and an ASP.NET  Web App to perform CRUD operations on it. This would have meant us reinventing the wheel for requirements such as Alerting, Reporting etc., besides ofcourse implementing standard features such as Authentication, Authorization etc. that any asp.net app needs would still have to be done. Given that this is a SharePoint shop, going this route seemed like lots of custom development and might not work in the short time we had for this project. Also, had we gone this route, we would still have needed to either develop a native iPad app or develop a hybrid app for this Web App.

 
2) Third-Party Web Parts on SharePoint: We did evaluate Third Party web parts such as Quest Web Parts to quickly create this app. Using this approach, we could still take advantage of all the OOTB features SharePoint has to offer and also take advantage of native iPad apps such as Shareplus available on the App Store for Offline Editing of SharePoint data. This would have however, required us to ramp up on customization of the Quest Web Part, not to mention extra licensing costs for the server licensing. 
Since SharePoint 2010 makes it easier to develop Visual Web Parts, and the users were already familiar with SharePoint, we decided to build our own Visual Web Part for this solution and adopt Solution 3) explained below.

3) SharePoint Visual Web Part and Lists: The Visual Web Part would be the interface and instead of using a relational database as the back end, we decided to use SharePoint lists instead. The lists would have a relational design with lookup columns for joins.


The SharePoint lists would then give us all the OOTB features SharePoint already provides such as Alerts, Export to Excel, Metadata Search etc.

One other advantage of using SharePoint lists for this project is that we could solve the offline editing problem by using apps already available on the App Store, such as SharePlus, which do a good job of supporting offline editing of Lists. It would have been harder to solve this problem if we had built a custom relational database.

We decided to leverage products including Dundas charts for SharePoint, Excel Services and Performance Point for the Reports and Dashboards.


Disadvantages: This solution does have some disadvantages, first of all, even though SharePoint 2010 does allow some amount of relational database power, such as allowing cascading/restricted deletes, using SPQuery.Joins or the use of SharePoint to LINQ to perform joins, it still cannot be looked upon as a full fledged relational database solution. We will need to live with the consequences of this decison throughout the life of this product. As we work on enhancing it, set up reporting etc., we will always face challenges with joining and querying different lists.
Another problem is that since we have two interfaces, one is the visual webpart interface, and the other is the native iPad app for offline use, the user experience becomes dramatically different as a user switches between the desktop browser to the mobile app. This is a disadvantage we would have to live with till we have time to build a better mobile solution or find one already available off the shelf. Please note we have recently also heard of an HTML 5 solution called Mobile Entree, which seems better as a soluton since sharePlus is a native iPad app and we would have to train our users on our SharePoint backend List Data Model. With an HTML5 solution we would retain the web app's user experience to some extent. We have not evaluated this solution at the time of writing this blog.