Highlighted
Acclaimed Contributor.
Acclaimed Contributor.
684 views

Count of attachments for device table

Hello.

I made next functional.

Concept: When operator add/remove attachment to device table (into CI) then put amount of attachments into field in device table (attach.count)

Implementation:

1) triggers for SYSATTACHMENTS table: "before add" and  "before delete"

if (record.application == "device" && record.segment==0)
{
lib.HPCinteroperabilityHelpers.scheduleActionWithName(record.topic+" - MOS.DEVICE.CALC.ATTACH", record, "MOS.DEVICE.CALC.ATTACH")
}

 2) Shcedule wich create shcedule record wich start ioaction

3) ioaction:

var TargetTable="device";
var TargetField="logical.name";
var AttachTopicVal=vars.$L_file.topic;
var result=lib.HPCMOSLinkedRecords.CalcAttach(TargetTable,TargetField,AttachTopicVal);
if ( result == false)
{
var returnCode = system.library.HPCinteroperabilityHelpers.rescheduleActionWithName(AttachTopicVal+" - MOS.DEVICE.CALC.ATTACH",vars.$L_file, "MOS.DEVICE.CALC.ATTACH");
}

4) Script library (wich called from 3) ) calculate amount of attachments and save it to device table and then transfer result of "save" to 3) (true or false)

And there is a problem.

When i add attahment for device table all works fine, but if i delete attachment from device the new value does not appear.

(see attachments - real extension TXT)

Tags (1)
0 Likes
9 Replies
Highlighted
Acclaimed Contributor.. Acclaimed Contributor..
Acclaimed Contributor..

Re: Count of attachments for device table

First, what version of HPSM are you on?

Second, that seems to be a roundabout way of doing it.  Adding a schedule record to come back around and modify a CI record...

Are you adding the attachment from the device record itself?  Like, if you're on the CI record, you select Add Attachment?  If so, then you can simply do a formatctrl query to get an on-display count.  Or we use this code in the device formatctrl initialization expressions:

$L.void=rtecall("rinit", $L.rc, $L.attachment, "SYSATTACHMENTS");$L.void=rtecall("count", $L.rc, $L.attachment, "topic=\""+logical.name in $file+"\" and segment = 0", $countAttachment)

If you're looking to save the value, you can change the $countAttachment variable to whatever field you want to populate in the record instead...

(FYI: I am having issues opening your attachment.  Not sure if it's me or the site or the attachments themselves)

Highlighted
Acclaimed Contributor.
Acclaimed Contributor.

Re: Count of attachments for device table

1) SM 9.30

2) $L.void=rtec.... this function just to calculate value - but problem is to save this result to device table while its opened.

Operator open CI and enter to Attachments tab and then add or remove files from here. (So this action of operator just add new record or delete existing from SYSATTACHMENTS table)

3) To open my attachments just save it and change extension to txt (this forum allow attach only picture extensions)

0 Likes
Highlighted
Acclaimed Contributor.. Acclaimed Contributor..
Acclaimed Contributor..

Re: Count of attachments for device table

You can save it to the record by specifying a field instead of the variable.

The rtecalls initialize the SYSATTACH table and then query the SYSATTACH table.  What you do with the result is completely up to you.  If you want the count saved to a field (for example, some field called 'attach.count' then change the last part of the expression from '$countAttachment' to 'attach.count in $file'

I'm not understanding why you're putting it on the schedule table.  It seems you're making it harder than it needs to be.

But, that being said, looking at your script, the delete isn't working because your trigger is a pre-delete trigger.  When your script is called, the records still exist in the SYSATTACH table.  Change that from a pre-delete to a post-delete and see if that helps.

0 Likes
Highlighted
Acclaimed Contributor.
Acclaimed Contributor.

Re: Count of attachments for device table

Because it is impossible to store the value in a table that is opened (blocked) by the user.

Thats why there is the scheduler wich runs ioaction, and  ioaction try to save this value again and if failed once again (the record was again busy), then be re-created this same scheduler to try save it again.

0 Likes
Highlighted
Acclaimed Contributor.. Acclaimed Contributor..
Acclaimed Contributor..

Re: Count of attachments for device table

But it's the user who is saving the record.  The record is locked, but it's locked by the user who will be saving the value...

Look, everything on the formatctrl record triggers when the user views the record.  Using the code snippet I provided, here's how it will work.

User goes into a CI record.  The Intialization Expressions run and the system gets a count of attachements and populates it into the field.  (In your case, you're calling it something like mos.count.attach or whatever).  So the value of mos.count.attach in $L.file when the user views the record is the value of the number of attachments for that device.  When the user saves the record to save the attachments, the system runs the expression and populates the field.

You don't have to do it this way - your schedule record, once you move it to a post-delete instead of a pre-delete - should be fine.

0 Likes
Highlighted
Acclaimed Contributor.
Acclaimed Contributor.

Re: Count of attachments for device table

There are options:

1) The Intialization Expressions (FC for device) run and the system gets a count of attachements and populates it into the field.

this method is not suitable for me, as the number must be specified in all CI (to make a view with count column to export it)

2) put your code in FC of device table in Calculations tab for ADD and UPDATE 

