best practices guide - customer extension points

Best Practices Guide

SAP NetWeaver Landscape Virtualization Management 1.0

SP05 Document Version: 1.0 – 2012-11-12

CUSTOMER

Customer Extension Points

2

Error! Reference source not found.

© 2012 SAP AG. All rights reserved.


Typographic Conventions

Typographic Conventions

Type Style Description

Example Words or characters quoted from the screen. These include field names, screen titles,

pushbuttons labels, menu names, menu paths, and menu options.

Textual cross-references to other documents.

Example Emphasized words or expressions.

EXAMPLE Technical names of system objects. These include report names, program names,

transaction codes, table names, and key concepts of a programming language when they

are surrounded by body text, for example, SELECT and INCLUDE.

Example Output on the screen. This includes file and directory names and their paths, messages,

names of variables and parameters, source text, and names of installation, upgrade and

database tools.

Example Exact user entry. These are words or characters that you enter in the system exactly as they

appear in the documentation.

<Example> Variable user entry. Angle brackets indicate that you replace these words and characters

with appropriate entries to make entries in the system.

EXAMPLE Keys on the keyboard, for example, F2 or ENTER .


Document History


© 2012 SAP AG. All rights reserved. 3

Document History

Version Date Change

1.0 2012-11-12 Initial Version

4




Table of Contents

Table of Contents

1 Abstract ........................................................................................................................................................... 5

2 LVM High Level Architecture ........................................................................................................................ 6

3 SAP Host Agent .............................................................................................................................................. 8

4 Custom Operations and Hooks .................................................................................................................. 10 4.1 SAP Host Agent Registered Scripts ..................................................................................................................... 10 4.2 HTTP Post Provider Implementation ................................................................................................................... 12 4.3 Web Service Provider Implementation ................................................................................................................ 12 4.4 Summary ................................................................................................................................................................ 13

5 Custom Validations ...................................................................................................................................... 14

6 Custom Services ........................................................................................................................................... 15

7 User Exits....................................................................................................................................................... 18

8 Custom Links ................................................................................................................................................ 19

9 Customer Extensibility of Partner Libraries ............................................................................................ 20

10 Appendix ........................................................................................................................................................ 21 10.1 Largest System Tree ............................................................................................................................................. 22 10.2 Syntax of the Configuration Files ......................................................................................................................... 23

10.2.1 Command block .................................................................................................................................... 23 10.2.2 Command line ....................................................................................................................................... 23

10.3 Web Service Provider Implementation WSDL .................................................................................................... 23


Abstract



1 Abstract

SAP Netweaver Landscape Virtualization Management (LVM) provides the customer with the ability to manage

his on premise SAP System Landscape in a virtualized and cloud environment. It allows the SAP Basis

Administrator to start, stop, relocate, and monitor his systems (basic functionality). In the management of an SAP

Landscape often the need comes up to extend basic management tasks (for example hardware maintenance)

with specialized functionality. In that paper we describe the existing extension points1 the landscape virtualization

management (LVM) provides to the customer to extend the LVM operations and functionality without modifying

the LVM code base.

1 I am only referring to the corresponding concept of eclipse „extension point’s” there is no other similarity.

6




LVM High Level Architecture

2 LVM High Level Architecture

In the picture below you see a high level architecture of LVM. The parts that play a role in the customer

extensibility are emphasized in green.

The LVM is an application for the SAP basis administrator to manage a large on premise SAP system landscape. It

provides the system administrator with a high-level system overview and high level monitoring data of the SAP

systems and instances he has to manage. The LVM allows in its basis functionality the (mass) starting and

stopping of SAP systems (including the databases). The LVM ensures by starting and stopping in the correct

order that an SAP system can also be started after stopping. To be able to do that the status of all system

components is always monitored and certain constrains are validated continuously. These monitoring data

together with the configuration data that determine the services (SAP Systems are made up out of services (see

below)) and resources (an OS) make up the core model of the LVM. The configuration data can either be detected

via the host and instance agent from the physical (virtual) landscape or can be detected from the SLD. The

configuration data are then stored in an own DB.

The LVM has also the ability to work with Virtualization monitors that abstract various virtualization technologies.

Over registered virtualization managers the LVM sees virtualization providers (hypervisors) and virtual machines

that are managed by these providers. These virtual machines become then visible in the LVM as resources.

