One API Feature ,One API Feature Provider ,One API Service Plan ,One API Service Plan Feature

[Komal Gore2]

One API Feature ,One API Feature Provider ,One API Service Plan ,One API Service Plan Feature  
getting added to my update set after Xanadu release.

i have not work on nay REST/SOAP integration , still i can see this getting added to my update set
can anyone help me to understand why this happened and where it is actually being used?

[cynlink1]

I 

Spoiler

I am experiencing the same behavior. Were you able to figure out why this happens?  

FYI, I am not sure why my response to your post says 'Spoiler'.

[ashish0133]

Today I got the same issue, any solution on this or root cause?

[cynlink1]

I opened a case with ServiceNow support. Here is the solution provided:

Solution Proposed:

As mentioned during our call the OneAPI records show up on the sys_update_xml table as these records are auto-created by the OneExtend framework whenever any OneExtend capability or Generative AI capability listed under sys_one_extend_capability table is called. All of these records are created behind the scenes by the OneExtend/OneApi framework. These auto-added records help in mapping the GenAI/OneExtend capabilities to their related providers like Azure, OpenAI, etc depending on the capability and accordingly help with making external calls to these providers via the Flow Designer Integration Hub.

These records are created dynamically when OneExtend/GenerativeAI capabilities are run so you do not need to move them around to other instances as their creation purely depends on the usage of specific capabilities. It's not something the customer has to worry about as it does not affect any functionality. When these records are created they will use the current default update set, which is why they sometimes show up unexpectedly in customer update sets rather than the global default.

It is our recommendation to just move the update set items to a different update set if they are generated in the wrong update set.

[George Daswani]

One of their solutions is to have the developer play "musical chairs" with update sets.   Switch to an update set, capture the specific change, then switch out to the global update set.    When devs perform UNIT testing, they normally don't switch back and forth (proper update set -> default and back)  and makes it a pain (and leads to more errors).     

Another method they stated was for customers to clean up their update sets before 'completing' it, or having some sort of BR or scheduled job auto delete these spurious customer updates.

We ran into this problem and replicated it by just browsing any Workspace Related UI in the system as an admin, these customer updates then end up in currently selected update set (in most causes, Default).   

The option we are going with for now until this issue is fixed is by requesting they turn off the attribute  'update_synch=false' on the following tables in our DEV system (which is the source for all update sets promoted up the tiers).

* One API Feature
* One API Feature Provider
* One API Service Plan
* One API Service Plan Feature

If anybody has a more creative solution, please share..