This article has been archived, and/or refers to legacy products, components or features. The content in this article is offered "as is" and will no longer be updated. Archived content is provided for reference purposes only. This content does not infer that the product, component or feature is supported, or that the product, component or feature will continue to function as described herein.
Once the K2 connect environment has been setup and configured, the Service Object developer then selects the Default destination against which the service objects are developed. The destination that is used affects the life cycle of the service object from development to publishing into the production environment.
The purpose of this KB is to discuss, at a high level the options that the service object has when developing service objects.
A destination is a logical connection to a backend system. For K2 connect, the destination is a logical connection to a SAP instance. When developing a service object, the development environment needs to be aware of a SAP instance or destination to which BAPI calls can be made. The K2 connect service object designer requires that a default destination be identified. The default destination is user configured, i.e. the user selects which destination to be used as the default and is dependent on which BAPIs the service object needs to do its job.
|Note: An in-depth discussion of BAPIs (methods, structure, etc) is beyond the scope of K2 connect’s documentation. Please refer to the relevant SAP documentation for further details.|
Shown in the image is an example environment that has two destinations. The destinations are a mirror of each other. This example is intended to typify a Dev to Production method of development where the development environment mirrors the production environment.
Deploying Service Objects to different Destinations
Service Objects can be deployed into different environments so long as the following requirements are met:
- The BAPIs availability must be identical
- They have access to a destination that is similar to the original
Why a default Destination ?
The default Destination determines which environment the service object runs against. If, as shown in the image, two similar environments exist side by side Development and Production then publishing service objects to a different environment requires that the Default environment selected be changed. Once the
new default environment is selected, the service object can be published to the new environment.
An important factor is that when you publish your Service Object to another server than the one in your current environment (dev), you will have to refresh the service instance on the prod environment manually as the designer will only refresh the current environment service instance. Also, the default destination
on your current environment (dev) should be configured to your dev SAP instance, and the default destination on your prod environment should be configured to your prod SAP instance.
|Note: The default server determines the K2 connect Repository the Service Object will be published to.|
How to change the default K2 connect destination
The default destination is set by the user, and can be reconfigured at any time. The default destination can be altered from the Destination Explorer or from within K2 Designer for Visual Studio. To change the
default from the destination explorer, follow the steps below:
- Open the K2 Destination explorer
- Select an existing destination but one whose name is NOT IN RED. Red identifies the destination as the default destination.
Right click on the destination and select "Set as Default Destination"
|Note: If the destination required does not exist, then it must be added as a destination before these steps can be followed.|
- Refresh you service instance for your K2 connect server. This must be done from the following location: K2 connect Administration > K2 blackpearl Settings. When done from the administration tools, this automatically stops and starts your K2 connect server before refreshing the service instance. This is required because a security label is required for the destination instance.
|Note: The method described above only applies to standard BAPI’s i.e. the BAPI must be accessible from the initial destination as well as the reconfigured one.|