Productive SAP systems are normally installed on central storage. The LVM contains also the necessary

configuration data to manage SAP systems that are installed on central storage. In its simplest form that means

that the LVM configuration of the corresponding system contains the necessary mount data and export points

from the central storage.

That knowledge enables the LVM also to copy and clone SAP systems stored on central storage by directly

interfacing with the corresponding storage managers.

With the corresponding SAP system the LVM communicates via the host and instance agent that run on each

resource where a SAP might run or runs. The SAP Host Agent is the entry point for most of the customer

extension points. (More details see the chapter over the SAP Host Agent). The necessary configuration data of

these customer extensions is also stored in the DB.

The LVM user interacts directly either via custom operations with an SAP system or via certain well defined RFC

calls or via a process that is created as a consequence of an operation. The process execution takes care of

certain interdependencies between process steps.

Last but not least the LVM processes external interfaces that allow the execution of all existing functionality via

web services so allowing automation of the landscape. In the other direction the customer can provide customer

implementations of a web service provider (see below) or a simple HTTP service.


LVM High Level Architecture



Figure 1 High Level LVM overview

The LVM provides in addition to the customer extension point’s, extension points for partners e.g. providers of

virtualization technologies or storage technologies, these extension points will not be discussed here, they allow

partners to provide implementations of adapters of their technology to the LVM, e.g. storage, DB, virtualization.

This was a quick run through of the all components of the LVM as shown in the picture. For more details and the

used terminology see the official LVM help at help.sap.com (See references below).

In the following we will describe the existing customer extension points of the LVM. Since the functionality of these

extensions depend to a good part on a core component of the LVM that runs on each host of an SAP system, we

will describe that component, the SAP Host Agent first.

SAP landscape virtualization management (LVM) Config Data

Service Manager

Service

Registry

Resource Manager

Resource

Registry

Virtualization

Manager

Service

Registry

Monitoring & Validation Manager

Monitoring Cache

Controller

Process Manager

Pro

ce

ss

Qu

eu

e

Service

Config

Basic

Config

Resource

Config

Virtualization

Config

R R R

R R R

Validation Cache

Landscape

Administration

Configuration /

DetectionAuthorizationCap. Mgmt.

Alerting /

Reporting

Provisioning

(Copy, Clone,

DI)

Managed Resource (Physical / Virtual)

Virtualization

Manager

R

monitor / validate / operate

Virtual Landscape

HostAgentSAP Instance

R

controls

(if virtual)

R

controlsInstance Agent

Instance

R-monitor / validate

instance

-detection

Database /

Custom Service

R controls /

monitors

R

-monitor / validate

DB & CustSrv

-operate

-detection

R controls

SAPInst /

Custom Ops.

R executes

R

installs /

modifies

R

modifies

R

modifies

Step Executor

External Tool /

3rd party application

System Landscape

Directory (SLD)

R

UI

R

CCI

(Web Service)

R

landscape

detection

(optional)

External Tool /

3rd party application

R

before /after

step

(HTTP)

Alerts

Central Storage

Management

Central Storage System

Volume /

LUN

Volume /

LUN

Volume /

LUN

R

clone / copy

storage

(SSC / SMI-S)

R

clone / copy

LUN / Volume

Custom Ops &

Hooks

R

-execute ABAP

post syscopy &

Refresh

-execute RFCs

CustOpsCentral

nameserver /

user store

R

retrieve

data

CustSrvUserExits

LM Runtime /

Automation

Java EE Post

System Copy

Content

Java EE

Refresh

Content

R execute

8




SAP Host Agent

3 SAP Host Agent

The SAP Host Agent is a central component that must run on each host were a SAP System might run. It is part of

the SAP Netweaver Management Agents. The core functionality of the SAP Host Agent is to provide the ability to

control SAP Systems and their databases that run on the given host and to provide information about the host to

various other SAP applications. Therefore the SAP Host Agent has a WebServices (WS) interface that can be used

by these clients. The SAP Host Agent runs on port 1128 and therefore the WSDL of the SAP Host Agent can be

fetched by executing: http:// <hostagent_host>:1128/SAPHostControl/?wsdl.

For executing his tasks the SAP Host Agent uses other helper agents as there are:

saposcol:

Runs as a hung up process on its own after started by the SAP Host Agent.

Collects OS information that can be used by other SAP Monitoring Software.

