4 of 4 people found this helpful
My input will probably not help but it's surely worth to know Our problem was the AST:Attribute records were not created at all (not even after 3 hours).
-I found that there is a form ASI:SYSAction where are records created and then set to delete each minute by escalation ASI:SYALProcessRecords
-On delete (which is a strange trigger) another 3 Filters are triggered which should create AST:Attributes record (ASI:SYA:CREATEASSETLIFECYCLESTATUS
The first one checks if you have the class configured in AST:ClassAttributes
The _1 and _2 should create the AST:Atributes record.
Our problem was the AST:Attributes form was somehow corrupt after 9.1.04 upgrade and the value of Submitter didn't have the default $USER$. As the Filter _1 doesn't map Submitter a required field was not set and the process throw always a silten error which we didn't get visible in UI.
That's my story. Hope somebody will give you more hints for your case
Thanks a lot for your valuable inputs.
Seems like your case was now captured as a KB article, exclusively for v9.1.03.
As explained, I see the mentioned filters are executing and exactly at "ASI:SYA:CREATEASSETLIFECYCLESTATUS_1" while executing a Push fields action, a recon id already exists in the custom dataset and hence no records are created in AST:Attributes form for the golden dataset record. This seems to be the OOTB functionality.
This is what I see in the Computer System class:
one in custom dataset and the other in BMC.Asset dataset.
The below is from AST:Attributes form:
one record with matching recon id and instance id, in custom dataset.
However, I was hoping there will be a filter/workflow action which will either create a new record or update the existing instanceid for BMC.Asset dataset.
1 of 1 people found this helpful
Nice KB Article. I had the problem 2 weeks ago but didn't search for KB now I see it is known problem.
I'm little bit confused about what you wrote. If the entry already exist in AST:Attributes then where is the problem ? or you mean the entry is connected to the custom dataset ? then that is wrong from my pooint of view.
If I understand it right, the AST:Attributes entries should exist only for CI's in BMC Asset dataset. As Asset Management works only with Productive CI's hence there is no reason to have these entries for Custom Dataset CIs.
Maybe...if you want to make this clean, you can remove all entries from AST:Attributes and create a escalation which will do the same push as ASI:SYA:CREATEASSETLIFECYCLESTATUS_1 for all entries from BMC_BaseElement where DatasetID=BMC.ASSET. Just then you will lose all AssetLifecycleStatus values.
that was either my plan before I found the real problem that time.
Thanks Marek, seems like the Instance ID's were all messed up after the upgrade from 7.6 to 9.1.
Did some cleanup in specific sandboxes/attribute records and i found my way from there.