I’m trying to return a simple array of objects from a typescript function to be used in Workshop as an object set. However, Workshop doesn’t automatically interpret this array as an object set. I’ve considered using the Ontology API to define a new object type and create an object set, but this requires changes to the Ontology. Are there alternative ways to present this data in Workshop, or is there a way to configure Workshop to recognize the array as an object set?
In general, to have a Function-backed Object Set variable in Workshop, the corresponding Typescript function needs to return an ObjectSet type as opposed to an ObjectList.
Depending on how you’re generating your list, there are possibly more efficient ways, but the straightforward approach is simply to map through the list of objects and create a list of the primary key values, and then return an object set based on the .exactMatch() filter search.
The input to the typescript function is an object type.
I get all records(object set) of the object type. The object set has around 100K records and 80 columns.
The output I am trying to return is a table with 4 columns
Column 1 - hardcoded values that are just labels
Column 2 - aggregation(sum) of a column, with each record an aggregation of a certain column
Column 3 - aggregation(sum) of a column, with each record an aggregation of a certain column
Column 4 - delta of column 2 and column 3
I am unable to return an object set as the output does not have any primary keys.
It sounds like you’re looking for this: https://www.palantir.com/docs/foundry/workshop/widgets-object-table#configure-a-single-function-backed-property
Scroll down for a code example for how to write a single function that will return all three of your aggregation columns. Note the return type is of a special type.
Thanks for clarifying and apologies for misunderstanding your initial explanation; I got it now that you’re looking to make a table that is based on the information in the input object set, but no longer corresponds 1:1 with those objects.
The more straightforward options to consider are the pivot table, if your aggregations are straightforward to define (this widget is getting an overhaul in the first half of this year) or, like @joshOntologize mentions, using the function-backed or linked object aggregation derived properties. This latter approach is limited, however, in that each row of the table will still correspond to a single object in the input set.
The “ontological” solution would be to create a new object type that represents whatever real-world concept defines the categories in column 1; I’m imagining this might be “Regions” or " Product Category" or something like that. I wrote some brief thoughts on this elsewhere that I’ve copied into a footnote for reference.
Finally if you want to kind of “brute force” it, you could check out this comprehensive guide to a function-backed dynamic pivot table or you could drop in and build it pretty quickly in Slate and then embed the Slate visitation as a custom widget.
Footnote: Modeling Hierarchies in the Ontology
Hierarchies come in two flavors with two modeling approaches:
Of a kind hierarchies represent hierarchical relationships between entities of the same fundamental type, for example employee object types have a managerial hierarchy or parts have a module/sub-module hierarchy while at each level sharing the same fundamental properties. Our ontology model should reflect this and a common practice is to configure a self-referential link from the lower to the higher (i.e. from a specific employee to their manager or an individual part to a sub-assembly).
In addition to these one-step relations, the entire upwards and downwards tree can be collapsed in the pipeline phase using a connected component algorithm such that each object has a property with the list of all the upwards and downward nodes. In this model, a given object will normally have a “level” property of some kind that allows for easy horizontal comparison by filtering the set of all components.
Distinct hierarchies reflect real world concepts where each layer is fixed and fundamentally distinct. A common example is geographic hierarchy - facility, city, state, country, region. Each layer represents something different in the world and we would want to treat it differently with regards to information display. While you could abstract this type of hierarchy to a single object type and model it as above, more common would be to model it as a separate object type for each level, with Relations defined between them.
Regardless of which approach is taken for modeling hierarchical data, use the hierarchy:parent Typeclass in the link configuration on the parent object type to enable extra navigation affordances in Object Explorer.
2 Likes