sapacosprep:

Used by the SAP Host Agent to attach and detach new SAP instances or Databases to the host. Only actively

used during operation execution of the SAP Host Agent.

sapdbctrl:

Used by the SAP Host Agent to control the databases of SAP systems that run on that host. Only actively

used during operation execution of the SAP Host Agent.

sap instance agent:

Running as own process per SAP instance under the corresponding sap<SID> user. The instance agent itself

controls and monitors its SAP instances running on the same host. The instance agent itself has its own WS

interface to control and monitor SAP instances and can be analyzed by using the URL:

http://<instance_host:5><Instance_Number>13/SAPControll/?wsdl

custom operations:

Only actively used during operation execution of the SAP Host Agent.


SAP Host Agent



Figure 2 SAP Host Agent framework components

It is important to notice that there is no one to one relation between an SAP System and a host, in most realistic

scenarios that is not the case, on a host you can often have instances from different SAP systems running there

with or without a database on the same host, you can even have multiple databases from different SAP systems

running on the same host. You can even have a dynamic environment where you move SAP instances and or SAP

databases from one host to another. You can find much more detailed information about the SAP Host Agent in

the references below. I only wanted to give you a high level understanding of the architecture of the SAP Host

Agent framework.

The important point for customer extensions is that the SAP Host Agent (saphostexec) runs as “root” on the local

machine and can execute arbitrary “custom operations” on the host. This gives the administrator a lot of flexibility

to automate his landscape via the existing interface of the SAP Host Agent. This flexibility is then of course

immediately used by LVM to provide the customer with the “custom operations” extension points (see below).

References

SAP Netweaver Landscape Virtualization Management at help.csap.com

Infrastructure of the SAP NetWeaver Management Agents

TCPIP Ports used by SAP Applications

host of sap system and instances

saphostcontrol saphostexec

sapstartsrv

R

Local Socket

saposcol

sapacosprep

sapdbcrtl

R

R

R

R

Controlls &

Monitors

custom

operations

R

Runs as sapadm

Runs as root or

„Local System

Account“

SAP instance

R controlls

Runs as sap<SID>

respectively

SAPService<SID>

user

R

R

registers/starts

http://help.sap.com/saphelp_lvm10enterprise/helpdata/en/4e/3134de31fd537be10000000a15822b/frameset.htm

http://help.sap.com/saphelp_nw73ehp1/helpdata/en/44/86b14bcc8812d2e10000000a422035/content.htm

10




Custom Operations and Hooks

4 Custom Operations and Hooks

Custom operations and hooks are callbacks that are executed in different contexts and by different agents and

that must be provided by the customer. If the customer has implemented his logic he can configure these

callbacks in the LVM so that they can be executed by the LVM.

Custom hooks are executed during the process execution and custom operations are executed by the user when

viewing a specific system/service/resource.

There exist 3 different possible types of callbacks (provider implementations) that can be configured in the LVM

1. SAP Host Agent Registered Scripts (aka Custom Scripts)

2. HTTP Post Service

3. WebService

In the configuration of the LVM you first provide the definitions of your existing provider implementations and

enable your functionality as callback for custom operations or custom hooks. In addition to that you declare if the

functions should be called in the context of an operation/hook and executed for a service and/or a resource. This

defines the “what” will be executed in addition to that you must configure the “when or if” a custom

operation/hook will be executed i.e. you define constrains that must be fulfilled before you can execute (or the

hook will be executed) the operation for a specific entity type. For an operation the user defines the event and the

context for which a custom operation will be executed. For a hook the event type (event type means here that a

certain operation type is executed) for which the hook will be executed must be defined, then for each event type

you can define if the hook is executed as a pre_event, post_event or error_event hook.

In addition to that constrains can be formulated in a simple declarative manner in the configuration and must

evaluate to true otherwise the operation will not be visible or the hook will be skipped for the corresponding event

and entity type. (See references)

So far we have been talking about the generic mechanisms and configuration that underlay all custom operations

and hooks. Now let’s detail on the three different provider types.

4.1 SAP Host Agent Registered Scripts

These are scripts that are executed on the hosts where they are registered. Registering just means storing a

*.conf file that defines the operations available on the given host in a certain location.

The configuration files must be placed in the operations.d/ sub folder of the exe/ folder of the SAP Host Agent.

