I am feeding ACC nms:broadLogEventHisto data to a legacy system which cannot accept primary keys that are larger than 32 bit integers, but needs a unique value to represent the records. The reason for this can be ignored for this use case.
It turns out, all broadLog tables, with the exception of those related to message center, have a 32 bit integer PK incrementing via the NmsBroadLogId sequence:
I would like to retain the @id field in the broadLogEventHisto schema (without changing the internal name), since the OOTB message center workflow process references and updates data via the name of that attribute, while also adding an additional unique attribute (name = "broadLogEventHistoId32bit") that will run on the same sequence as what is used for the id for tables built off nms:broadLog and auto-increment -- i.e. @id in nms:broadLogRcp. However, extending this table and declaring: autopk="true" pkSequence="NmsBroadLogId", automatically adds a key field with the name @id, which is already taken by the PK in broadLogEventHisto that i wanted to retain. Additionally, i have explored using a counter, but i am unsure how to make the value restart at 0 once all 32bit integer values are consumed. Essentally, i want this new attribute to operate in the same exact manner as @id in nms:broadLogRcp
So my questions are:
1) Where is it decided what autopk="true" names the auto-created PK value?
2) How can i add a value that mimics @id in nms:broadLogRcp within nms:broadLogEventHisto, while retaining the current int64 bit field @id.
FYI - @Jonathon_wodnicki
Solved! Go to Solution.
Views
Replies
Total Likes
Hi,
The nms:broadLogEventHisto/@id col is populated by mcSynch_local workflow, which sets it to:
$int64(vars/@CELL_OFFSET)*$long(vars/@cellId) + @ID
If you only have 1 exec instance, set its execution id to 0 in Deployment wizard, it'll get rid of the offset, no further work needed.
If you have >1 exec instances, you'll need the offset- it's what keeps the logs from colliding when they're collated on the control instance.
To fix (seems like how it should work ootb?):
Thanks,
-Jon
Views
Replies
Total Likes
Hi,
The nms:broadLogEventHisto/@id col is populated by mcSynch_local workflow, which sets it to:
$int64(vars/@CELL_OFFSET)*$long(vars/@cellId) + @ID
If you only have 1 exec instance, set its execution id to 0 in Deployment wizard, it'll get rid of the offset, no further work needed.
If you have >1 exec instances, you'll need the offset- it's what keeps the logs from colliding when they're collated on the control instance.
To fix (seems like how it should work ootb?):
Thanks,
-Jon
Views
Replies
Total Likes
Thanks Jon!
Nms:broadLogEventHisto doesn’t have an autopk, it just populates the @ID field with the values pulled from message center, where the sequence actually exists. I want to add an autopk to this table in mkt, but I can’t because autopk adds a field called @ID...which is already being utilized and populated by the mc feed. I want to see if there’s a way to change the name of the field autopk populates from @ID to something else, so I can add an auto incrementing value to the table with a different name
Views
Replies
Total Likes
-
Views
Replies
Total Likes
Views
Replies
Total Likes
Views
Replies
Total Likes
Views
Replies
Total Likes
Views
Likes
Replies
Views
Likes
Replies
Views
Likes
Replies