Assembly
The Assembly Service Type enables you to call Public Static methods from .NET assemblies by exposing these methods as SmartObjects. The broker utilizes serialization and deserialization to work with .NET types.
Service Keys (Service Instance Configuration Settings)
| Key | Can be modified | Data Type | Sample Value | Notes |
|---|---|---|---|---|
| Assembly Full Path | Yes | Text |
\\server\share\file_path "%ProgramFiles%\K2 \Host Server\Bin" |
The full path, relative to the K2 Server, to the assembly. Universal Naming Convention (UNC) paths are supported. |
| Serialization: Compress | Yes | True/False | False | Compress the serialization data for complex types. |
| Serialization: Include All Assembly types | Yes | True/False | True | Includes all available serialization objects regardless of usage in public methods |
| Names: Append Property Types | Yes | True/False | True | Includes the property type in parentheses after the complex property name. Default value: True. |
| Names: Use Method FullName | Yes | True/False | True | Uses the full name of the method including the property names and types. Default value: True. |
| Debugging Enabled | Yes | True/False | False | Displays stack trace information in dialog and error information. Default value: False. |
| Include non Serialized Properties | Yes | True/False | False (Default value: False) |
If the value of this Key is set to True it will add non-Serializable properties on the Serialize method Input values. |
Service Objects
When generating SmartObjects for an Endpoint Service Instance, some standard categories of SmartObjects are created; for example, the Object Types, and System Types. These define the data types used. Other SmartObjects may be generated depending on what the Endpoint exposes.
SmartObjects
K2 does not automatically create SmartObjects for the Service Objects in this service. SmartObjects can be automatically created by selecting the Generate SmartObjects for this Service Instance check box when creating a new Service Instance. Designers can use the SmartObject design tools to build advanced SmartObjects that leverage the Service Objects in this service. It is recommended to use the SmartObject design tools to create SmartObjects rather than generating SmartObjects, since this allows better control over the naming, behavior and design of the SmartObject and its methods and properties.
Considerations
- The targeted assembly (and its references) must be placed in the %ProgramFiles%\K2\ServiceBroker or the %ProgramFiles%\K2\Host Server\Bin directory, or can be registered in the GAC.
- In a farm environment, the assembly and its references must exist on each physical K2 server.
- For .NET Assemblies, only public, static methods are supported. The service broker should not be used to replicate .NET programming through SmartObjects because the Endpoint broker is stateless; without state, everything is static. The purpose of exposing an assembly is to use existing business logic in .NET assemblies within SmartObjects. Creating new instances of .NET classes and objects and then using them within SmartObjects is not a valid scenario for the Endpoint service broker.
Pointing the Assembly to SharePoint.dll, for example, will expose the Site class. But creating a new site instance and then using that with SmartObject is not a valid scenario. However, pointing the Assembly to SourceCode.Workflow.Functions.dll is a great scenario for accessing the static methods available in Inline Functions via SmartObjects. - When working with EndPoint SmartObjects, an understanding of serialization and deserialization is essential. See Working with EndPoint SmartObjects for more information.
- When using System.Configuration.ConfigurationManager.AppSettings in the targeted assembly's code, the default configuration file is the K2HostServer.exe.config. For example, if the assembly utilizes code like this:
value = System.Configuration.ConfigurationManager.AppSettings["anykey"];
that configuraiotn value must be defined in the K2HostServer.exe.config file.
It is possible (and recommended) to have a separate config file just for the assembly, however the code in the assembly will have to explicitly use the configuration file, as in the sample below:
appConfig = System.Configuration.ConfigurationManager.OpenExeConfiguration(System.Reflection.Assembly.GetExecutingAssembly().Location);
value = appConfig.AppSettings.Settings["anykey"].Value; - The Assembly Broker supports UNC paths, but the latest .NET framework blocks loading assemblies from remote sources by default. Loading assemblies from remote sources is a security risk. Rather keep assemblies on the K2 server. If, however, you need to load assemblies from UNC paths and ignore the risk, enable "loadFromRemoteSources" in the K2HostServer.exe.config file by placing the following element under the <runtime> element that is found under the <configuration> element:
<loadFromRemoteSources enabled="true"/>
If it is not enabled the following Service Instance Error will occur:
"VALIDATION An attempt was made to load an assembly from a network location which would have caused the assembly to be sandboxed in previous versions of the .NET Framework. This release of the .NET Framework does not enable CAS policy by default, so this load may be dangerous. If this load is not intended to sandbox the assembly, please enable the loadFromRemoteSources switch. See http://go.microsoft.com/fwlink/?LinkId=155569 for more information."
- For troubleshooting tips, please see Troubleshooting the EndPoint Service Types