The scripts are referenced from the configuration files and can be placed anywhere. The communication channel

between the SAP Host Agent and the script are stdout and stdin. The scripts will normally run under root, under

Linux you can specify the user. In addition to that the *.conf file will contain parameters (For details see appendix

section: Syntax of the Configuration Files) in the command line that is handed over to the command executor of

the corresponding operation system i.e. the bash or cmd. These parameters are expanded during runtime to the

current values of the context of the SAP Host Agent.





Figure 3 Components of custom scripts that are called as custom operations/hooks

The files must be owned by and only be modifiable by the sapadm/sapsys user/group. In SAP Note 1465491 you

find an example of an SAP Host Agent registered script that can be used as a custom operation.

@Resource mechanism

As explained above the location of the configuration files of a specific custom operation are bound to the host for

that the user triggers the custom operation. This might be useful for scripts that should modify or collect data

from the given host that has the focus during the operation. But you can think of operations that must not be

executed on the host that has currently the focus but just need all the context information of the current host and

can be executed (or must be) on another host.

For that case we have the <operationname>@<resourcename> mechanism that executes the SAP Host Agent

operation on the resource with the name <resourcename> as if it would be executed on the host that has

currently the focus of the custom operation (hook). All what is needed, is to configure the host (resource)

<resourcename> in the LVM (there are other mechanism to configure necessary connection information but

these technical details can looked up in SAP Note 1465491). Then you configure the custom operation name in the

form <operationname>@<resourcename>. As a consequence the custom operation (hook) will be executed on

the resource <resourcename> instead of the current host.

host

Host agent Custom Script A

/operations.d/operationAConf.conf

stdin/stdout

R

User or process

R

context information

WS

Binaries

12





Figure 4 Overview diagram of the @ mechanism

4.2 HTTP Post Provider Implementation

Inside the LVM you can configure a HTTP Post Provider that executes an HTTP Post call to a specified URL

furnished with context parameters that are specific to the entity type that currently has the focus in the LVM. The

call is a synchronous call and the service provider implementation can provide a text/plain mime type response

that is recorded in the operations log.

4.3 Web Service Provider Implementation

In principle similar to the HTTP Post Provider implementation this provider type is richer in its semantics due to a

predefined WSDL file that can be used to generate the necessary skeletons and stubs. The WSDL can be

downloaded from the LVM when you configure a new web service provider definition. For details of the WSDL see

section Web Service Provider Implementation WSDL.

Host Z

Host A



stdin/stdout

R

Execute Custom Op A on

resource A

R

context information

WS

Binaries

Host Excecutor



stdin/stdout

R

Binaries

R





4.4 Summary

Custom operations and hooks provide a very flexible way to enhance the LVM functionality and to provide an

“outside-in“integration of the LVM. i.e. you can integrate arbitrary outside services like a central landscape

database into the LVM by the mean of custom hooks e.g. This rounds off the inside-out integration capabilities of

the LVM via its web services interfaces.

References

SAP Note Link

1465491

Provider Implementation Definition

https://service.sap.com/sap/support/notes/1465491

1550099

Additional Host Agent Operations for ACC/SAP

Net weaver LVM


1467759

Constraints for Custom Operations/Hook in ACC

7.30





14




Custom Validations

5 Custom Validations

In addition to be able to define the “what” and “when” of custom operation you can also define for what the result

of a certain custom operation will be used at least to some extent.

Normally the output of custom operations is read from the standard out and shown in the corresponding

operations log of the LVM. Here the custom operation has the ability to return the success of the operation via

special formatting of the output (see references) and of course the return value of the process after execution

(return value >0 indicates an error).

That result can also be used as validation result for services and resources. You specify if a certain custom

operation will become a custom validation in the configuration of the custom operation. After that the validation

frame work of the LVM takes care of the regular execution of the custom operation as validation of the

corresponding entity type and the recording of the result of the operation as validation result.


Custom Services



6 Custom Services

Each SAP system can be seen as a service tree (composite-component pattern) of services where you can have

start stop dependencies between services.

Figure 5 The core service class model of the LVM

In the picture below a simple example of a standard SAP is shown. Here the database(s) must be started first, in

parallel the ERS(s), then the Central Instance must be started in parallel with the SCS(s) and last but not least the

dialog instances.

serviceparent

*

starts-before

children

parent-child

16




Custom Services

