SPX Series – A little bit of history

This is part of the SPX Series

Previous post: SPX Series – SharePoint eXperience – (aka SPX) – Series Introduction

First off – I want to explain that I am, in no shape or form, an SPX “expert”. I’m just a guy who has been using SPX since it was first released. I’m not a coder, so can’t tell you all the cool ways that the web parts can be tweaked, or made to dance. I am able to share with you some of the “lessons learned”, and tips . that I have picked up over time. Some of what I write might be incorrect. Please feel free to let me know if that is the case.

And, where possible, if there are other resources that explain something better than I can, I’ll point you to it.

So without further delay I will launch into today’s SPX post…”A little bit of history“.

SharePoint

In 2007 Microsoft introduced SharePoint 2007.

As well as providing the ability to store content in its own repositories (doclibs, lists), it also provided web sites that could be populated with web parts that allowed users to interact with internal content (lists and SharePoint repositories), as well as external content. This included other LOB enterprise systems (such as SAP, Siebel, etc). There was no native way to connect SharePoint and Documentum though.

Wingspan

A company called Wingspan had also developed technology that provided Web Services connectivity to Documentum.  This consists of the Docway Server, and Docway “Portlets”, (and for SharePoint – Webparts), and allowed for single sign-on,  cross-docbase browsing, as well as the ability for users to access, create & update content from a Portal.

SPX

CSC’s FirstDoc, provides a layer that sits on top of Documentum, and allows for compliance with many of the Pharmaceutical regulatory requirements imposed by the various regulatory authorities (FDA, EMA,  MHRA, etc.)

Using Wingspans technology, CSC (or, at the time, FCG), were able to create special webparts that allowed users to interact with their FirstDoc system from a SharePoint Portal. These offered about 85% percent of the functionality provided by the native FirstDoc application.

4.3

The first version was released in the 2nd half of 2007, and had the moniker “version 4.3“. This was to keep the version inline with the (then current) version of FirstDoc. It was compatiable with version 5.3 of Documentum.

There were 17 webparts available. These included webparts for browsing cabinets, listing the logged-on users checked-out documents, displaying the Home Cabinet, an inbox webpart, an very handy object-view webpart that could be configured to display one particular folder, or cabinet), an also handy query-view webpart that allowed content to be displayed based on a query, as well as an assortment of other functional webparts, and administration webparts.

Each web part offered a user the ability to further interact with an object via a context menu that showed extra functionality depending on the type of object that was clicked upon.

This first version was an excellent step towards greater flexibility in creating interfaces for users that better matched their daily work style. For the 80% of users who rarely log into FirstDoc, it provided a quick and easy way to get to specific documents. Links to specific documents could be sent via e-mail, and when a user clicked on it, the document would automatically be opened, without having to go through a process of logging into a client and searching for a document.

But there were also several shortcomings. There was the 20% of hard-core users that quickly discovered that there was still a lot of functionality that was not available. Also the SPX interface did not offer the same flexibility that WebTop did. You couldn’t easily change the columns that you wanted displayed, the search functionality when compared to the WebTop search was very limited, and the way of interacting with the documents was different. The context menu was not found in WebTop.  Performance was also a bit sluggish especially when using the webparts over a WAN.

To be fair, CSC were also restrained by the limitations of the underlying Docway technology.
(However, Wingspan have been making continual improvements to their technology and CSC have been able to take advantage of this).

5.0

CSC listened to the concerns that the hard core users (as well as the administrators) were having. Version 5.0 of SPX was released in the middle of 2008, with Product Alias Search functionality, the ability to limit search results, and also the ability to add multiple documents to a workflow. Version 5.0 was also compatible with Documentum 6.0

6.0

Then later that year, version 6.0 was released. This was based on Documentum 6.5, and an upgraded version of Docway(6.1). It had been designed to be backwards compatible (with configuration, it could work with version 4.3 of FirstDoc). This allowed SPX to work over multiple docbases of different versions. As well as this, the Inbox and Query webparts were tweaked so that values could be automatically passed on the URL. Menu selection was made configurable. A quicklink capability was added that allows a link to be configured that will launch FirstDoc functionality, and the ability to View Relationships, and Audit Trail reports was added.

6.1

Then, in the later part of 2009, version 6.1 was released with even more functionality – Virtual Documents could now be viewed, multiple files could be imported, a new :”My Views” webpart was available, as well as the ability to view the Workflow Status report. Importing related documents was now, also possible. A version 6.1.1. was also released but this was a correction to a limitation that was previously believed to be uncorrectable.

