Microservice not triggered when adding rows with UNION in source element

High-Level Problem: I have an editable table element (CC) and want to edit values via a WF with a Microservice Input - WF is not even triggered (no Jobs)

Set up:
datatable → APPS: datasource linking to datatable with SQL adding rows with UNION to datatable → APPS: table element linked to datasource with Microservice Endpoint → WF with Microserive Input (ignore schema mismatch on)

Shouldn’t the Microservice Input get triggered even though rows are added?

I tested the same setup with an SQL query without UNION only adding columns

Does trigger WF:

SELECT
  *,
  0.0 AS calculated_hidden_year_1,
  0.0 AS calculated_hidden_year_2,
  0.0 AS calculated_hidden_year_3,
  0.0 AS calculated_hidden_year_4,
  0.0 AS calculated_hidden_year_5,
  0.0 AS calculated_hidden_year_6,
  node_name AS kpi
FROM
  inputTable i

Does not trigger WF:

SELECT
  *,
  0.0 AS calculated_hidden_year_1,
  0.0 AS calculated_hidden_year_2,
  0.0 AS calculated_hidden_year_3,
  0.0 AS calculated_hidden_year_4,
  0.0 AS calculated_hidden_year_5,
  0.0 AS calculated_hidden_year_6,
  node_name AS kpi
FROM
  inputTable i
UNION
  (
    SELECT
      i.*,
      0.0 AS year_1_cal_hidden,
      0.0 AS year_2_cal_hidden,
      0.0 AS year_3_cal_hidden,
      0.0 AS year_4_cal_hidden,
      0.0 AS year_5_cal_hidden,
      0.0 AS year_6_cal_hidden,
      'FTE (Yearly Average) (S&M)' AS kpi
    FROM
      inputTable i
    WHERE
      node_name = 'FTE (S&M)'
  )

Error in console when saving editable table:
image

Since I suspect this has something to do with how App’s “datasource” is digesting SQL code, this could be more of an Apps issue than a ONE DATA Core issue.
@emanuel.berndl Could you maybe also post it under this category?

1 Like

Very good idea, @matthias.lechner , thanks for pinging me.
I quickly checked if there is a possibility to post it in both categories, which there isn’t - so I picked Apps as the most likely better fitting category - hope that is fine!

1 Like

Before calling the microservice app builder uses the implicit ROW_IDs to map your changes to the original rows. A union breaks that mapping. We tried some time ago several workarounds e.g. collecting all available ROW_IDs and somehow distributing them on the new schema (after union) but we did not succeed, so we’d also be interested in a solution.