BookmarkSubscribeRSS Feed
🔒 This topic is solved and locked. Need further help from the community? Please sign in and ask a new question.
JohnJPS
Quartz | Level 8

We are testing a concept on a test system, purposely deleting and recreating a test library, then trying to update the Metadata ID of the new library to match that of original that we deleted. We are using the Metadata Browser, finding the relevant library, going to the Attributes tab, selecting "Id" and attempting to Modify there. (Partially based on the write-up here.)

 

When we attempt to "OK" out of the dialog we receive the error: "ERROR: The attribute name is duplicated in element definition."

 

Is anyone familiar with this error or have either a workaround or comments on the process taken?  The main desire is to match the old Metadata ID so that any dependencies in an impact analysis are unaffected.

1 ACCEPTED SOLUTION

Accepted Solutions
PaulHomes
Rhodochrosite | Level 12

This piqued my interest because I had always thought that SAS metadata object id's could not be changed once assigned. I was surprised that metabrowse would allow you to attempt to change the id. To see what it was trying to do I repeated your example with trace level logging turned on for the metadata server with a throwaway sandpit environment. This was the metadata API XML request it sent to the metadata server with the same error that you saw:

 

2018-09-11T10:22:20,525 TRACE [00402070] 1020:sasadm@saspw - IOM CALL {compRef:7f80cc0878c0}->OMI::DoRequest():
inString=<UpdateMetadata><Metadata><AccessControlTemplate Id="A5XNT08Y.AO000006" Id="A5XNT08Y.AO000XX6"/></Metadata><Ns>SAS</Ns><Flags>268435456</Flags><Options/></UpdateMetadata>
2018-09-11T10:22:20,525 INFO [00402070] 1020:sasadm@saspw - DoRequest return code=807fd80b....
2018-09-11T10:22:20,525 ERROR [00402070] 1020:sasadm@saspw - The attribute name is duplicated in element definition.

 

You can see from the XML that the duplicate attribute name in question is Id. It is being provided once to refer to the object and again to attempt to change the attribute value ... but that XML is invalid. I wonder if this may be a defect in metabrowse in allowing and attempting a change of metadata object id. You may want to follow up with SAS technical support to check this.

 

I think you are likely to run into difficulties with a business process based on being able to choose a specific metadata object id and may want to take a step back and revisit the core issue. I think looking at backup/restore options might give you a better outcome.

 

Looking at the documentation for the Id attribute on the Root object in the SAS 9.4 Metadata Model: Reference, it states in part:

Id is a 17-character string that is guaranteed to be unique for a given object within a metadata server. It takes the form of A0000001.A0000001 where the first 8 characters represent the repository Id and the second 8 characters represent the object Id. If the object is a repository, the first 8 characters represent the repository manager and will always be equal to A0000001; the second eight characters represent the repository Id.

 

Ids should never be stored outside of the metadata object and it should not be assumed that a given logical entity will retain the same metadata Id during its lifetime. When updating logical entities in the metadata server, applications often delete and re-create objects in the metadata server. The new objects created will have different metadata Ids than the original. Also, metadata definitions may be exported and deployed to a new metadata server. These, too, will have different metadata ids than the original objects.

 

There is also a caution in the SAS 9.4 Open Metadata Interface: Reference and Usage section on Identifying Metadata:

CAUTION:
Do not attempt to assign Id values in a client application.
Let the SAS Metadata Server assign identifiers to new objects.

 

I have also been thinking that if you were able to modify metadata objects ids you would probably also have to check to make sure the id you are going to use/reuse is not already being used/reused. Also adding an object with the same id as a previous object will not re-instate any associations that the old object had as those associations (and possibly other objects) will have been deleted when the old object was deleted.

 

Given the use case is someone accidentally deleting an object that may potentially have many other objects associated with it, I would suggest looking into backup/restore options as alternatives. The larger scale options (more disruptive and having potential for loss of metadata changes since the restore point) would be the SAS Metadata Server Backup and Recovery Facility and Deployment Backup and Recovery Tool. For smaller scale options where admins and developers can interactively backup/restore selectively via SAS packages, with the possibility for scheduling package exports in batch, you could look at the SAS metadata Promotion Tools.

 

I hope this helps. Perhaps, other admins managing large DI environments might offer some suggestions on how they handle this use case.

View solution in original post

5 REPLIES 5
SASKiwi
PROC Star

That post you refer to is 5 years old and two SAS versions ago. I'd be surprised if the METABROWSE tool has been kept up to date to deal with the complexities of SAS 9.4 metadata. Most SAS installations I deal with don't even have that tool any more.

 

What is the context of your metadata usage? DI Studio, SAS VA or something else? What is the purpose of delving around under the hood in your SAS metadata?

