Monday, June 24, 2013

Inconvenient Import-SPWeb with Sandboxed Solutions

In current project we deliver an initial SharePoint site-collection as white-label site. The aim is we utilize the initial site as template for concrete label websites. Challenge is how to duplicate the white-label site collection into a concrete label site. Backup-SPSite plus Restore-SPSite is an option, but requires that you restore each copy to its own content database. Reason is that Restore-SPSite preserves the siteid from the original / backed-up site, and this conflicts with the white-label site (and any other restored site) in same content database.
Second option is to restore the site collection structure via combination of Export-SPWeb plus Import-SPWeb. Approach is to export the root web plus all its recursive sub webs; and import them in a fresh created empty site collection.
When doing this, the import job halted with error:
Inspecting the Import log revealed that it concerned a SPList based on ListTemplate provisioned via feature in a Sandboxed solution. And this results in a sequencing issue: the list is first to be created in the copy site, before the sandboxed solution is also added plus activated within the copy site.
Solution is to upload and activate the Sandboxed solution within the fresh copy site collection, before running the Import-SPWeb.
Note that default you cannot download solutions from the solution gallery of the white-label site collection. But you can fix that by adding a view to the solution gallery with includes ‘Name’ as view column.

Friday, June 21, 2013

SharePoint - best all-rounder for the employee workplace

This posting is a translation from earlier Dutch publication on The Next Thought blog.
In this era in which our (work)life is more and more influenced by the capability to access the enterprise knowledge and functionalities, optimum support in the execution of our work is of essential importance. We need to focus on the aspects that really matter and not be bothered with the administrative burdens that the business proccesses and IT can bring. We all know it. Handling the daily and the ad hoc tasks often takes too much time. Our work productivity is killed by the diversity in how to access the various sources of information, and by the diversity in how to perform and complete our tasks.
This is a challenge that was promised to be resolved by portal technology. One shell around your processes and applications, that improves the access and uniformity in all its facets. For a decade we hear that portal technology makes this possible, but the reality appears more stubborn.
Granted, it is also a difficult problem to solve. On the one hand, once ultimately a portal technology is choosen, the organization must conform to the utilization of that technology and how it is deployed onto the employees. And that [governance] is no small thing.

Sufficient functionality?

Another issue is whether the selected portal technology is rich enough to support the various aspects of the integrated employee workplace: information sharing, locate information and people, work collaboration, process, task management, integration with other systems, information dashboards, and more. A multitude of functional requirements, supplemented with the Enterprise Architecture requirement that it is simply to align all the different systems already included in the enterprise architecture.
In the last decade SharePoint has established a prominent position in the market of portal technology. Gartner consistently grades SharePoint as [the] leader in the field of Horizontal Portals.
And rightly so. The integration of SharePoint with Microsoft Office products, plus the broad functionality and integration capabilities that SharePoint provides, makes it a very good all-rounder. A platform that provides virtually every need of the information worker.
As of release 2010, the SharePoint platform complemented by the ecosystem, includes adequate support for all recurring aspects for the integrated employee workplace. The key word here is 'sufficient': SharePoint provides certainly not for every single aspect the most advanced and complete solution, but for most scenarios the platform offers sufficient support.
An example is the field of Business Process Management: SharePoint workflow is not a world-class BPM suite, when we compare it with SAP or Tibco BPM; it does not intend that to be. But through SharePoint workflow, possibly supplemented with Nintex Workflow or K2, it is possible to achieve a "lightweight BPM" solution. For the average desired application often a much more cost-effective solution, that can immediately be deployed from the available SharePoint platform within [a] company.
The same applies to the 'social' components of SharePoint. The platform itself out-of-the-box delivers the minimal expected 'social' support: microblogging / status updates, follow, like, tagging etc. Whenever the 'social' needs of an organization go beyond these, then there are additional products in the SharePoint ecosystem (eg NewsGator) to go a step further on ‘social’ front.
And that applies to all SharePoint features: document handling, archiving, BI dashboards, enterprise search, collaboration: the product itself includes direct deployable enterprise functionality. And as a portal platform it is functionally expandable through standard products available on the market.

