Despite Successful Skill Execution logs (Write To Table (Continuous Data Push API) + Update New Attributes), data is not being written to a table

Hi Vasco,

let's troubleshoot it piece by piece.

1) did you recently change permissions? It can be that now the API key no longer have the permissions to write to the table

2)when you trigger the skill manually, does it populate your ANALYZED_DUPLICATED_HOLDER table?

3)when you trigger the skill manually and it does not populate the ANALYZED_DUPLICATED_HOLDER, can you check the latest value of the attribute of "7) Update new attribute"? It can be that it is taking the other route

Best,

Gabriel

Hello Gabriel,

Thank you for taking the time!

1) No permissions were changed, that I am aware of:

1.1) Event Log permissions:

1.2) Data Model permissions:

I'm not sure if it should have permissions enabled anywhere else, but at least here they are okay.

2) The only way to trigger the skill is indeed manually and it is not populating the ANALYZED_DUPLICATED_HOLDER at this time, despite the successful logs.

3) This is the last actually successful execution, and step 7 is really not happening..

Do you see anything in here that should be different?

I ticked permissions on and off, and reran the skill manually to see if there will be an impact, let's see...

In the backend, I have a script that drops and recreates the table in order to remove duplicate entries, the table is created with the exact same format and name, could this have an impact? I'm fairly certain this was already in place at the time, but, is it possible?

Update: I had another look at the backend, and I'm NOT dropping or altering this table at all, I'm copying everything from this table to another table (ANALYZED_DUPLICATES) and altering that one, so as not to cause any potential issues.

Regardless, after testing it out, it works if I select only 1 Record Entry to use the Skill on, but when I select multiple entries it does not work anymore.....

Multiple Entry selection:

Looks like this:

Single Record Entry Selection looks like this:

We've never had issues with it previously, I'm not sure what could've caused this.

Update: My current theory, since all failed executions pertain to entries that have a value in their FLOAT Data Type Columns >= 1000.

This is due to the fact that the formatting of these values changes from 999.99 to 1,000.00, for example, and the thousands separator "," turns the value into a STRING Data Type, which cannot be populated into the table, since those columns are of Data Type FLOAT

It makes no sense, I have no such formatting in the knowledge model, I'm fixing this in the backend by creating an auxiliary table, but I don't think I should have to.

Hi Vasco,

this is indeed very odd and probably a bug. Would you mind raising a servicedesk ticket (servicedesk@celonis.com) so the Product Team can investigate>

Thank you!

Best,

Gabriel