TSG has had two recent clients deploy Alfresco 5. After stabilizing the environments to handle the proper production load, we gathered a list of tips and tricks that have helped improve performance for Alfresco 5 around transformation and Microsoft SQL Server. For clients familar with Alfresco 4, we have found making some small changes within client configurations in Alfresco 5 can result in a substantially improved performance. The remainder of this post will serve as a suggested checklist for consideration when deploying Alfresco 5.
Last week we posted on a publishing approach for enterprise search. Along with enterprise search, we have seen more and more ECM clients look to publish content out of the ECM repository for a variety of business reasons including performance, business continuity and reducing costs. This post will highlight how Hadoop can be used within a publishing architecture and explain some of the benefits.
As we’ve mentioned in a previous blog post, we often meet with potential clients who are interested in using OpenMigrate to meet a migration need but they haven’t yet identified specific migration requirements beyond the need to move documents from one location to another. It is important to identify requirements and an overall migration strategy as early as possible as migrations provide a great opportunity to “clean up” content management systems. This “cleansing” can be through object model updates, metadata cleansing, deletion or archival of obsolete documents, or other business related decisions.
After upgrading Alfresco for one of our financial clients, we started looking at how to improve the tools and process they use to manage web content for multiple external sites. Beginning with an informal survey of how our other customers curate and publish web content it became apparent that each one handles it slightly different. This post will summarize seven different clients and how they are adding, reviewing, approving, and publishing information to the web.
When we first meet with clients who are interested in using OpenMigrate to meet a migration need, they typically know that they need to move documents from one system to another, but many times they haven’t yet identified all of the specific migration requirements. Determining and discussing this information as early as possible is helpful to minimize the migration effort and ensure that the documents are migrated in a way that makes them useable and accessible to the appropriate users.
TSG has several clients using Documentum as a repository and a custom front end application for consumption of the records or renditions of records. In most cases there is a mechanism in place such as SCS (Site Caching Services) or TSG’s OpenMigrate PUMA (See CIS Case Study for more details). While a typical Documentum application (ex: Webtop) provides a “one stop shop” for authors and approvers, the interface can be challenging when “consumers” are just looking for quick search and retrieval. This solution provides improved performance, business continuity, and ability to add documents from other systems. One potential risk to using a cache of documents and metadata for search and retrieval is the integrity of data. Publishing techniques are designed to accurately cache records; however there are uncontrollable circumstances that may result in a mismatch. Continue reading
When EMC revealed Documentum 6 a few years ago, they made a subtle—yet important—change to the way Documentum would store dates and times in the database. While most clients would never even notice the change, some of us would. In particular, when it becomes necessary to access the underlying database tables, like OpenMigrate can when preserving modification dates, confusion can be the order of the day.
OpenMigrate, TSG’s open source migration framework, supports migration to and from a number of ECM repositories, including Documentum, Alfresco, FileNet and SharePoint (and many others).
We’ve designed OpenMigrate to perform several different types of migrations:
- Between different instances of the same ECM product (e.g., during an upgrade)
- Out of one ECM technology into a “neutral zone” (usually a file system and database or text files for metadata)
- From a neutral zone into an ECM technology
- Out of one ECM technology directly into another (e.g., Documentum to Alfresco)
While the general pattern of migrating content and metadata is consistent across all of these migration types,
TSG has been continually making updates to our Alfresco Target for the OpenMigrate platform. When it comes to migrations from other repositories or a reworking of metadata and business rules, OpenMigrate has been a key platform in managing complex migrations. We’ve made a number of updates to better understand bottlenecks and performance, and to make sure that all use cases are covered in regards to migrating all attribute types, aspects, content types, folders, and versions.
Since the original Alfresco webinar last year showcasing the migration of content from SharePoint 2003 to Alfresco, we’ve has success migrating content out of a number of ECM repositories, including FileNET , Documentum, SharePoint 2007, Stellent, and of course your traditional file system. More often than not, our JDBC connector provides the primary means in which you can access the underlying content of a legacy ECM repository, extract the metadata and content, and migrate to the target repository.
We’ve also successfully migrated content into Alfresco EC2 instances. Our most recent migration included migrating over 300GB of content into an Alfresco repository in the Cloud. When moving this much content, it may make sense to utilize Amazon Web Services (AWS) Import/Export—ship a portable storage device over to Amazon to be loaded into Amazon S3. OpenMigrate can then load the content into the Alfresco repository on the cloud. FedEx will beat low bandwidth every time!
Alfresco has been great in providing suggestions and comments on how to further increase migration performance. In the coming months, we will be looking to integrate concepts from Peter Monk’s work with the Alfresco Bulk Filesystem Import.
In the content management world, users often require an “all-in-one” interface to help them assemble batches of related documents, tag them with metadata , then import them into the underlying Content Management System. Traditional web-based interfaces, such as Webtop or Web Publisher from Documentum, Explorer or Share from Alfresco, don’t offer this functionality out-of-the-box.
Could TSG’s OpenMigrate open source migration framework fit this need?
OpenMigrate is typically used in a batch mode, especially in high-volume situations. And while the browser-based Administrator does allow for interactive configuration and execution of migrations, the actual tagging of documents with metadata is outside of its realm.
To bridge this divide, TSG is pleased to announce the availability of the new OpenMigrate Bulk Load Interface for download.
The OpenMigrate Bulk Load Interface provides a highly configurable user interface which enables the user to easily manage documents and import them into a variety of targets. The interface is built on top of the Spring framework making it extremely easily maintainable, customizable, and configurable.
To learn more about this versatile new entry in the OpenMigrate toolset, please visit www.tsgrp.com.