Testing D2 development and REST services

After the summer, I’ve found myself with some spare time between projects that I’ve used to review some EMC products:

  • D2 4.1

Over the years, we’ve developed a webtop based solution that includes several custom developed components like import from external source, TBO’s/SBO’s used to name documents/folders, etc.

So after attending several D2 demos, we decided to do exactly the same with D2 (or at least get as close as possible) as a testing project.

Custom naming/default object creation was the easiest part, as the autonaming and autolink features are functional enough to cover our needs.

Import from external source looked like it was going to be tough, as we couldn’t touch the default import, and the development documentation is… lacking. So after a little investigation thorugh the available documentation and the community, we decided to go with the external widget approach and it was quite easy actually: Take our custom applet from webtop, put it on a jsp and communicate with the D2 import component sending the files… no problem at all

Some other functionality that involved modifying default D2 behavior required to developed plugins, but after reviewing the API and the available examples we decided not even trying because currently is a waste of time trying to figure which method/libs you need.

  • Good: external widgtes are extremely easy to develop, and there is enough documentation to be able to communicate those widgets with D2 without killing yourself in the process.
  • Bad: plugins are useless as there’s no reliable documentation available, and it seems the API could change in future versions, making useless old plugins.

To sum up, I think D2 4.1 is more a beta/unfinished product (which it really is, as EMC is doing everything from scratch to made it compatible with browsers other than IE, and currently is missing features that were on previous versions). I’ve heard that D2 4.2 is a more mature product and that effors have been made regarding development documentation. If EMC wants to “kill” wdk application with D2 and xCP2 they better give us enough tools to do our customizations, as by now we all should realize that the idea of “configure only” is cool, but is far from our daily work…

  • REST Services:

I’ve been developeing different solutions with DFS (extra layers to the services, custom clients both in JAVA and .NET, bulk load applications, etc) since version 6.0. Afterwards I migrated everything that could be done with the CMIS standard to CMIS with Apache Chemistry; so it was clear the next step was trying the new REST services.

Before the summer I started developing an Android application with the REST preview just as a proof of concept (and as a way to learn how android applications work), and it worked quite well. Last week I’ve been updating the application using the REST 7.0 services (finally we have a working query service!!!) and cleaning/improving the android application that has now become an administrator tool that lets you check repository status, browse the repository, open files, check job status, etc.

I hope to keep improving the application and I hope EMC keeps the REST services, as there is way easier to develop with these REST services than using the monstruosity that DFS are. However, if CMIS meets your requirements, I still go that way, as it is a standard…

 

 

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s

This site uses Akismet to reduce spam. Learn how your comment data is processed.