In the case of FileNet P8 these two scenarios are often the same. For p8 when you checkin a document the PWC becomes (or gets promoted) to the new version. This means that the ID of the PWC and the ID of the new version are identical. (Not sure if inMemory also does this)
So the p8 specific rules (because of this implementation detail) is that whatever you checkin (both bindings) you will get back an id that is the same as the (former) PWC. It is just not a PWC anymore, but now is the latest version. Jay Brown Senior Engineer, ECM Development IBM Software Group [email protected] From: Tim Webster <[email protected]> To: [email protected], Date: 04/11/2013 04:46 AM Subject: Returned ObjectId on check in (WS vs. AtomPub) Hi All, I've noticed that the ObjectId returned from a check-in operation is different depending on the binding type used. If atompub is used, the check in operation will always return the the 'new' objectId (i.e. the object ID of the new version that is being created by the check in). If webservices is used, the check in operation will always return the objectId of the Document that is being checked in. I've tested both scenarios using the following inputs as the document to check in: - v1.0 of the document - latest major version of the document - PWC of the document I initially thought this might be a bug in the CMIS repository implementation I'm using (IBM FileNet P8), as the Chemistry client code seems to just return what is returned from the server. However the same behavior exists in OpenCMIS InMemory Server as well. It would be odd if this was a bug AND showing up in two different implementations. I couldn't see anything in the spec regarding this, so am now wondering if I've missed something or if in fact this is a problem with the Chemistry client somehow. Any thoughts? Thanks, Tim
