Getting cdt data from a dse

If this is static, why not just create a CDT from it? Then do a!keys() on that CDT.

Because it's not static. I basically have to figure out what the table looks like from the dse input so I can populate/query the table regardless of which table it is. 

I have a milestone component that is used across everything in the application. There are various different activities that require the milestone, but each has its own set of steps. The steps themselves are held in one table that basically builds out the milestone based on the name of the activity type. But to know which step on the milestone the milestone is supposed to be, I need to query up data from that particular activity's history table. Each activity has a different history table, so one of the rule inputs is the history table's dse. The layouts of these tables are all different, so I need to be able to basically pull up the list of column names and figure out which column has the exact data I need to tell the milestone I'm on step x.

Now normally there is something in the history table, so it being empty isn't USUALLY a big deal, except for the very first time you create a particular activity of a particular type. I can manually throw in some dummy value in the backend of course, but I'd rather not do that if there is a better way. 

That is an interesting challenge :-) Thank you for the explanation.

If you can create a mapping of DSE to TABLE NAME, you may be able to use my solution to reference the columns via something such as INFORMATION_SCHEMA.COLUMNS - are you on MSSQL?

I'm not sure if it is possible to access table name dynamically via DSE input, but I have seen some work magic with XML on here for related situations..

Thanks. It works really well and saves us the trouble of configuring a new milestone each time we come up with a new activity or need to rework the flow of an existing activity. This one minor kink aside anyway. 

Wouldn't I still need something in the table to do that? I'm good on the Appian side if something is in there. 

No, INFORMATION_SCHEMA.COLUMNS is the database definition and does not rely on data in the tables.  This is the MSSQL version, I'm not sure what you are using for an underlying database.  Just a thought for how you might be able to return columns per DSE/table regardless on data present.

For instance, in this case we query for "chris_test_table" and are returned all column names, data types, etc in that table (more metadata is available).  The table is empty.

We've got MariaDB. I guess I'd pull this info up through a stored procedure. Question is how do I get the table name from the dse? 

Since each DSE has to map to a CDT, why not just make an expression rule that stores a key:value pairing with different DSEs and their matching CDT?

I was thinking creating a mapping as well - assuming new DSEs are not added that frequently?

Also, MariaDB should be similar for INFORMATION_SCHEMA.COLUMNS.  I would create a VIEW, then map a CDT/DS to the view, vs a stored procedure.

Also, MariaDB should be similar for INFORMATION_SCHEMA.COLUMNS.  I would create a VIEW, then map a CDT/DS to the view, vs a stored procedure.

I just whipped up this quick expression rule which, storing a list of data store entities and their accompanying CDTs, one can pass a DSE (like via constant) and it'll find the matching item in the list.  If I were implementing this for real I'd probably store the list of maps in "local!pairs" in its own expression rule (for universality) and just reference it from this one.

a!localVariables(
  local!pairs: {
    a!map(
      entity: cons!APP_ENTITY_PERSON,
      type: 'type!{urn:com:appian:types:APP}APP_Person',
      typeId: tointeger('type!{urn:com:appian:types:APP}APP_Person'),
      keys: a!keys('type!{urn:com:appian:types:APP}APP_Person'())
    ),
    a!map(
      entity: cons!APP_ENTITY_EQIP_SUBMISSION,
      type: 'type!{urn:com:appian:types:APP}APP_eQIPSubmission',
      typeId: tointeger('type!{urn:com:appian:types:APP}APP_eQIPSubmission'),
      keys: a!keys('type!{urn:com:appian:types:APP}APP_eQIPSubmission'())
    )
  },
  
  local!index: where(local!pairs.entity = ri!dse),
  
  index(local!pairs, local!index, null())
)

As seen here, we can even have it directly provide us the CDT "keys" array as a member of the output set(!)

Nice!  We are not on a version that supports a!keys() yet :(.  I believe that was introduced in 21.4?

Yeah, plus or minus a version.  AFAIK there might be a usable workaround if you need, like by populating an empty member of the data type then scraping the text for the property names.