SmartObject Terminology and Architecture
Understanding the terms used in the SmartObjects component will be valuable when you want to create more advanced SmartObjects (for example, if you want to create SmartObjects that integrate with external systems like SQL databases and Web Services, or when you want to create composite SmartObjects that combine data from different systems).
The diagram below illustrates the basic architecture and terminology of SmartObjects. The important terms have been highlighted in red and are described more in the text following the diagram.
SmartObjects
A SmartObject is the logical business object or entity that consuming elements like Reports, Forms and Workflows will use to ultimately interact with some Provider. A SmartObject is made up of properties and methods that come from one or more Service Objects. The SmartObject itself is actually nothing more than a definition that tells K2 which Service Object to use when populating the SmartObject with data or executing a method. A SmartObject could be associated with a single Service Object: for example the “Customer” and “Account” SmartObjects in the diagram. Each of these SmartObjects links to respective “Customers” and “Accounts” Service Objects. The “Customers” and “Accounts” Service Objects, in turn, point to tables in the “Finance” SQL database. This is a fairly straightforward “mapping” of a data entity in a Provider (a table in a SQL database) that ultimately maps directly to an equivalent SmartObject. The consuming element does not need to know anything about the SQL database or how to interact with a SQL database, instead it just calls the SmartObject and K2 takes care of the rest. SmartObjects could also be associated with multiple Service Objects when you combine properties and methods from different Service Objects; these are known as Composite SmartObjects. In the diagram, we created an “Employee” SmartObject. This SmartObject points to the “AAD User” Service Object and the “Employees” Service Object, each of which retrieves data from a different provider. By combining the data from different systems, we created a more interesting logical business object called “Employee” which may be very useful to our business. Again, the consuming elements do not need to know anything about the underlying systems or how the data is combined: all they know is that there is an “Employee” object that contains all the data that makes up an Employee in our organization, regardless of where that data resides.
Service Objects
A Service Object is a representation of the properties and methods for an entity in a particular provider. Consider the “Customers” SQL table in the diagram. This SQL database table has several columns (name, contact person, website and so on) and methods (select, update, delete and so on). K2 uses a Service Object to represent the database table’s properties and methods in a way that can be understood and used by SmartObjects. When you register a Service Instance for a particular provider, K2 will query the target system and then generate Service Objects for that system based on the entities it could discover. Optionally, you could also tell K2 to generate SmartObjects for each Service Object, but you can always create a SmartObject manually later and point it to an existing Service Object as well. You can also use the same Service Object in multiple SmartObjects; in the diagram, notice that the “AAD User” Service object is used in two different SmartObjects. This makes it possible to create different SmartObjects that expose different data, but still using the same underlying Service Objects and Service Instances. In this example, perhaps the business wanted to create a “User” SmartObject that is used to modify user accounts in Azure Active Directory, and another “Employee” SmartObject that is used to Read data from a SQL database and Azure Active Directory.
Service Instance
A Service Instance is a configured instance of a particular Service Type. Essentially, this is where K2 stores the configuration information necessary to reach a particular system, such as a server name, web service address or database name. This configuration is defined and stored in the Service Instance Configuration, and also includes security settings (in other words, what security credentials should K2 use to connect to the service), connection settings (for example, the name of the SQL server and the database that the service instance should connect to) and other configuration settings that may be required by the provider. The configuration settings are usually different depending on what type of system you are trying to connect to: a SQL database would have different connection settings than a Web Service, for example. In the diagram, notice that there are two Service Instances in the SQL Service Type block. Each Service Instance has been configured to point to a different SQL database, but they both use the same SQL Service Broker to communicate with the target databases. In the diagram there is also a Service Instance of the AAD Service Broker, which has been configured to point to the Denallix365 domain. A Service Instance is always associated with a particular Service Type. Think of it this way: the Service Type tells K2 which adapter/broker to use when connecting to a provider, and the Service Instance tells K2 how to connect to the provider. The Service Broker does all the actual work of interacting with the provider.
Service Type
Service Types are essentially "connectors" or "adapters" that allow K2 to interact with some underlying system and eventually expose that system as SmartObjects. A Service Type is used to allow K2 to integrate with a particular technology, while Service Instances are configured instances of a Service Type that connect to specific occurrences of that technology. Service Instances are essentially configured instances for a particular service type that point to s specific occurrence of a technology, and you can have multiple Service Instances for the same Service Type that are configured to connect to different systems. For example one instance of the SQL Server Service Type will be configured to interact with your HR database while another Service Instance of the SQL Server Service Type will be configured to interact with your Finance database. You must configure Service Instances before developers and designers will be able to create SmartObjects for that particular data store.
A Service Type is just an entry in a database for a specific Service Broker. Before K2 can use a Service Broker to interact with some Provider, the Service Broker must be registered with K2 as a Service Type. K2 administrators can then create Service Instances for the Service Type and configure the Service Instance with the necessary settings to connect to a particular system. A Service Type is bound to a Service Broker in a one-to-one relationship. Usually, a K2 environment will contain many different Service Types, and each Service Type is usually associated with a particular Provider technology. In the diagram, there is a Service Type that understands how to interact with SQL Databases, and another Service Type that understands how to interact with Azure Active Directory. Of course, your K2 environment will have many more Service Types. For a listing of available Service Types, you can jump to SmartObject Services
Service Broker
A Service Broker is the “adapter” or “connector” that performs the actual work of connecting to some provider, executing the methods and doing the translation between the service object “language” and the “language” that the provider understands. In the diagram, we are using the SQL Service Broker to communicate with the SQL databases. The same Service Broker is used by both the “Finance Database” and the “HR Database” Service Instances because the mechanism to interact with a SQL database is the same, regardless of the actual data in that database. However, if we want to interact with another system (like Azure Active Directory), K2 will use a different Service Broker because the language and syntax to interact with an Azure AD system is different than interacting with a SQL Database. Under the covers, Service Brokers are .dll files that reside in the file system of a K2 server.
Providers
A Provider is just the source of the data, for example the database, web service, API or whatever else is providing the data that we want to expose as a SmartObject. It is important to note that the data always lives in a Provider: SmartObjects does not store actually store any data. Whenever you interact with a SmartObject, K2 will use the Service Object>Service Instance>Service Type>Service Broker mechanisms to retrieve data from the provider on-demand. This ensures that data is always consistent and you are always interacting with the latest version of the data.
Available Service Types
The table below lists some service types that are available in K2. You can review the available Service Types in your environment by using the Service Types screen in the K2 Management Site.
| Service Type | Description | Can be configured /registered |
|---|---|---|
| K2 Service Types | These Service Types integrate with the K2 system itself and are often used for internal functions performed by K2. | |
| Deployment Service |
Internal service used by K2 for K2 Package and Deployment functionality. |
No |
| K2 Generic Settings Service |
Provides a generic SmartObject service that is used for storing and using personal and shared settings. |
Yes |
| K2 Management |
Internal service used by K2 for management functions. |
No |
| Licensing Service |
Internal service used by K2 for licensing operations and license audit reporting. |
No |
| PDF Converter |
Internal service used by K2 for converting HTML or dynamic URLs to PDFs. |
No |
| SmartBox Service | Provides a K2-managed SQL database for storing SmartObject data when there is no existing system that can store the data. (By default, SmartObjects will use the SmartBox provider unless you specifically change the SmartObject to use data from a different system.) | No |
| SmartObject Service Functions |
Internal service used by K2 to work with Service Instances and SmartObjects. |
No |
| Task Allocation Service | Used for Task Allocation operations and algorithms. | Yes |
| User Role Manager Service |
Provides methods for returning users, groups, roles and security label information from the available Security Providers. |
No |
| Workflow Reporting |
Provides the data used to generate K2 workflow reports and (optionally) exposes reporting SmartObjects for specific K2 workflow definitions. |
No |
| Workflow Service |
Provides runtime services for K2 workflows, such as starting new processes or opening and completing worklist items for specific events in the workflow. |
No |
| Technology-specific Service Types | These Service Types integrate with specific technologies, and are often used to create SmartObjects that integrate with those technologies. | |
| Account Management |
The Account Management service type provides write capabilities for Active Directory integration. |
Yes |
| AD Service2 (Active Directory) |
The Active Directory 2 service type provides objects and methods to read information from Active Directory. |
Yes |
| Azure Active Directory |
The Azure AD service type provides the ability to lookup and manage users and groups in Microsoft Azure Active Directory. |
Yes |
| CRM |
The CRM service type provides the ability to integrate with a Microsoft Dynamics CRM environment. |
Yes |
| CRM Functions |
The CRM Functions service instance allows K2 to integrate with CRM, and is used in conjunction with the CRM service |
Yes (but not necessary) |
| CRM 4 Entity |
The legacy CRM 4 Entity service types provide the ability to integrate with CRM 4 entities in a Microsoft Dynamics CRM 4 environment. |
Yes |
| CRM 4 Functions |
The legacy CRM 4 Functions service instance allows K2 to integrate with CRM 4 functions based on a Microsoft Dynamics CRM 4 environment, and is used in conjunction with the CRM 4 Entity service |
Yes (but not necessary) |
| DocuSign |
The DocuSign service type allows K2 to integrate with DocuSign. Note that this Service is configured with the DocuSign page in the K2 Management Site. |
(see description) |
| Exchange |
(This Service Type is deprecated and should no longer be used. Listed for backward compatibility only) |
No |
| Exchange Administration |
Provides functions to manage Exchange mailboxes. |
Yes |
| Exchange Management |
Provides functions to manage Calendar, Task and Meeting items. |
Yes |
| Exchange Metadata |
Allows the K2 server to discover Exchange servers, groups and mailbox databases. |
Yes |
| Oracle Service |
Provides integration with Oracle database to expose database entities as SmartObjects. |
Yes |
| SalesForce Service |
Exposes Salesforce entities for a specific SalesForce.com account using a WSDL file provided by SalesForce. |
Yes |
| SharePoint Functions |
This is an internal broker that K2 uses for integrating with SharePoint in order to read group information from SharePoint and to read and load List column or Document column values. |
No |
| SharePoint Service V1 |
(This Service Type is deprecated and should no longer be used. Listed for backward compatibility only. Please use the SharePoint Service V2 for integration with SharePoint 2010 and earlier.) |
No |
| SharePoint Service V2 |
Provides read and write capabilities to read, update, delete, list and add attachments to SharePoint 2010 and earlier libraries and Lists. |
Yes |
| SharePoint Content |
The SharePoint Content service type enables integration with the SharePoint 2010 CSOM (Client-Side Object Model) API to manage content in SharePoint, such as list items and documents. |
Yes |
| SharePoint Management |
The SharePoint Management service type allows you to make calls to the SharePoint 2010 CSOM (client side object model) to manage lists, libraries, templates and subsites. |
Yes |
| SharePoint 2013 | Provides integration with SharePoint 2013 and later as well as SharePoint Online to interact with SharePoint List, Libraries and Sites via the SharePoint CSOM (Client-Side Object Model) and REST APIs. Service Instances for these Brokers are normally generated by running the K2 Registration wizard after adding the K2 App to the SharePoint site | (see description) |
| SharePoint 2013 Integration | This is an internal Service Type that K2 uses for integrating with SharePoint 2013 and later as well as SharePoint Online to perform functions related to SharePoint Events, Form Submit Types, Helper Methods, Settings, Setting Events, Workflow and Workflow Events | No |
| SQL Reporting Service |
The SQL Server Reporting service type exposes the Export methods for reports published to a SSRS server as SmartObject methods. |
Yes |
| SQL Server Service | The SQL Server Service allows K2 to interact with Tables, Views and Stored Procedures a Microsoft SQL Database by exposing these as SmartObjects. | Yes |
| Generic Service Types | These Service Types are built to integrate generically with technologies that expose certain APIs or Services, and are often used to create SmartObjects that integrate with technologies when there is not a technology-specific Service Broker, or the standard technology-specific Service Broker does not provide the desired functionality. | |
| Endpoints Assembly |
Allows the calling of public static methods of a .NET assembly. |
Yes |
| Endpoints WCF |
Allows K2 to interact with WCF endpoints using .NET serialization/de-serialization. |
Yes |
| Endpoints WebService |
Allows K2 to interact with web services endpoints using .NET serialization/de-serialization. |
Yes |
| OData |
Allows K2 to interact with OData-compliant web service endpoints using .NET serialization/de-serialization. |
Yes |
| REST |
Allows K2 to integrate with REST endpoints. |
Yes |