Monday, June 17, 2013

Architecture of a cloud-enabled SAP/SharePoint document viewer

End 2012 IntelliDocx LLC approached us to design the global architecture for their new DocSet.ECM for SAP and SharePoint product suite, and build DocSet.ECM for Plant Maintenance (PM) as first member. The DocSet.ECM functionality is enable end-users to search, navigate and access documents linked with SAP entities, directly within SharePoint based workplaces. The SAP entities come from any of the known SAP Business Suites - PM, Sales, HCM, SRM. IntelliDocx had an ambitieus deadline, as they aimed to release the PM solution to the public and market analysts at the European SharePoint Conference in Copenhague (Februari 2013).
The base functional requirement for the product suite is that it renders a view in SharePoint on documents linked in SAP. But to make it a winning solution, they have more requirements. The products must be very user-intuitive and friendly; enabling arbitrair end-users to utilize it without requiring inside SAP knowledge. Product deployment must be fit for both on-premise as cloud. More and more organizations nowadays have decided, or are looking into, SharePoint Online utilization iso maintaining an own on-premise SharePoint farm. And of course, the product should support both SharePoint 2010 and 2013; or at least be prepared for 2013 ahead.

System Architecture

The diagram below illustrates the architecture we proposed to address the requirement set. (And which we indeed applied to successfully deliver the DocSet.ECM for PM product to market, within the tight timeframe [News release]).

Essentials

DocSet Viewer
  • Deployed via Sandboxed Solution
  • UserControl iso aspx page
    • allows to add the DocSet viewer to regular SharePoint site and content pages / intuïtieve integration within customer’s SharePoint based portals
  • Server-side only rendering the html
    • No server postback handling
    • No interactive dependency on SharePoint server (may be cloud-hosting)
  • Client-side handles communication with the DocSet webservice, and dynamic UI-rendering
    • By-pass SharePoint server
    • Use jQuery:
      • Invoke DocSet JSON webservice
      • Render tree-view of hierarchical document folders
      • Drag-and-drop of documents (for Move + Add)
  • Configuration:
    • Endpoint of DocSet webservice (may be cross-domain)
DocSet webservice
  • WCF JSON webservice
  • Enable CrossDomain invocation via JSONP
    • CORS is not yet widely supported; and in particular not within the enterprise domain
  • Utilize ERP-Link RFC Connector for SAP / Microsoft.NET interoperability with DocSet.ECM RFCs
    • The architecture allows usage of other SAP / Microsoft connectors, e.g. Duet Enterprise, but we decided to initially use the ERP-Link connector as IntelliDocx told us a lot of their customers already use the Gimmal ERP-Link Suite.
  • Configuration:
    • Connection settings to DocSet RFC
    • Address of SharePoint server hosting the DocSet viewer, to allow cross-site requests from this possible remote / other domain server

DocSetViewer App - SharePoint 2010 + 2013

The DocSet.ECM for SAP and SharePoint product suite is fit to deploy and run within both SharePoint 2010 and 2013, without any code-change; and hosting supported on-premise and within the Office365 cloud.
  
Related info: IntelliDocx

Sunday, May 26, 2013

Tip: Use Productivity Tool to setup code structure for Open XML generation

