How to set category attributes for specific node using OScript API/Built-in Package. ver. 10.5

Hello all

I need to set value to category attribute in specific node. As far as I know LLAPI is depricated after 10.0 and it is not recomendet to use. In OScript API/Built-in Package documentation I cant find anything useful to implement my task.

I tryed somethig like thise

Integer cardID = 7056217
DAPINODE node = DAPI.getNodeByID(prgCtx.DSession().fSession,cardID)

Dynamic attr = DAPI.GetNodeUserAttr(node, "_1_1_22_1")

but in attr variable I have value E681967618 and The item user attribute is invalid.

Any Ideas?

Find more posts tagged with

Comments

Appu Nair

LLIAPI Packages Objects are what we use in Oscript not the too low DAPI things.Thats what they teach at class.I recently wrote this to show

someone how it is done

https://knowledge.opentext.com/knowledge/cs.dll/63899706/How_to_add_Categories_to_a_Node.docx?func=doc.Fetch&nodeid=63899706

If you search you should get plenty of snippets with category stuff

in this folder perhaps you will find other Oscript tidbits that may be useful as well.

PavelEvdokimov

Appu, thanks for your reply, and for your blog!

I have no permisions to llink you gave me https://knowledge.opentext.com/knowledge/cs.dll/63899706/How_to_add_Categories_to_a_Node.docx?func=doc.Fetch&nodeid=63899706. It sad, because I realy interesting in this material... Can I find it in your blog? Or somewhere?

I tried to search here about my question, but nothing useful got. Maybe I bad searcher...

Now I have better understending about how to do my task. Please tell me if I wrong.

I was confused about LAPI, DAPI, LLIAPI. Now I understand LAPI - is depricated after 10.0 (or used for backward compatibility), DAPI - basic OScript functions (low level), LLIAPI - wrapper on DAPI for develop business logic in OScript. Am I right?

Now my code is works fine

// Object to work with attributes and categories
FRAME attrDataObj
// Specific node
Integer cardID = 7056217
Dynamic someThing
// Get new object for specific node
attrDataObj = $LLIApi.AttrData.New( prgCtx, cardID, 0 )
// Get data from DB
someThing = attrDataObj.DBGet( FALSE, TRUE )
// Change string attribute
attrDataObj.fData.{519226,24}.Values[1].(22).Values[1] = "New value"
// Save data to DB
attrDataObj.DBPut( FALSE )

Is it correct way to do it?

Thanks

John Simon

Pavel,

You can do it that way, and indeed many of us do. However you can also do this at the LLIAPI (or LLNode) level. Assuming you have already retrieved the node:

LLNode = $LLIAPI.LLNodeSubsystem.GetItem( node.pSubtype )
result = LLNode.NodeCategoriesGet( node )
if ( result.ok )
attrData = result.attrData
// make your changes to attrData
result = LLNode.NodeCategoriesUpdate( node, attrData )
end

The benefit to this way is: 1) Callbacks are run for you, 2) Auditing is done for you, 3) honors the setting for not changing the modified date when categories are updated.

Cheers...

Appu Nair

One can never match John's way of clearly explaining things(He is an University trust me:)

@Pavel I have given access to the link as well as the folder inside you

https://knowledge.opentext.com/knowledge/cs.dll?func=ll&objId=63636347&objAction=browse Inside the folder you should see a utility script https://knowledge.opentext.com/knowledge/cs.dll/63900718/SetCategoryAttributeOscript.txt?func=doc.Fetch&nodeid=63900718 if you put your mind to understand what John said where he says this // make your changes to attrData

that is what you will find in my script, the attrData structure parsing was what is found in most OT code,even used to exist as an easy to understand document somehere here in the forum even though nowadays I think I have seen better and faster approaches.

What one would need to almost understand is

Once you have a Node ,Node’s metadata is stored in the Attribute Groups (Read this as Multiple Categories applied).Each Attribute Group relies on a structure(Cat Version ) and default values