Any UPDATE/ADD will start calculation the number of attachments, it is better if such a calculation will only be in the event of a change in the number of attachments

3) Put this calculation in FC for SYSATTACHMENTS table for ADD\DELETE.

This is the perfect option.

How to write this code, if use it from FC for SYSATTACHMENTS but save value to DEVICE table ?

0 Likes
Highlighted
Acclaimed Contributor.. Acclaimed Contributor..
Acclaimed Contributor..

Re: Count of attachments for device table

1) Since this triggerrs when the record saves, this WILL show up in your record list, assuming you're populating a field and not a variable.  You may need to do a Mass Update the first time to populate the value for the records that already have attachments, but, once the code is in, it will trigger whenever the record displays, and store whenever the record saves, so you'll get this value into your list.  (I'm not sure why this is unclear to you...)

2) You're right, that putting this in the initialization expressions, or the add/update condition will perform this update whenever the record is saved.  However, you're performing a keyed query against the table, so the impact to the system will be negligable.  There will be no noticable performance hit, unless you have a record with thousands of attachments on the same record.

3) The formatctrl record does not trigger unless you're looking at a record using that form.  If you put code in the SYSATTACHMENTS formatctrl, that code will never trigger unless someone is looking at a record in the SYSATTACHMENTS table using the SYSATTACHMENTS form.  Since you won't have anyone doing that, putting code in the SYSATTACHMENTS fc won't get you anywhere.

So, your options are to use what I have already told you is working in our environment (not sure why you don't believe that it's working) or use your initial idea of putting it on the triggers.  The triggers should work too, but your issue was your delete code wasn't working because your trigger is running pre-delete instead of post-delete.  Change when that trigger runs and your current design should work.

0 Likes
Highlighted
Acclaimed Contributor.
Acclaimed Contributor.

Re: Count of attachments for device table

1)

I assumed you were talking about that code ($L.void=rtecall...) should be placed in "FC-Calculations-Calculate - INITIAL"

so I couldn't understand how, in this case, it is possible to obtain current information on number of attachments, because:

a)  INITIAL: "Conditional expressions used in this field are evaluated once, before a record is displayed the first time."

b) So if you talking about "FC-MAIN INFORMATION -Initialization expressions"

  • Initializes fields or variables that are later used in the Format Control record. Initialization expressions are the first operation performed for each evaluation of a Format Control record.

So, as follows from this description - "the initialization expressions" is run when the form opens (i.e. when FC runs)

=======

In both this case - $L.void=rtecall... , only runs when the form opens, but will not start, when I made changes and clicked Save.

0 Likes
Highlighted
Acclaimed Contributor.
Acclaimed Contributor.

Re: Count of attachments for device table

So, if you count the number of attachments and use

FC-CALCULATIONS-INITIAL(true), then you get right amount of attachments, but you get it only after you open a form of CI.

Since I require that each CI contains a number of current number of attachments. To make the selection of records by value of this field. (for example, all CI that have no attachments)

To use FC and triggers to directly write data of the number of attachments is impossible.

1)  FC-CALCULATIONS- ADD\UPDATE as triggers Before Add\Before Update starts before changes will occur in the table SYSATTACHMENTS. Therefore, the calculated value is the number of attachments before making any changes, i.e. the previous value.

2) If use triggers (there is no FC) for SYSATTACHMENTS table, it will be launched after the device table has been saved.

And the user after clicking the save button will still be on the form of CI. Therefore, the trigger for sysattachments will not be able to change the data in the device table.

==========

it seems that the change in the table SYSATTACHMENTS are made after saving the table device (i.e., after performing all actions in FC for device table)

0 Likes
The opinions expressed above are the personal opinions of the authors, not of Micro Focus. By using this site, you accept the Terms of Use and Rules of Participation. Certain versions of content ("Material") accessible here may contain branding from Hewlett-Packard Company (now HP Inc.) and Hewlett Packard Enterprise Company. As of September 1, 2017, the Material is now offered by Micro Focus, a separately owned and operated company. Any reference to the HP and Hewlett Packard Enterprise/HPE marks is historical in nature, and the HP and Hewlett Packard Enterprise/HPE marks are the property of their respective owners.