6.2

In 2010, version 6.2 and 6.2.1 were released. The only difference was that 6.2.1 was certified for use with SharePoint 2010. Both versions also used Docway 7.0.  And there was a bundle of new features and functionality. These included: the ability to register interest, the availability of the WebTop Search app as a webpart, a single-box search (“Google-like”), Saved Searches, the ability to display custom properties in the web parts, clipboard tools, subscription notifications, as well as other functionality.

Future

CSC are working on the next release of  SPX, and it looks like they’ll be adding even more functionality to close the gap between SPX and WebTop.

FirstDoc doesn’t have its own client application – it extends the functionality of the EMC Documentum native client – “WebTop”. EMC has announced that they will be phasing out this out sometime soon.  As a result CSC are dedicated to ensuring that SPX is ready to be a replacement.

So – that’s the end of my “A little bit of history” post. If have made mistakes anywhere, please feel free to let me know.

SPX Series – SharePoint eXperience – (aka SPX) – Series Introduction

This is part of the SPX Series

Hands up those of you who know what SPX is an acronym for.  (Hint – the answer is in the title of this post.)

SPX is the technology that CSC have that allows users, from a SharePoint interface, to interact with documents in a FirstDoc-Documentum system. (And, if you didn’t know – FirstDoc is a CSC’s Life Sciences compliance layer that sits on top of Documentum.) The technology consists of specially constructed web parts and a back-end Docway web server that acts as a “translator” for communication between the web parts and the Documentum server.

In fact, if you look at Andrew Chapman’s list of Reference Models, the SPX web parts would be the 3rd model listed.

Now – I have been working with SharePoint eXperience (SPX) technology for a while now – ever since the first version. I’ve been involved on a technical level as a customer. (That is, someone who has actually had to use the technology in a real-business environment to meet real-world requirements.)

As such, I thought it might be a good idea to start a series of posts on what the technology can do, along with some best practices. Here is a list of the things I will cover:

  • Overview – what SPX is, etc.
  • Best Practices – what are some of the best ways to configure/use SPX
  • Some of the issues that I have had to deal with
  • Anything else that I can think of.

Feedback from Readers is always great to receive, so if you feel that you have a question, or a suggestion, and I can answer it, I’ll certainly do my best.

Next post: SPX Series – A little bit of history

New & Classic – Ways that SharePoint & Traditional ECM systems can play together

In this post I look at some SharePoint-ECM Integration scenarios.

————————————————

The AIIM SharePoint Master course material that I am studying at the moment presents 4 scenarios about how SharePoint can be used alongside, or integrated with, traditional ECM systems.

These are:

1. External Storage Provider

In this scenario, SharePoint is used to manage indexes, metadata, user presentation, etc, and the ECM application manages content storage/retrieval

2.  External Repository of Record

In this, all content is managed in SharePoint, until it is declared a record. Then a copy is pushed into the ECM application, where it can only be accessed by Record Managers. SharePoint provides the user interface where documents are created, and edited. The ECM application handles the security, record retention, etc of the document once it has the status of a record. Content only gets into the ECM app via SharePoint.

3. Cooperative

In a cooperative scenario, all documents are created in SharePoint, where they can be edited, etc. The ECM system  is used to manage and control documents that have the status of a Record. Unlike the External Repository of Record scenario, in the Cooperative scenario, content can only exist in one system at a time.

4. Portal

In this scenario SharePoint acts merely as an interface into the ECM app. All documents are created, and managed there.

In researching this further, I came across  Andrew Chapman blog “Never Talk When You can Nod“. In it he covers the use of SharePoint with existing ECM systems a lot better in his .

Andrew offers 8 scenarios. I won’t regurgitate all of what he has written (you can read the posts yourself – see link at the end of this post), but I do want to summarise his 8 scenarios, and discuss where the AIIM scenarios match. (Andrew has got some really cool images on his post that visually represent each of the 8 possibilities beautifully. I’ll use this as well, but remember, they came from his site :-)

Andrew Chapman’s 8 Reference Architectures

——————————————————————–

1: Keep Systems Separate, Restrict Usage.

 

1: Keep Systems Separate, Restrict Usage.

Content is moved manually from SharePoint into the ECM application.