Figure 6 A simplified service tree of an SAP system as it is seen and processed by the LVM (including custom services) The

custom dependencies that can be configured between cutom services and the other are not depicted.

SAP System

Release 7.3

Database Instance Set0..1

1

System DB Instance0..1

1

Diagnostic Agent Set

Diagnostic Agent1..*1

0..1

1

ERS Instance Set0..1

1

ABAP ERS Instance

Java ERS Instance

*1

*

1

Shared ERS Instance*

1

SCS Instance Set

ABAP SCS Instance

Java SCS Instance

0..11

0..1

1

Shared SCS Instance0..1

1

0..1

1

Central Instance

(ABAP, ABAP/Java)

Dialog Instance Set

Dialog Instance

(ABAP, Java, ABAP/Java)

1..*1

0..1

1

Custom Service Set

Custom Service1..*1

0..1

1

0..1


Custom Services



In real live it happens often that the SAP system is run together with other no SAP systems not managed by the

SAP Netweaver Agent Framework. Now it would be good if these “custom services” could be added to the LVM

and so managed together with the main SAP system the “custom services” belong to. To enable the customer to

do that the concept of custom services was introduced.

A custom service is just another “none” SAP service that must be started and stopped together with a particular

SAP System. E.g. it might be an Apache that is used for some customer specific system configuration.

The idea to solve that problem is again to wield the weapon of custom operations i.e. you must configure special

scripts and configuration files (*.conf) on a given host that define which types of custom services might run on the

given host and which basic operations you want to execute on a given custom service that runs on that host.

There are four core operations that can be executed:

1. Detect (Find the corresponding custom services on the host)

2. Start/Stop (the corresponding custom services on the host)

3. Monitor (the corresponding custom services on the host)

4. Attach/Detach (the corresponding custom services from the host)

And two additional operations: “Validate” and “Getproperties”.

Figure 7 A custom service type is defined by a set of scripts

I. e. for each type of custom service and operation you provide a configuration file that tells the SAP Host Agent

how to interact with the custom functionality. The custom functionality defines the custom services and the

operations that can act on these custom services. In each case the SAP Host Agent executes just a custom

functionality and the information how to do that is defined in some *.conf files on the host. The syntax is similar to

the syntax that defines “custom operation” so look in that chapter for more details. The only difference is that the

result of the custom operations is interpreted in some specific way whereas the results in the general case are just

recorded / logged.

References

SAP Note/Document Link

SAP Note 1396981

Custom Services Configuration for ACC


Business Objects Enterprise Server as Custom

Service

Integration of a Business Objects Enterprise System in

the Adaptive Computing Controller.pdf

CustomServiceType

acc_<customServiceType>_list.conf

acc_<CustomServiceType>_monitor.conf

acc_<CustomServiceType>_start.conf

acc_<CustomServiceType>_stop.conf

1

1

1

1

0.1

0.1

1


18




User Exits

7 User Exits

User exits are executed as hooks (pre, post, and error) of a certain well defined set of SAP Host Agent operation

types. So they are a less generic kind of custom operations or hooks. The main difference to the generic custom

operations/hooks is that they are only executed by the SAP Host Agent directly on the host and only as part

(hook) of an operation triggered by a process step execution of LVM.

With respect to the configuration and execution semantics they are basically SAP Host Agent registered scripts

but their configuration files are stored in the hooks.d/ folder instead. So they are configured different than the

older still supported user exist concept of the SAP Host Agent were you configured the hooks in the SAP Host

Agent profile (see references). The SAP Host Agent detects the hook configurations by himself (compare old

hooks, see references), no restart of the SAP Host Agent is needed. The concept of operation types, hooks and

configuration files is described in the diagram.

Figure 8 An operation config file defines a specific hook for an operation type

The syntax of the configuration files is the same as the syntax of the configuration files of the custom operations.

The ResultConverter is always “hook” therefore you don’t need to specify that. For details of the syntax see SAP

Note 1347299 and 1465491.

References

SAP Note Link

1347299 New User Exits in SAP Hostagent https://service.sap.com/sap/support/notes/1347299

1306616 User exits in SAP Hostagent 7.10 and 7.11 https://service.sap.com/sap/support/notes/1306616

OperationType HookType1 1..3

1

0..n OperationConfigFile

1

0..n




Custom Links



8 Custom Links

