Publishing Service Objects

When you have created the Service Object, publish it to a location where it can be run against the SAP BAPIs to execute the service methods. The Service Object is published to the connect Application server. You can access the service objects from the Default Service object repository. Publishing the Service Object exposes the methods that were created as Service Object methods in K2 Five and makes them available via the K2 connect service broker. This enables you to create a SmartObject based on the Service Object. The SmartObject acts as an intermediary layer between a workflow or smartform and the Service Object, as the methods are not exposed directly but are called via the service broker. Explained simply, the SmartObject enables the K2 Designer to use the methods available from the Service Object.

When the SmartObject is created, all existing or default methods of a new SmartObject are replaced by the methods created for the Service Object.

Service Objects are only published to the default service object repository as hosted by the default K2 connect Service instance. When more than one K2 connect Service instance is listed in the Service Object Repository, publishing will always be to the one selected as default.

Service Objects are always published to the default service object rRepository. The default service object repository is determined by which K2 connect Server is the default server. The default K2 connect server is dependent on how the infrastructure has been configured, and whether there are multiple standalone servers or a clustered configuration.

The Service Object repository is not the same as a Destination.

The Service Object repository is the location where the Service Objects are published to. The repository can be administered from the K2 Administration Tool or from the Object Browser in K2 Designer for Visual Studio. The Service Objects can only be consumed by SmartObjects, which can then in turn be consumed by application elements like Workflows, Reports or Forms.

The Service Objects are hosted by the default application, which enables other users developing against the same K2 connect Service instance to share the published Service Objects. The Service Objects, when published are always published to the default K2 connect Service instance which may be either a stand alone K2 connect Server of a cluster of K2 connect Servers.

The manner in which a service object is added to the service object repository will affect it's availability.

Menu Item Description
Show Entity Documentation Displays any documentation which was included with the service object from the K2 connect for SAP Administration Tool.
Remove Entity from Repository Removes the selected item (service object) from the repository *.
Duplicate Entity Creates a copy of the selected item, for later changes.
Modify Entity Modifies an existing entity, see Duplicate Entity above.
Perform Delta Check Performs a consistency check on the ServiceObject, this may be useful for when a ServiceObject is a copy or an update of a previous or an existing version.
Publish as Service Object If a Service Object was added manually or is a duplicate, it may need to be published so that it can be added to the SmartObject service as a Service Object. This feature does not apply to Service Objects published directly from K2 Designer for Visual Studio.
* Even though an item has been removed, there may still be remnants of the item present which will cause a reference to the service object to appear in the K2 Administration tool and the K2 SmartObject browser. A refresh of the K2 connect Service and the K2 SmartObject service may be required to completely remove the entity.

In the case of a distributed environment, there may be more than one SAP instance and therefore multiple K2 connect service instances listed under the Service Object Repository. A Service Object is always published to the Default Service Object Repository and the default server is only default relative to the client and is set by the client; there is no global or system setting that defines which server is the default server.

As shown in the image below, two K2 connect instances are listed. The image illustrates that:

  1. Default (BPDEV1) this is the default K2 connect service instance.
  2. BPHOST1 (Non default - no publishing against this server can currently take place).

You can publish to an alternate server, by setting the alternate server to default. To change the default server do the following:

  1. Right click on the server that will be set to the default server.
  2. Locate the option Set as Default.
  3. Select the option.
  4. Note that the default server has changed.

You can now publish service objects to the new default server.

Permissions are required when a service object is published to the service object repository, and the ability to publish successfully will depend on the network configuration. Stand alone systems won't encounter errors related to network related permissions. However, in distributed environments, after the service object has been published a remote server, a restart of the K2 connect service is required. For this to take place your user account would require Administrative permissions on the K2 Server. In some organizations for security reasons this level of permissions may only be reserved exclusively for Administrators.

As a work around to this, the following Microsoft article is available for use in establishing group policies How to grant users rights to manage services in Windows Server 2003

A security label for a K2 connect Server instance is only available from the User Preferences page after a Service Object has been published to it. The K2 Server must be restarted manually after publishing the Service Object.

The publishing a process creates a file of type SVD, and publishes the Service Objects to a repository. Before publishing, the Service Object will be checked for any service related errors that would prevent the Service Object from functioning. When no errors are found the Service Object is published to the default repository and is available for use via the SmartObject broker in the object library.

The processing window as shown below illustrates what takes place, from the user's point of view. Once the Publish Service Object command is clicked, the Service Object is interrogated for any errors. When non are found, the Service Object is published. From the server and service side, the Service instance is refreshed and the K2 connect Server is restarted.

Any major changes that affects the K2 connect server or service instance requires that they be refreshed or restarted.

Once the process is complete, the completion message will display as below. Click OK to proceed.

If the K2 connect for SAP service instance is running locally, then the Service Object can be published locally. However since the K2 connect service is running on the K2 Five server, this means that the default repository would must likely be a remote location. This does not necessarily pose a problem unless the K2 connect service is not running or there are network connectivity issues; at both design and run time.

The K2 Server must be restarted when a Service Object is published to a destination for the first time.

Service Objects are published once they have been completed to the Service Object Repository. The SOR is a public location; public in the context that any developer that has access rights to that particular service instance will be able to consume, delete or edit the published object.

Published service objects can be moved between SOR instances. However, they can only be moved in one direction, namely from any SOR to the default SOR. Service objects cannot be moved in the opposite direction from a default SOR to any other SOR.

For further information on publishing Service Objects to different environments, see the following knowledge Base Article : Deploy service object to different environments, or copy and paste the following link into your browser : http://help.k2.com/en/articles/kb000345.aspx.

When a Service Object is published, the user has the option to create a SmartObject automatically as part of the process. When the Service Object has the same name or the same Service Object has already been published to the Service Object repository, the following user dialog will appear to manage publishing the new Service Object.

Dialog Options Description
Do not create SmartObject The SmartObject will not be created.
Create the SmartObject with the following name The SmartObject will be created but with a new name.
Name A custom name entered by the user.
Related Topics