attrDataObj.fData.{519226,24}.Values[1].(22).Values[1] = "New value" your code like that I understand as

a Category Object (subtype 131) has a DataID of 519226 and version 24 and AttrID(22) with a single value of “New Value”

if you do ?func=attributes.dump OT has a Request Handler that shows you the same info. Also when you program you need to understand that OT Attribute Values are or can be more than 1 .

Chris Meyer

*.kc { font-family: Helvetica , arial , sans-serif; font-size: 16.0px; line-height: 1.6; background-color: rgb(255,255,255);}*.kc a { color: rgb(65,131,196);}*.kc a.absent { color: rgb(204,0,0);}*.kc a.anchor { display: block; padding-left: 30.0px; cursor: pointer; top: 0; left: 0; bottom: 0;}*.kc h1, *.kc h2, *.kc h3, *.kc h4, *.kc h5, *.kc h6 { margin: 20.0px 0 10.0px; padding: 0; font-weight: 700;}cursor:text {}position:relative {}*.kc h1:hover a.anchor, *.kc h2:hover a.anchor, *.kc h3:hover a.anchor, *.kc h4:hover a.anchor, *.kc h5:hover a.anchor, *.kc h6:hover a.anchor { text-decoration: none;}*.kc h1 code, *.kc h1 tt { font-size: inherit;}*.kc h2 code, *.kc h2 tt { font-size: inherit;}*.kc h3 code, *.kc h3 tt { font-size: inherit;}*.kc h4 code, *.kc h4 tt { font-size: inherit;}*.kc h5 code, *.kc h5 tt { font-size: inherit;}*.kc h6 code, *.kc h6 tt { font-size: inherit;}*.kc h1 { font-size: 28.0px; color: rgb(0,0,0);}*.kc h2 { font-size: 24.0px; border-bottom: 1.0px solid rgb(204,204,204); color: rgb(0,0,0);}*.kc h3 { font-size: 20.0px;}*.kc h4 { font-size: 18.0px;}*.kc h5 { font-size: 16.0px;}*.kc h6 { color: rgb(119,119,119); font-size: 16.0px;}*.kc blockquote, *.kc dl, *.kc li, *.kc ol, *.kc p, *.kc pre, *.kc table, *.kc ul { margin: 15.0px 0;}*.kc hr { border: 0 none; color: rgb(204,204,204); height: 4.0px; padding: 0;}*.kc body > h2:first-child { margin-top: 0; padding-top: 0;}*.kc body > h1:first-child { margin-top: 0; padding-top: 0;}*.kc body > h1:first-child + h2 { margin-top: 0; padding-top: 0;}*.kc body > h3:first-child, *.kc body > h4:first-child, *.kc body > h5:first-child, *.kc body > h6:first-child { margin-top: 0; padding-top: 0;}*.kc a:first-child h1, *.kc a:first-child h2, *.kc a:first-child h3, *.kc a:first-child h4, *.kc a:first-child h5, *.kc a:first-child h6 { margin-top: 0; padding-top: 0;}*.kc h1 p, *.kc h2 p, *.kc h3 p, *.kc h4 p, *.kc h5 p, *.kc h6 p { margin-top: 0;}*.kc li p.first {}*.kc li { margin: 0;}*.kc ol, *.kc ul { padding-left: 30.0px;}*.kc ol *:first-child, *.kc ul *:first-child { margin-top: 0;}*.kc dl { padding: 0;}*.kc dl dt { font-size: 16.0px; font-weight: 700; font-style: italic; padding: 0; margin: 15.0px 0 5.0px;}*.kc dl dt:first-child { padding: 0;}*.kc dl dt > *:first-child { margin-top: 0;}*.kc dl dt > *:last-child { margin-bottom: 0;}*.kc dl dd { margin: 0 0 15.0px; padding: 0 15.0px;}*.kc dl dd > *:first-child { margin-top: 0;}*.kc dl dd > *:last-child { margin-bottom: 0;}*.kc blockquote { border-left: 4.0px solid rgb(221,221,221); padding: 0 15.0px; color: rgb(119,119,119);}*.kc blockquote > *:first-child { margin-top: 0;}*.kc blockquote > *:last-child { margin-bottom: 0;}*.kc table { padding: 0; border-collapse: collapse;}*.kc table tr { border-top: 1.0px solid rgb(204,204,204); background-color: rgb(255,255,255); margin: 0; padding: 0;}