2: Loosely Coupled Solution

2: Loosely Coupled Solution

Content is moved from SharePoint into the ECM application based on some rule, or event.

3: Use SharePoint as a Portal Container

3: Use SharePoint as a Portal Container

SharePoint uses Web Parts that allow content from the ECM application to be seen, and at the same time, other Web Parts that allow the user to interact with content in SharePoint.

4: Passive Unification in Web Part

4: Passive Unification in Web Part

SharePoint contains Web Parts that allow a user to see content from both the SharePoint system, and the ECM system. This is from within the same Web Part. The user is unaware that the documents are located in separate systems.

5: Active Unification

5: Active Unification

Similar to Architecture 4 except that in this Architecture, the user is able to perform more complex operations with the content (managing versions, attaching objects to versions, etc).

6: Passive Back-end Aggregation

6: Passive Back-end Aggregation

An aggregated view of all the content stored across all libraries in created in the ECM. This aggregated view could then be used to make security decisions, perform risk analysis, monitor file usage, etc.

7: Active Back-end Aggregation

7: Active Back-end Aggregation

All content is aggregated from SharePoint into the ECM system where it is managed, and controlled.

8: Synchronized, Intelligent, 2-way Shortcutting

8: Synchronized, Intelligent, 2-way Shortcutting

As with Architecture 7, all content is transparently moved from SharePoint into the ECM system. However in this scenario, users can still act upon the document directly from SharePoint.

—————————————–

As you can see, Andrew Chapman has put a lot of thought into the various possibilities of SharePoint and tradition ECM systems working together.

Looking at what the AIIM SharePoint course material mentions, and comparing it to Andrew’s various architectures, there are close correlations – the AIIM scenarios match the first four of Andrew’s Architectures, with the last four describing variations on the Portal concept.

Andrew Chapman’s post: Eight Reference Architecture Organizer

—————————

Find out More about those Red Error Messages in Your SPX Web Part

In the Life Sciences industry, many companies use CSC’s FirstDoc to add a regulatory compliance layer to EMC‘s Documentum.

And, if you are using SharePoint as a Portal solution, CSC also offers web parts that offer 99% of the FirstDoc functionality of the thick client. These are known as SPX web parts. (SPX stands for SharePoint eXperience).

The SPX web parts are built on top of the DocWay UI component that Wingspan offers (refer my earlier post for more details).

I’ve been working with SPX pretty much since the first version, and have often seen red error messages appear in the web part. Some of these error messages are self-explanatory. Others are more cryptic.

To get more information about the error message, use your browser’s “View Source” option. In the HTML that is displayed, there is a large section giving more technical information. Using this, the actual problem can be better identified.

The Wingspan Connection – getting SharePoint & Documentum to talk to each other

This is just a short post.  Just want to show an overview of how Wingspan components  allow a user to access their Documentum documents from SharePoint.

wingspan spx sharepoint documentum firstdoc emc

Taken from Wingspan Documentation

Here you can see that there are two main components:

The DocWay UI is a collection of Web Parts installed on a SharePoint Server .

The DocWay Server comprises two components that are always installed together even though they function independently.

  • The DocWay Web Service provides Search, Content Management, and Workflow services.
  • The DocWay Content Transfer Service (DocWay Transfer Service) provides transfer of content between the user’s desktop and individual Documentum Docbases

So, basically, what happens is:

  • A user logs into their SharePoint site that contains Web Parts supplied by the DocWay UI.
  • These Web Parts display meta-data gathered by the DocWay Server about content stored in the Documentum Docbases.
  • Should the user transfer content between their local storage and a Docbase, the transfer is made by the DocWay Transfer Service, bypassing SharePoint entirely.

Included Web Parts for End Users

  • Home Cabinet
  • Subscriptions
  • Checkouts
  • Recently Accessed Files
  • Inbox
  • My Workflows
  • Virtual Folders
  • Repository Browser
  • DQL Query
  • Object View
  • Search

Included Web Parts for Administrators

  • DocWay System Administrator
  • Menu Designer
  • Component Administration
  • Web Part Group Settings

Included Web Parts for Developers

  • DocWay Diagnostics
  • AJAX Call Viewer
  • HTTP Request Inspector
  • System Information

Wingspan produce several other products that allow integration between Documentum and SharePoint. One of these is eResults that I have posted several times about in this blog (see Tag Cloud).

Related Posts