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