A customer requirement is the ability to offline manage business data within a downloaded excel sheet, and upload for processing into the business administration. Strong demand is that the input and actions in the excel sheet must be user-prescribtive as well as restricting. Microsoft Excel supports this via capabilities as input cell validation, cell format, protecting sheets and so on. We provided our customer with an example Excel 2010 sheet as functional specification. After we reached agreement on the Excel sheet behaviour, next step is to realize the runtime Excel sheet generation, and bind it to the user-selected data retrieved from the business administration.
The Open XML SDK can be used for server-based Excel sheet generation. A problem however is that (usage of the) the Open XML API / language is not very well documented. Setting up the generation of a simple Excel sheet is not a problem [as there are also sufficient code examples online]. But when it comes to including capabilities like data validation, the situation changes. The Open XML generation is very fragile, and you easily end up with an incorrect Open XML structure. Due the badly documented Open XML API, fixing the programmatically generation is a frustrating and time-consuming task.
In case of a complexer Excel sheet, a better approach is to utilize Open XML Productivity Tool. Just open the Excel sheet in this tool, and then export the Open XML code generation for the imported sheet. Mind you, typically you will want to refactor the generated code to improve on its maintainability. Also in our example we bind it to the data retrieved from the business administration.

Saturday, March 30, 2013

No silver bullet for multilingual SharePoint websites

In 2007 I wrote an advice on how-to deliver multilingual user experience in a SharePoint 2007 based public facing website. Althought the SharePoint Variations concept promised to fulfill this need, our experiences turned out differently. As result my advice was that we better just made a localized copy of the website per language.
This month I repeated the analysis on multilingual solution directions for SharePoint websites; now for SharePoint 2010 (and looking forward to SharePoint 2013). Sadly, the findings have not really improved compared to the 2007 support.

Aspects of multilingual in SharePoint sites

The information architecture of SharePoint based websites differs considerable from plain asp.net, php websites. SharePoint artifacts are typically administrated within the SharePoint content database, instead of physical files on the webserver. The SharePoint platform is also very rich with out-of-the-box capabilities and components that are used to construct a website. And for public facing websites it enables content managers to logical extend the websites with new content and composition pages.
In a SharePoint website the text displayed can come from any of the following places:
  1. Contained within physical .aspx and .ascx files in the layouts folder; typically via asp.net Resources mechanism
  2. Contained within code of SharePoint controls: standard and custom
  3. SharePoint content database
On deeper level, the following multilingual aspects can be distinguished in SharePoint public facing websites
  1. Multilingual of the SharePoint standard UI (MUI: Multilingual User Interface)
    • menu’s
    • list and libraries column names
  2. Multilingual of custom developed SharePoint components
  3. Multilingual of the SharePoint content
    • Publishing pages content
    • Static html in Masterpages, PageLayouts and SitePages
    • List and libraries items
    • Localized images
  4. Multilingual of SharePoint navigation: Global, Current, Mega-menu
  5. Multilingual of SharePoint search-discovery items: website title, friendly-urls

Solution directions

Manual website-copy per language

This is the most basic and also most flexibel approach. But it also implies that all multilingual aspects must be performed manual and repeated per language website-copy: at moment of the initial website provisioning, and later for each change to its information architecture and content. The latter also beholds a risk: site content manager forgets to propagate a change on the source site to one or more of the language copy-sites.

Site-copy per language via SharePoint Variations

Variations is an out-of-the-box capability of the SharePoint platform since 2007 version. The concept is that you declare one site in your sitecollection as the Variation root, and create + declare sites for other languages as so-called Label sites. Each change to site structure and publishing pages in the Variation root is propagated as draft to all Label sites. Per Label site, the content manager must next translate the propagated page(s), and publish them. Visitors do not see the content as it is propagated from the root site.
The most important limation of Variations is that it does not cover all the multilingual aspects. It only applies to publishing page content. SharePoint list and libraries are not in scope, and still need to be handled manual.
Another major limitation is that Variations cannot be applied as an afterthought to an already existing SharePoint site. It must be applied at start of provisioning the information architecture of the source SharePoint site.
In SharePoint 2007, the Variations functionality suffers from multiple issues that in general gave it a bad press; and there are very limited organizations that actually (trust to) apply it. In SharePoint 2010 the robustness of Variations behaviour should be a bit improved; but there are still only limited known practisioners in real world. Also noteworthy is that the STSADM VariationsFixUpTool is reported by Microsoft self to be still needed for fixing corruption in Variations Relationships list.