Custom links are similar to custom operations when the provider implementation is an HTTP Post Provider. The

difference is that the command is an URL that is resolved by the browser as an agent. I.e. the control is handed

over to the standard browser. The URL can again contain variables that are expanded depending on the entity

type (service or resource) that has the focus. For details of the syntax of the URLs see the appendix.

The custom links will be displayed parallel with the custom operations in addition to the difference already

mentioned is the fact that the custom operations are executed as an operation in a process step and remain

under control of the LVM.

The custom links are often used to open e.g. the SAP MC for a specific SAP application server to drill further into

the instance. But in addition to that a custom link can do for you everything the browser will do for you when

resolving a URL e.g. opening another application via the mime/type activation framework.

References

SAP Note Link

1527599

Custom Links to RDP, SSH and SAP Logon within ACC



20




Customer Extensibility of Partner Libraries

9 Customer Extensibility of Partner Libraries

In the SAP Host Agent chapter we saw that the SAP Host Agent utilizes helper libraries to manage the host

environment of the sap instances. In particular there are the

sapacosprep library to manage OS resources as mounts, ip addresses, firewalls

sapdbctrl library to manage DB instances on the given host

The core idea behind these libraries is that they provide an storage/OS/DB independent interface towards the

SAP Host Agent to manage these entities. In particular the sapacosprep library loads then OS/storage technology

dependent libraries that must then be provided by technology partners. This type of “partner extensibility” has so

far not been the focus of this paper. Due to the fact that this process is pain full slow we have given the customer

(may be also a technology partner) the ability to provide the “sapacosprep” functionality via “custom scripts”

pretty similar to the mechanisms you have already seen.

In detail you have to do the following to provide or overwrite the sapacosprep functionality:

You follow the ideas already described under SAP Host Agent Registered Script.

The sapacosprep library provides a set of OS/storage partner independent commands that are executed by the

SAP Host Agent. Now you just provide per command you want to overwrite/provide (if missing) a <command-

name>.conf file in the operations.d/sapacosprep folder. The commands that are defined in that configuration file

will be executed instead of the partner or OS dependent library normally called by the sapacosprep library. Details

and examples of the interfaces of the supported commands can be found in the SAP Note 1685728.

References

SAP Note Link

1685728

Script Implementation of sapacosprep Library Functions




Appendix



10 Appendix

22




Appendix

10.1 Largest System Tree

Figure 9 The largest possible system tree that can be handled by the LVM

SAP System

Release 7.3

Database Instance Set0..1

1

System DB Instance

IMCE Instance

0..11

0..1

1

LiveCache Set0..1

1

LiveCache 1..*

1

Other DB Set

Other DB1..*

1

0..1

1

Diagnostic Agent Set

Diagnostic Agent1..*

1

0..1

1

MDM Server Set

MDM Server1..*

1

0..1

1

MDM SyndicationServer

MDM Layout Server

MDM Import Server

0..1

1

0..1

1

0..1

1

Gateway0..1

1

Web Dispatcher Set

Web Dispatcher*

1

0..1

1

ERS Instance Set0..1

1

ABAP ERS Instance

Java ERS Instance

*1

*

1

Shared ERS Instance*

1

SCS Instance Set

ABAP SCS Instance

Java SCS Instance

0..11

0..1

1

Shared SCS Instance0..1

1

0..1

1

TREX Server Set

TREX Server1..*

1

0..1

1

Central Instance

(ABAP, ABAP/Java)

0..1

1

Dialog Instance Set

Dialog Instance

(ABAP, Java, ABAP/Java)

1..*1

0..1

1

Custom Service Set

Custom Service1..*

1

0..1

1


Appendix



The picture show the largest possible system tree i.e. the most generic object diagram of possible SAP systems

that can be handled by the LVM.

10.2 Syntax of the Configuration Files

The configuration files are simple text files in the following format:

There might be multiple command blocks in a config file, all blocks are executed one after the other till the first

command fails indicated by a return code != 0. A command block looks like that.

10.2.1 Command block

Name: NAME (required)

Mode: async/sync (optional)

Command: COMMANDLINE (required)

Description: DESCRITPTION (optional)

WorkDir: DIR (optional, working directory of the command)

Plattform: Windows|Unix (optional, filters the command blocks effectively for different platform’s. That allows you

to place the commands for all platforms into one config file)

