Updating Physical Object DefaultLocation and CurrrentLocation?

I seem to be misunderstanding something - I can find the getter and setter methods of PhysObjItemInfo for both DefaultLocation and CurrentLocation and they work as expected, but I can't seem to work out how update the underlying PhysicalObject with the updated PhysObjItemInfo after using the setters. I was expecting to find a method like 'updatePhysObjItemInfo(NodeID, PhysObjItemInfo)' similar to the updateNodeRight() method of DocumentManagement but no such luck.

Any hints?

Find more posts tagged with

Comments

William_Collinsworth

The release notes for physical objects in 10.5.1 mention this specifically. You update not through the physicalobjects web service but the documentmanagement one.:

https://knowledge.opentext.com/knowledge/llisapi.dll/fetch/2001/3551166/27085930/27085937/2193468/3045752/56552581/OpenText_Physical_Objects_10.5.1_Release_Notes.pdf?nodeid=56596808&vernum=-2

WebServices

New WebServices Capabilities:

It is now possible to obtain physical item attributes based on the unique id including the CS object id in WebServices.

The following Physical Item metadata can be updated using DocumentManagement method "UpdateNode" ( using corresponding parameter names):

o Default Location ("poLocation")

o Home Location ("HomeLocation")

o OffsiteStore ID ("OffsiteStorID")

o Temporary ID ("TemporaryID")

o Client Name ("Client_Name")

o Client ID ("Client_ID")

o RefRate ("RefRate")

o From Date ("poFromDate")

o To Date ("poToDate")

o Locator Type ("LocatorType")

o Keywords ("poKeywords")

o and Physical Properties of the selected Physical Item Type

Kris Boutilier

Well spotted, thanks! I'm still on 10.5.0 which would explain why I couldn't find anything.

It does beg the question though - if it's considered a 'new' feature in CWS in 10.5.1 does that mean the LAPI interface was the only way to manipulate this data before, given that LAPI is depricated in CS 10.5?

Appu_Nair1

Oscript is the language by which LAPI,CWS and now ReST API is implemented.It was always possible to use Oscript API's to change PO and RecMan functions(as well as anything else livelink offers) . I wouldn't state that LAPI was the only interface availableto a programmer.Other publically used easy to use API's is XML node instructions via the product called Object Importer.The XML is parsed byOscript and will do what it is supposed to do.To a large extent companies who do not wish to program in lapi or oscript rely on the power of webreports(which again is oscript under the covers)

Other serious deficiencies in other language programming is Oscript offers what is termed "callbacks" which are basicaly subscribing to things happening in livelink so one is able to process "event of interest" very cleanly and very efficiently.You can see a lot of practical applications in workflow processing and other node activities.

Just thought of saying this because LAPI wasn't the only avenue for programming since I used to do lapi as well as socript.

Kris Boutilier

Hi Appu, thanks for your input.

Quoted Appu Nair on 07/02/2015 11:39 AM:

As I've learned more about the environment I've come to understand Oscript as the proprietary interpreted programming language that the APIs are built on top of, but that it's not an API itself (except in the most abstract sense). Yes, I can encode business logic in Oscript patches and bake it in as customizations to the product, or construct custom extentions to the existing APIs using Oscript to expose addtional/missing functionality, but without an SDK license Oscript is not accessible (and **** up in Oscript can prevent the system from operating as I'm frequently reminded). LAPI/SOAP/REST are all exposed for interacting with CS from elsewhere, rather than customizing the product, so they maintain a clean boundary (CS itself will always run correctly, even if the external logic stops working).

Certainly Object Importer can be used to automate large tasks by generating job control files, but that tools seems to be targeted in a different direction than I've been looking for. I'm not really considering it an API, rather just an 'automation engine' - that's to say: export metadata in bulk, manipulate it with some other tool(s), then re-import the updated metadata. In theory OI would be an external tool that utilizes the same complete suite of API calls that everyone has access to, but I've read in various places that's not how it's designed (thus the need to implement it as Oscript module).

Quoted Appu Nair on 07/02/2015 11:39 AM:

Yes, access to syncronous callbacks are definitely the key advantage of implementing business logic as Oscript customizations - and if you need to implement hard constraints then that probably makes it worth the effort to licence the SDK and maintain a customized Content Server. In my case I can accept using asyncronous/post-event business logic for now so staying out of the Oscript arena is worthwhile. To achive this I've been experiementing with feeding Apache Camel with events taken from the DAuditNew table as they're being inserted, and taking actions on only the events of interest.

The situation that lead to my original question was is a validation check - if a physical item has been assigned into a physical item container then, when the assignment operation is complete, does the location of the item that was assigned match the location of the container? eg. if a Physical Folder was assigned to a Physical Box and the user did not tick the option in the web interface to update the child object location then the Folder location is no longer valid in our environment. It's easy enough to detect the condition and draw someones attention to it so they can go update it by hand, but it should be equally easy to just reach it and correct it after the fact through an API call - committing that update back to the database is where I stumbled (... and yes, a quick Oscript/Weblingo patch to entirely remove the option from the web page and default it to 'always inherit location' would be ideal, but that strays into the realm of customization again).

edit: **** keyboard...