cancel
Showing results for 
Search instead for 
Did you mean: 
cancel
Showing results for 
Search instead for 
Did you mean: 
cancel
Showing results for 
Search instead for 
Did you mean: 

Complete documentation of adapter-specific AOM interface implementions

Complete documentation of adapter-specific AOM interface implementions

I recently was confronted with an unexpected event:

The method CMSObject.getVersions() of the PTC Server adapter did not deliver the expected versions of the CMSObject but an error message :"Method not implemented".

From a project managers point of view this is a very bad situation:

Learning about unimplemented features only from error messages (“Not implemented”) while implementing customizations is far too late and leads to the impression that documented features cannot be regarded available until tested.

I do planning based on API documentation.

I actually would expect that described features of the documentation are generally available if there is no hint about being not.

The uncertainty of implemented/not implemented methods (or let’s say features) makes it impossible to keep projects time schedules.

Realistic planning software development / customization is not possible from this basis. Customization projects  depend on a actual and true API documentation. Actually it takes a lot of time to re-convince software developers to continue working with the documentation / actual state of the AOM packages after such "surprises".

I would recommend urgently to work on the Adapter Limitations online help page and the Javadoc pages to mentions adapter specific implementations / limitations ( including  missing implementations). The pure interface documentation show currently "only" the potential of some implementations.

By the way I would expect the PTC Server Adapter to be the reference implementation (and customers best choice) for the interfaces of the AOM packages rather than the weakest implementation.

3 Comments
GarethOakes
15-Moonstone

Wouldn't that be nice! Sadly this stuff is all very complex and while documentation is strong in some areas, I wouldn't necessarily stake my life on it You need to have a lot of experience with Arbortext to get the most out of it. We tend to do a lot of R&D on projects before committing to a project plan, particularly to avoid this type of situation...

From an Arbortext perspective, before acquisition the Documentum adapter was the main focus and most developed. After acquisition by PTC the focus has shifted to Windchill but functionality is lagging as you have seen. It is much better nowadays than six years ago but still some gaps.

ptc-1140188
1-Newbie

I think customiziation capabilities are a (if not the) main feature of the Arbortext plattform. The topic is certainly complex and errors can not be avoided totally. But a list of unimplemented methods could be provided easily from Arbortext development, I think. At least, more easily than testing each functions implementation by customers.

olivierlp
Community Manager
Status changed to: Archived

Hello,

We are archiving your idea as part of a general review. This action is based on the age of your idea and the total number of votes received, as per this announcement.

You can always post a new idea with all the details required in the form.

Thank you for your participation.