
PAGE 8
All rules of the process
User Interfaces
Reports
The SmartObjects are then mapped to their appropriate backend systems via SmartObject Services. This allows
changes to the back-end system at any point in time without affecting the business application. When using the
SmartObject Services shipped with the product, no code needs to be written for read and write access to backend
systems. Custom SmartObject Services, often referred to as Service Objects, can also be written to talk to various
backend systems that do not have a corresponding SmartObject Service that ships with K2 blackpearl.
Note: The Active Directory service objects that ship with K2 blackpearl 0807 do not allow updates to Active
Directory. There is a service object available on K2 blackmarket that allows updates
(http://k2underground.com/k2/ProjectHome.aspx?ProjectID=3).
Using SmartObjects in this manner allows a process to store nothing but a reference to a SmartObject ID in the
process data fields, which abstracts data from the process and offloads work from the K2 workflow server. Using
this one data field, a SmartObject Reference can be made in the process definition. This SmartObject reference
becomes a re-useable object in the process definition which, in turn, is employed in line rules, start rules,
escalation rules, destinations and the like. As a benefit of abstracting data from the process, the process becomes
more lightweight in terms of instance data handled by the server and database storage needs as well as
permitting this business data to be more easily leveraged outside of the process.
Follow your company's naming conventions when defining properties and methods in your service objects, and
provide understandable descriptions for service type properties and methods, since these are surfaced to users
that need to design SmartObjects that consume these methods and properties.
SmartObjects are developed once the underlying service types have been registered on the K2 server and an
instance of the service type created. This instance registration is accomplished through the K2 Workspace, and
can also be accomplished with the BrokerManagement.exe tool that allows you to supply a specific service
instance GUID for each custom service type.
You might choose to keep all SmartObjects within separate solutions based on the service types, but since
SmartObjects do not necessarily have to be bound to a specific service type, this approach may not be logical. A
single solution for all SmartObjects may be a better approach, as you can ensure consistency and avoid naming
conflicts, duplicated and overwritten SmartObjects, and to centralize the deployment of SmartObjects. Where this
is not possible, develop groups of SmartObjects, each within a single solution, using an approach that makes
sense to your business, but try to avoid having any single SmartObject contained within multiple groups. A hybrid
approach that may work in your environment is to develop all business-related, common SmartObjects in a single
solution, and have separate solutions for application-specific SmartObjects.
With the single solution approach, developers are able to work on individual SmartObjects at the same time,
although deployment requires them to „exclude‟ SmartObjects they are not currently designing.
Note: When deploying SmartObjects, K2 will automatically create a Category for the project name and sub-
categories for each of the folders in the project. By including all SmartObjects in a central solution, you can
ensure that SmartObjects are logically grouped, named and deployed to the K2 category system.
There are two more important things to remember when designing SmartObjects.
K2 provides two mechanisms to retrieve data from SmartObjects: The.NET Data Provider for
SmartObjects (a standard ADO.NET data provider) and the SourceCode.SmartObject.Client API. Each