JohnJPS
Quartz | Level 8

Thanks for you response. The context is DI Studio. Our purpose of delving... we don't expect this to happen often, but suppose a user builds a library and then dozens of other users build dozens of jobs that all pull from that library... then the original user deletes the library. Granted they shouldn't do that, but it would still be nice if we could easily recreate the original library right down to the Metadata ID, such that dependent artifacts are unaffected.

 

That's basically what we're going for, and in many cases the "library" is essentially just a pointer to a database: recreating it is trivial, but unfortunately the Metadata ID is different.

 

PaulHomes
Rhodochrosite | Level 12

This piqued my interest because I had always thought that SAS metadata object id's could not be changed once assigned. I was surprised that metabrowse would allow you to attempt to change the id. To see what it was trying to do I repeated your example with trace level logging turned on for the metadata server with a throwaway sandpit environment. This was the metadata API XML request it sent to the metadata server with the same error that you saw:

 

2018-09-11T10:22:20,525 TRACE [00402070] 1020:sasadm@saspw - IOM CALL {compRef:7f80cc0878c0}->OMI::DoRequest():
inString=<UpdateMetadata><Metadata><AccessControlTemplate Id="A5XNT08Y.AO000006" Id="A5XNT08Y.AO000XX6"/></Metadata><Ns>SAS</Ns><Flags>268435456</Flags><Options/></UpdateMetadata>
2018-09-11T10:22:20,525 INFO [00402070] 1020:sasadm@saspw - DoRequest return code=807fd80b....
2018-09-11T10:22:20,525 ERROR [00402070] 1020:sasadm@saspw - The attribute name is duplicated in element definition.

 

You can see from the XML that the duplicate attribute name in question is Id. It is being provided once to refer to the object and again to attempt to change the attribute value ... but that XML is invalid. I wonder if this may be a defect in metabrowse in allowing and attempting a change of metadata object id. You may want to follow up with SAS technical support to check this.

 

I think you are likely to run into difficulties with a business process based on being able to choose a specific metadata object id and may want to take a step back and revisit the core issue. I think looking at backup/restore options might give you a better outcome.

 

Looking at the documentation for the Id attribute on the Root object in the SAS 9.4 Metadata Model: Reference, it states in part:

Id is a 17-character string that is guaranteed to be unique for a given object within a metadata server. It takes the form of A0000001.A0000001 where the first 8 characters represent the repository Id and the second 8 characters represent the object Id. If the object is a repository, the first 8 characters represent the repository manager and will always be equal to A0000001; the second eight characters represent the repository Id.

 

Ids should never be stored outside of the metadata object and it should not be assumed that a given logical entity will retain the same metadata Id during its lifetime. When updating logical entities in the metadata server, applications often delete and re-create objects in the metadata server. The new objects created will have different metadata Ids than the original. Also, metadata definitions may be exported and deployed to a new metadata server. These, too, will have different metadata ids than the original objects.

 

There is also a caution in the SAS 9.4 Open Metadata Interface: Reference and Usage section on Identifying Metadata:

CAUTION:
Do not attempt to assign Id values in a client application.
Let the SAS Metadata Server assign identifiers to new objects.

 

I have also been thinking that if you were able to modify metadata objects ids you would probably also have to check to make sure the id you are going to use/reuse is not already being used/reused. Also adding an object with the same id as a previous object will not re-instate any associations that the old object had as those associations (and possibly other objects) will have been deleted when the old object was deleted.

 

Given the use case is someone accidentally deleting an object that may potentially have many other objects associated with it, I would suggest looking into backup/restore options as alternatives. The larger scale options (more disruptive and having potential for loss of metadata changes since the restore point) would be the SAS Metadata Server Backup and Recovery Facility and Deployment Backup and Recovery Tool. For smaller scale options where admins and developers can interactively backup/restore selectively via SAS packages, with the possibility for scheduling package exports in batch, you could look at the SAS metadata Promotion Tools.

 

I hope this helps. Perhaps, other admins managing large DI environments might offer some suggestions on how they handle this use case.

JohnJPS
Quartz | Level 8
Thanks Paul for the tips, analysis and explanation. Great stuff.
PaulHomes
Rhodochrosite | Level 12

No problem. It was an interesting exploration.

suga badge.PNGThe SAS Users Group for Administrators (SUGA) is open to all SAS administrators and architects who install, update, manage or maintain a SAS deployment. 

Join SUGA 

Get Started with SAS Information Catalog in SAS Viya

SAS technical trainer Erin Winters shows you how to explore assets, create new data discovery agents, schedule data discovery agents, and much more.

Find more tutorials on the SAS Users YouTube channel.

Discussion stats
  • 5 replies
  • 2268 views
  • 5 likes
  • 3 in conversation