I do a lot of work with category and attributes from within OScript. As John pointed out, you want to do the fetch and save via LLNode in order for the appropriate callbacks and auditing to take place. Let me add a few comments:

2) Auditing is done for you

You don't get this for free. Audit entries for individual attribute updates only takes place if the .fValueChanges feature is updated in parallel with the data in .fData. Why this isn't automatic is a mystery to me.

// make your changes to attrData

This is probably the most confusing and misunderstood part of developing with $LLIApi.AttrData. Too often I see developers traverse and manipulate .fData directly, which can lead to data corruption if the code doesn't align with the category definition. This means having to hardcode assumptions about the category structure within a module.

You also don't want to hardcode DataIDs, version IDs, or attribute IDs since it makes it impossible to install on different systems. This means some type of configuration, which is another task in itself.

What I don't understand is why $LLIApi.AttrData doesn't have simple methods to abstract the setting and getting of data on a category. Methods exist, but they are error prone, difficult to use, and can corrupt your data if used incorrectly.

A few years ago I wrote some extensions to $LLIApi.AttrData to get around many of these problems. You can read about it in this blog post. Hopefully this provides additional context to the problem and gives additional thoughts on what you need to look out for.

John Simon

Chris,

Quoted Chris Meyer on 12/07/2017 08:57 AM:

We recently figured out a "simple?!?" way to populate .fValueChanges but it is not obvious and of course I can never remember where we have an example. I tracked it down this morning...

           // populate attrData.fValueChanges to enable auditing
           $LLIAPI.AttrUtil.GenerateAttrChangeEvents(
               attrData,
               attrData.fData.( categoryKey ),
               attrData.fDefinitions.( categoryKey ) )
           retVal = LLNode.NodeCategoriesUpdate( node, attrData )

Also I couldn't agree more with your comment about why isn't this automatic.

Cheers...

Chris Meyer

Hi John: I don't think this function suffices. If you update values in attrData (directly or via ValueSet()) you won't see the old values stored anywhere. It's therefore not possible to check whether a value has changed in order to appropriately populate .fValueChanges.

Digging deeper into $LLIAPI.AttrUtil.GenerateAttrChangeEvents you'll find the following logic for populating .fValueChanges:

change = { Str.Format( "%1.%2[%3]", displayPath, anAttrDef.DisplayName, j ) , Undefined, values[ j ] }if ( change[ 2 ] != change[ 3 ] )    RecArray.AddRecord( attrData.fValueChanges, change )end

The value of change[ 2 ] is always Undefined, which means the function will always generate audit entries for any attribute value that is not Undefined. The function doesn't seem very helpful.

Also I couldn't agree more with your comment about why isn't this automatic.

It's unfortunate since populating .fValueChanges isn't trivial. The Key column is used to populate the ValueKey column in DAuditNew. It has the following syntax depending if the attribute is within a set:

CategoryName[1].AttributeName[AttrIndex]

or:

CategoryName[1].SetName[SetIndex].AttributeName[AttrIndex]

This is highly error-prone if developers are expected to manually generate the key whenever an attribute value is updated. The REST API is a good example of this: It use the first syntax regardless if the attribute is within a set, which makes the audit entry incorrect and ambiguous when updating multi-valued sets.

Kyle_Swidrovich

As an FYI, Content Server 16.2.4 will have a new function called GenerateAttrChangeEventsDiff() that compares the new values to the old values so the actual changes are obtained -- not just recording new values.