Composite SmartObjects

Composite SmartObjects are SmartObjects that combine data and methods from different data sources, which is one of the key benefits of using SmartObjects. This approach allows designers to create logical business entities (such as “Employee”, “Customer”, “Order” and so on) that combines data from the different systems where the data is stored. The consumer (which might be a Form control) does not need to know anything about those data sources or how to combine the data: the SmartObject does all that work behind the scenes.

For example, you may want to create a logical "Employee" SmartObject which combines data from a HR SQL Database and a Azure Active Directory user store and presents this data to your application builders as a logical "Employee" object. The designers don’t need to know where the data comes from; but they can easily use this "Employee" SmartObject that represents all the Employee-related data.

Composite SmartObjects are implemented by creating a SmartObject method that chains or calls two or more Service Object methods in a specified sequence, using the Advanced SmartObjects: Methods screen. The key to building composite SmartObjects is that there must be a common, unique-value property between the data sources that can be used to join the data sources.

Let's examine an example. In the image below, there is a composite SmartObject called Employee, which combines data from an Employees SQL database table and an Active Directory user object. Notice that there is a common property between the two data sources. Both the SQL database and Active Directory store the user’s domain login name (e.g. Denallix\Bob). Because this is a common and unique property in the two systems, K2 can use these two properties to “join” data from the different data sources into one SmartObject.

Conceptual diagram of a composite SmartObject

Considerations

• When defining composite SmartObjects from service methods, you can only use similar methods in the method configuration. In other words, when you define a scalar method, you can only add scalar-type methods (e.g. Read) for the composite SmartObject. You cannot combine a List Method with a Scalar method like Read in a composite List method.
• Adding too many underlying systems into one SmartObject may result in poor performance, especially if you run "List" methods that returns thousands of rows from multiple systems that are then joined together.
• The order of the service object methods is important because at runtime, K2 executes the Service Object methods in the same order that the methods are displayed on this screen. When building composite SmartObjects, you may need to take care to ensure that the Service Object methods are called in the correct sequence.
• Composite SmartObjects effectively “flatten” a data structure into a single table of data. But remember that K2 does not store or cache the data: it just retrieves the data from the underlying providers and then combines this data into a logical "table" of data.