It is important to note that eRoom can be customized, but it is not a development platform.

If you must go from eRoom to SharePoint, try setting your eRooms to read-only and embed the items into SharePoint as little portlets. Not simple, but much easier than migrating.

Or, you could just stay with eRoom.

Can you point me at some reference materials for getting started with the XML API. I’m a Community Admin with a large number of data-rich eRooms I’d like to mine.

Thanks.

The things I found to be under-appreciated but extremely useful in SharePoint are:
- The ability to have columns look up value in other Lists provides an easy to manage environment where several different items (risks, issues, status report, change requests) can be merged into a single dashboard view.
- The ability to create calculated columns simplifies the user experience (i.e. probability * impact = risk level)
- The ability to directly link MS ACCESS, WORD, or Excel to the sharepoint data allows for user defined reports to be created and run with little hassle.

This is incredibly useful when modeling certain business programs, projects, people and process using eRoom. For instance, you may have many program areas. Each program can have multiple projects. Each project can have multiple tasks, etc. Using eRoom, I can build a database of programs with a database of projects in each program’s attachment area. Then a database of tasks within each project’s attachment area. That’s a 3 level deep embedded database. If I want more detailed reporting than eRoom an provide, I then use the XML API and Java to pull the data out of eRoom into Oracle (or MS SQL) and can do what I want with the data. Also, going in reverse, we may have an HR system in an outside database that may register a new employee. We can then use the XML api to insert a new user in eRoom and provide access to the roles, groups, rooms and items as necessary…. all programmatically. Even the initial invitation can be automated. All from being added as an employee to an outside database. No need for ADO.NET, as a prior poster complained about.

I do have a client that has a need for a portal that eRoom can’t handle and we’re looking at SharePoint and Oracle Portal (as well as others).

Again, thanks for posting your comparison.

Not trying to defend eRoom here, just want fair comparisons. Many of your points revolve around customization. My point is that eRoom is easier for the end-user to utilize immediately with minimal training. SharePoint is more advanced, and I think I’ve said that, though maybe not explicitly enough.

Also, at no point will I claim that eRoom is an ECM platform.

For future comparisons, please post something online that I can link to from my blog. The comment list is getting a tad long in the tooth.

I can add lot more features in sharepoint which eRoom does not has.

Conclusion: Sharepoint claims to be ECM platform/portal along with collaboration. We should not compare eRoom to sharepoint as eRoom is only collaboration tool.

If we compare sharepoint portal server with documentum, definitely documentum will be having big big hand.
Sharepoint need to be improved a lot to compare with documentum.
I will launch my blog post in few days with granular comparison of sharepoint services and eRoom.

That being said, a large number of companies use eRoom from day 1 with no customizations. They can create process databases with multiple steps and rejections using a wizard. eRoom also comes with a few more templates than eRoom for objects as well.

As for customization, I can do quite a bit in eRoom. eRoom does not have the same portal capabilities as SharePoint, so you can’t write a Web Part, or standardized portlet. However, I can write custom behaviors for the objects already in eRoom and customize the look and feel a great deal.

eRoom is for collaboration, remember that. SharePoint claims to be an ECM platform/portal. That I do not see out of the box. When considering Total Cost of Ownership (TCO) that is an important consideration.