Composite SmartObjects
Composite SmartObjects are advanced SmartObjects that combine data from different sources. Composite SmartObjects allow you to create logical business entities (such as Employee, Customer, and Order) that contain data from different LOB systems. Your forms and workflows don't need to know anything about those data sources or how to combine disparate data into a single entity, since the SmartObject and its underlying services do all that work.
Consider the diagram below. We have a logical Employee SmartObject that combines data from a HR SQL Database and Active Directory. With this approach, application designers have access to all relevant data about an employee without having to know where that data resides. The key to building composite SmartObjects is that there must be a common, unique property shared by the data sources to join them. In the example below, there is a common property (Email) that will allow us to 'match' or 'join' data from the two different systems. Because this is a common and unique property in the two systems, you can use these two properties to join data from the different data sources into one SmartObject.
Composite SmartObjects are implemented by creating a SmartObject method that calls two or more service object methods in a sequence, and populate the properties in the SmartObject with the data from different systems. You do this by using the
Considerations
- Don't mix method types: When defining composite SmartObjects from service methods, only use similar methods in the method configuration. In other words, when you define a scalar method (like read, create, update), you can only add other scalar methods for the composite SmartObject. You cannot combine a list method with a scalar method in a composite list method.
- Performance: Adding too many underlying systems into one SmartObject may result in poor performance, especially if your list methods return thousands of rows from multiple systems that are then joined together.
- Method execution sequence: The order of the service object methods is important because, at runtime, the service object methods are executed in the same order that you configure them on the Advanced SmartObjects: Methodsscreen. When building composite SmartObjects, ensure that the service object methods are listed in the correct sequence. This is especially important if you need to retrieve a value form one systems and then pass that value to the next method call to retrieve data from the next system.
- Data availability: Composite SmartObjects effectively flatten a data structure into a single table of data. Remember that Nintex K2 does not store or cache the data. Nintex K2 retrieves the data from the underlying providers and then combines this data into a logical table of data. Your data sources must always be available when SmartObject methods are used in solutions.