Multilingual in-place in the SharePoint site

The idea of this is that every localizable artefact (text + images) in the SharePoint site is inherent multilingual itself; and it server-side renders in the language of choice of the website visitor. Major benefit of such approach is that you avoid the need to maintain individual language site-copies consistent with each other. Most important limitation however is that it alone is not sufficent. You cannot apply this concept to out-of-the-box SharePoint menu’s, webparts and application pages, and also not without modification in SharePoint Web Content Management (Publishing Pages).

Multilingual via SharePoint Language Store

Basically a similar concept as ‘Resources’, and also somewhat comparable to the ‘in-place’ approach. Essence is that all text-parts are administrated in a Language Store that includes per text-part its translations in the multiple languages. The Language Store can be downloaded from CodePlex, however only for SharePoint 2007. It is not upgraded to SharePoint 2010. This approach has same limitations as the ‘in-place’ approach: does not work for SharePoint out-the-box ui-controls, menu’s, application pages, nor does it combine with SharePoint publishing.

Multilingual in SharePoint site via off-the-shelf products

Well, this in itself is a clear proof that multilingual is a complex matter in SharePoint context… The only 2 products found are from smaller and unknown companies (Oceanik and IceFire). Short evaluation of both propositions already demonstrates multiple shortcoming and functional-robustness issues – examples: mix language content on page, translation support not applied to standard SharePoint aspects (e.g. Reusable Content).

Conclusions

  1. SharePoint multilingual is a complex matter.
  2. Multilingual always implies extra work for SharePoint content manager → automatic text translation is yet immature to trust upon for public facing website
  3. There is no 100% automatic solution for supporting all the SharePoint multilingual aspects

Saturday, March 9, 2013

DataForm and DataView WebParts cannot display data from other site when on SitePage

DataFormWebPart is a powerful webpart to query and render data from SharePoint content sources on pages in the website. In our scenario we intend to utilize it to conditionaly display reusable content on pages. For the reusable aspect we use the standard SharePoint ‘ReusableContent’ capability. For the conditional part, we aimed to utilize the DataFormWebPart, and via ParameterBinding + Query direct it to retrieve specific ‘ReusableContent’ listitem based on a querystring parameter-value.
The ‘ReusableContent’ list is located on rootweb of the sitecollection. A mature website typically consists of a hierarchy of subsites within the sitecollection. To display through DFWP ‘reusablecontent’ in a subsite it is necessary to set it’s WebUrl parameter to ‘{sitecollectionroot}’.
To check the correct behaviour (reusable + conditional) I used SharePoint Designer to create a page in the website, add the preconfigured DFWP to it, and validate the effect in browser. It turned out that it works (reusable + conditional) when the page is created in the rootweb, but for subsites the DFWP gives an error when opening the page in browser (ULS: List Not Found). Strangely in SPD the DFWP on page in subsite can connect to the list in the rootweb, and you do not experience any problem. I was rather puzzled by this, moreover because I followed the exact directions of posts that instructed this is the way to enable DFWP on pages in subsites. Just when I was about to submit a support call to Microsoft, I decided as last attempt to create a Publishing Page (thus in browser, not possible via SPD), and add the preconfigured DFWP. And guess what; then it works!
As our scenario concerns external facing and thus publishing websites, this is sufficient. Just be aware that you cannot use the DFWP on SitePage to connect to SPList in another site.

Thursday, March 7, 2013

Duet Enterprise 2.0 Authentication flow

One of the changes in Duet Enterprise 2.0 is the Single Sign-On handling. Duet Enterprise 1.0 applies SAML to seamlessly authenticate and authorize the SharePoint authenticated user within SAP NetWeaver Gateway. For Duet Enterprise 2.0 this is no longer possible, result from the internal usage of OData for SAP - SharePoint data exchanges. The Duet Enterprise 2.0 SSO approach is X.509 based. On the Microsoft site you can find information that outlines the essential details of the authentication flow: