<?xml version="1.0" encoding="UTF-8"?>
<rss xmlns:content="http://purl.org/rss/1.0/modules/content/" xmlns:dc="http://purl.org/dc/elements/1.1/" xmlns:rdf="http://www.w3.org/1999/02/22-rdf-syntax-ns#" xmlns:taxo="http://purl.org/rss/1.0/modules/taxonomy/" version="2.0">
  <channel>
    <title>topic Re: Settings API: how can externalId be updated on an object in Dynatrace API</title>
    <link>https://community.dynatrace.com/t5/Dynatrace-API/Settings-API-how-can-externalId-be-updated-on-an-object/m-p/205573#M2317</link>
    <description>&lt;P&gt;Hi &lt;a href="https://community.dynatrace.com/t5/user/viewprofilepage/user-id/11940"&gt;@Bert_VanderHeyd&lt;/a&gt;,&amp;nbsp;&lt;/P&gt;
&lt;BLOCKQUOTE&gt;According to the documentation the {{.name}} is used to make the comparison (check if it is already there).&amp;nbsp;&lt;BR /&gt;[...]&lt;BR /&gt;I found out that actually the externalId is used of a settings object is used. &lt;BR /&gt;[...]&lt;BR /&gt;On the other hand, this is a very complex way of dealing with this. I think it should just work "by name" like documented with a fallback to externalId&lt;BR /&gt;&lt;HR /&gt;&lt;/BLOCKQUOTE&gt;
&lt;P&gt;The &lt;EM&gt;externalId&lt;/EM&gt; is indeed what is used to identify Settings objects. &lt;BR /&gt;Unlike the previous Config APIs, a Setting does not necessarily have a unique &lt;EM&gt;name&lt;/EM&gt;, or even any &lt;EM&gt;name&lt;/EM&gt; property at all.&lt;/P&gt;
&lt;P&gt;Thus external IDs were added to Settings to allow identifying them by something else than their Dynatrace generated object ID.&lt;/P&gt;
&lt;P&gt;This does make things a lot more complex than the original matching by name, but that complexity is sadly just the cost of the freedom that the general-solution Settings framework brings to configuration.&lt;/P&gt;
&lt;P&gt;Apparently we fail to mention this in documentation at the moment, sorry for that! &lt;BR /&gt;The next part is also still missing from documentation, we'll make sure to add it ASAP!&lt;/P&gt;
&lt;P&gt;&lt;STRONG&gt;How it should work:&lt;/STRONG&gt;&lt;/P&gt;
&lt;P&gt;As the name is gone and the &lt;EM&gt;externalId&lt;/EM&gt; is something monaco (or other tools, or you) has to set, a monaco config can contain an expected &lt;EM&gt;objectId&lt;/EM&gt; in the field&lt;EM&gt;&lt;BR /&gt;&lt;/EM&gt;&lt;/P&gt;
&lt;DIV style="background-color: #ffffff; color: #080808; font-family: 'JetBrains Mono',monospace; font-size: 11.3pt;"&gt;
&lt;PRE&gt;originObjectId&lt;/PRE&gt;
&lt;/DIV&gt;
&lt;P&gt;if an object with this ID is found in the environment, monaco will attach an &lt;EM&gt;externalID&lt;/EM&gt; for it.&lt;/P&gt;
&lt;P&gt;If you've downloaded an environment using monaco you should see these &lt;EM&gt;originObjectIDs&lt;/EM&gt; in your config YAML files, and the first deploy to the same environment &lt;STRONG&gt;should&lt;/STRONG&gt; "onboard" existing configuration to be controlled by monaco.&lt;/P&gt;
&lt;P&gt;Note that updating the &lt;EM&gt;externalID&lt;/EM&gt; &lt;STRONG&gt;should&lt;/STRONG&gt; be possible via the POST endpoint if you supply it with both an existing &lt;EM&gt;objectID&lt;/EM&gt; and an &lt;EM&gt;externalID&lt;/EM&gt;, so it would also be possible manually.&lt;/P&gt;
&lt;P&gt;&lt;STRONG&gt;&lt;span class="lia-unicode-emoji" title=":warning:"&gt;⚠️&lt;/span&gt; Big caveat:&lt;BR /&gt;&lt;/STRONG&gt;&lt;/P&gt;
&lt;P&gt;The Settings framework itself had to be adapted recently to fully allow attaching &lt;EM&gt;externalIDs&lt;/EM&gt; to existing Settings objects. &lt;/P&gt;
&lt;P&gt;As such only the upcoming Dynatrace version 1.262 will fully support this "onboarding" of existing Settings.&lt;/P&gt;
&lt;P&gt;&lt;STRONG&gt;What can you do right now? &lt;/STRONG&gt;&lt;/P&gt;
&lt;P&gt;If possible remove the existing Setting and recreate it with monaco - updating Settings that originated from monaco works without limitation. &lt;/P&gt;
&lt;P&gt;If you can not accept temporarily removing a Setting you could fall-back to using an equivalent Config v1 API to manage it if it exists. In the case of management zones that is possible.&lt;/P&gt;</description>
    <pubDate>Fri, 24 Feb 2023 09:11:56 GMT</pubDate>
    <dc:creator>nico_riedmann</dc:creator>
    <dc:date>2023-02-24T09:11:56Z</dc:date>
    <item>
      <title>Settings API: how can externalId be updated on an object</title>
      <link>https://community.dynatrace.com/t5/Dynatrace-API/Settings-API-how-can-externalId-be-updated-on-an-object/m-p/205492#M2315</link>
      <description>&lt;P&gt;Using monaco v2 now which supports settings API.&lt;/P&gt;&lt;P&gt;I want to update existing configurations (starting with management zones) which were configured manually.&lt;BR /&gt;According to the documentation the {{.name}} is used to make the comparison (check if it is already there). However, although the names are the same monaco complains...&lt;/P&gt;&lt;LI-CODE lang="markup"&gt;2023/02/23 16:31:16 ERROR failed to deploy config global:builtin:management-zones:nasca-300REL: failed to upsert dynatrace obj: failed to upsert config "nasca-300REL" after 3 retries: (HTTP 400)!
    Response was: [{"code":400,"error":{"code":400,"message":"Validation failed for 1 Validators.","constraintViolations":[{"path":"builtin:management-zones/7/name","message":"Management zone with this name already exists. Please provide a different one."&lt;/LI-CODE&gt;&lt;P&gt;I found out that actually the externalId is used of a settings object is used. When I change the name of my config it works and we see this via the API&lt;/P&gt;&lt;LI-CODE lang="markup"&gt;"externalId": "monaco:YnVpbHRpbjptYW5hZ2VtZW50LXpvbmVzJG5hc2NhLTMwMFJFTA==",
      "value": {
        "name": "NASCA-301REL",
...&lt;/LI-CODE&gt;&lt;P&gt;The value after monaco: is actually base64 encoded and corresponds with the monaco id. (builtin:management-zones$nasca-300REL)&lt;/P&gt;&lt;P&gt;So, if I could update the externalId via the PUT api it would be solved. However, that does not seem to be supported.&lt;/P&gt;&lt;P&gt;On the other hand, this is a very complex way of dealing with this. I think it should just work "by name" like documented with a fallback to externalId&lt;/P&gt;&lt;P&gt;&amp;nbsp;&lt;/P&gt;</description>
      <pubDate>Thu, 23 Feb 2023 15:43:34 GMT</pubDate>
      <guid>https://community.dynatrace.com/t5/Dynatrace-API/Settings-API-how-can-externalId-be-updated-on-an-object/m-p/205492#M2315</guid>
      <dc:creator>Bert_VanderHeyd</dc:creator>
      <dc:date>2023-02-23T15:43:34Z</dc:date>
    </item>
    <item>
      <title>Re: Settings API: how can externalId be updated on an object</title>
      <link>https://community.dynatrace.com/t5/Dynatrace-API/Settings-API-how-can-externalId-be-updated-on-an-object/m-p/205573#M2317</link>
      <description>&lt;P&gt;Hi &lt;a href="https://community.dynatrace.com/t5/user/viewprofilepage/user-id/11940"&gt;@Bert_VanderHeyd&lt;/a&gt;,&amp;nbsp;&lt;/P&gt;
&lt;BLOCKQUOTE&gt;According to the documentation the {{.name}} is used to make the comparison (check if it is already there).&amp;nbsp;&lt;BR /&gt;[...]&lt;BR /&gt;I found out that actually the externalId is used of a settings object is used. &lt;BR /&gt;[...]&lt;BR /&gt;On the other hand, this is a very complex way of dealing with this. I think it should just work "by name" like documented with a fallback to externalId&lt;BR /&gt;&lt;HR /&gt;&lt;/BLOCKQUOTE&gt;
&lt;P&gt;The &lt;EM&gt;externalId&lt;/EM&gt; is indeed what is used to identify Settings objects. &lt;BR /&gt;Unlike the previous Config APIs, a Setting does not necessarily have a unique &lt;EM&gt;name&lt;/EM&gt;, or even any &lt;EM&gt;name&lt;/EM&gt; property at all.&lt;/P&gt;
&lt;P&gt;Thus external IDs were added to Settings to allow identifying them by something else than their Dynatrace generated object ID.&lt;/P&gt;
&lt;P&gt;This does make things a lot more complex than the original matching by name, but that complexity is sadly just the cost of the freedom that the general-solution Settings framework brings to configuration.&lt;/P&gt;
&lt;P&gt;Apparently we fail to mention this in documentation at the moment, sorry for that! &lt;BR /&gt;The next part is also still missing from documentation, we'll make sure to add it ASAP!&lt;/P&gt;
&lt;P&gt;&lt;STRONG&gt;How it should work:&lt;/STRONG&gt;&lt;/P&gt;
&lt;P&gt;As the name is gone and the &lt;EM&gt;externalId&lt;/EM&gt; is something monaco (or other tools, or you) has to set, a monaco config can contain an expected &lt;EM&gt;objectId&lt;/EM&gt; in the field&lt;EM&gt;&lt;BR /&gt;&lt;/EM&gt;&lt;/P&gt;
&lt;DIV style="background-color: #ffffff; color: #080808; font-family: 'JetBrains Mono',monospace; font-size: 11.3pt;"&gt;
&lt;PRE&gt;originObjectId&lt;/PRE&gt;
&lt;/DIV&gt;
&lt;P&gt;if an object with this ID is found in the environment, monaco will attach an &lt;EM&gt;externalID&lt;/EM&gt; for it.&lt;/P&gt;
&lt;P&gt;If you've downloaded an environment using monaco you should see these &lt;EM&gt;originObjectIDs&lt;/EM&gt; in your config YAML files, and the first deploy to the same environment &lt;STRONG&gt;should&lt;/STRONG&gt; "onboard" existing configuration to be controlled by monaco.&lt;/P&gt;
&lt;P&gt;Note that updating the &lt;EM&gt;externalID&lt;/EM&gt; &lt;STRONG&gt;should&lt;/STRONG&gt; be possible via the POST endpoint if you supply it with both an existing &lt;EM&gt;objectID&lt;/EM&gt; and an &lt;EM&gt;externalID&lt;/EM&gt;, so it would also be possible manually.&lt;/P&gt;
&lt;P&gt;&lt;STRONG&gt;&lt;span class="lia-unicode-emoji" title=":warning:"&gt;⚠️&lt;/span&gt; Big caveat:&lt;BR /&gt;&lt;/STRONG&gt;&lt;/P&gt;
&lt;P&gt;The Settings framework itself had to be adapted recently to fully allow attaching &lt;EM&gt;externalIDs&lt;/EM&gt; to existing Settings objects. &lt;/P&gt;
&lt;P&gt;As such only the upcoming Dynatrace version 1.262 will fully support this "onboarding" of existing Settings.&lt;/P&gt;
&lt;P&gt;&lt;STRONG&gt;What can you do right now? &lt;/STRONG&gt;&lt;/P&gt;
&lt;P&gt;If possible remove the existing Setting and recreate it with monaco - updating Settings that originated from monaco works without limitation. &lt;/P&gt;
&lt;P&gt;If you can not accept temporarily removing a Setting you could fall-back to using an equivalent Config v1 API to manage it if it exists. In the case of management zones that is possible.&lt;/P&gt;</description>
      <pubDate>Fri, 24 Feb 2023 09:11:56 GMT</pubDate>
      <guid>https://community.dynatrace.com/t5/Dynatrace-API/Settings-API-how-can-externalId-be-updated-on-an-object/m-p/205573#M2317</guid>
      <dc:creator>nico_riedmann</dc:creator>
      <dc:date>2023-02-24T09:11:56Z</dc:date>
    </item>
  </channel>
</rss>