In case of multiple command lines all commands are executed in sequence till the first command returns an error

(return code >0). The commandline is structured as follows:

10.2.2 Command line

Commandline: ABSOLUTE_PATH ( $[Parameter])*;

Parameter: PARAMETER_NAME(#MODIFIER)*

Parameters can have multiple modifiers that determine from where the parameters will be fetched by the SAP

Host Agent and handed over to the script. For details which parameter names are available see SAP Note

1465491.

10.3 Web Service Provider Implementation WSDL

The linked WSDL shows the simple interface that must be implemented.

24




Appendix

Figure 10 The WSDL as seen in the eclipse WSDL graphical editor

So there are execute operations

executeCustomOperations* for services and resources

executeCustomHooks* hooks for services and virtual resources

and an operation to get the results asynchronously given the operation id.

getResults

All operations return a CustomOperationResult as return message:

Figure 11 The standard return message of the custom operation WSDL as seen in the eclipse graphical WSDL editor

All execute operations take the same generic operation name and operation properties as arguments and

additional operation specific information e.g. (Service) depending on the operation.

What the operation does or when it is executed can be more or less read from the name of the operation. For more

details see the linked WSDL.

All operations can be executed synchronously or asynchronously depending on the configuration.

www.sap.com/contactsap

Material Number


No part of this publication may be reproduced or transmitted in any

form or for any purpose without the express permission of SAP AG.

The information contained herein may be changed without prior

notice.

Some software products marketed by SAP AG and its distributors

contain proprietary software components of other software

vendors.

Microsoft, Windows, Excel, Outlook, and PowerPoint are registered

trademarks of Microsoft Corporation.

IBM, DB2, DB2 Universal Database, System ads, System i5, System

p, System p5, System x, System z, System z10, System z9, z10, z9,

iSeries, pSeries, xSeries, zSeries, eServer, z/VM, z/OS, i5/OS,

S/390, OS/390, OS/400, AS/400, S/390 Parallel Enterprise

Server, PowerVM, Power Architecture, POWER6+, POWER6,

POWER5+, POWER5, POWER, OpenPower, PowerPC, BatchPipes,

BladeCenter, System Storage, GPFS, HACMP, RETAIN, DB2

Connect, RACF, Redbooks, OS/2, Parallel Sysplex, MVS/ESA, AIX,

Intelligent Miner, WebSphere, Netfinity, Tivoli and Informix are

trademarks or registered trademarks of IBM Corporation.

Linux is the registered trademark of Linus Torvalds in the U.S. and

other countries.

Adobe, the Adobe logo, Acrobat, PostScript, and Reader are either

trademarks or registered trademarks of Adobe Systems

Incorporated in the United States and/or other countries.

Oracle is a registered trademark of Oracle Corporation.

UNIX, X/Open, OSF/1, and Motif are registered trademarks of the

Open Group.

Citrix, ICA, Program Neighborhood, MetaFrame, WinFrame,

VideoFrame, and MultiWin are trademarks or registered trademarks

of Citrix Systems, Inc.

HTML, XML, XHTML and W3C are trademarks or registered

trademarks of W3C®, World Wide Web Consortium, Massachusetts

Institute of Technology.

Java is a registered trademark of Sun Microsystems, Inc.

JavaScript is a registered trademark of Sun Microsystems, Inc.,

used under license for technology invented and implemented by

Netscape.

SAP, R/3, xApps, xApp, SAP NetWeaver, Duet, PartnerEdge,

ByDesign, SAP Business ByDesign, and other SAP products and

services mentioned herein as well as their respective logos are

trademarks or registered trademarks of SAP AG in Germany and in

several other countries all over the world. All other product and

service names mentioned are the trademarks of their respective

companies. Data contained in this document serves informational

purposes only. National product specifications may vary.

These materials are subject to change without notice. These

materials are provided by SAP AG and its affiliated companies ("SAP

Group") for informational purposes only, without representation or

warranty of any kind, and SAP Group shall not be liable for errors or

omissions with respect to the materials. The only warranties for SAP

Group products and services are those that are set forth in the

express warranty statements accompanying such products and

services, if any. Nothing herein should be construed as constituting

an additional warranty.

best practices guide - customer extension points

Documents

volume lun

shared scs instance

shared ers instance

java scs instance

java ers instance

http post provider

sap basis administrator

sap systems running