Automation - Engine APPLICATION INTEGRATION GUIDE en PDF

Automation Engine 11
ONE Automation Platform
Application Integration
Guide
Version: 11.2.2
Publication Date: 2016-10
Automic Software GmbH
ii Copyright
Copyright
Automic® and the Automic logo® are trademarks owned by Automic Software GmbH (Automic). All such
trademarks can be used by permission only and are subject to the written license terms. This
software/computer program is proprietary and confidential to Automic Software and is only available for
access and use under approved written license terms.
This software/computer program is further protected by copyright laws, international treaties and other
domestic and international laws and any unauthorized access or use gives rise to civil and criminal
penalties. Unauthorized copying or other reproduction of any form (in whole or in part), disassembly,
decompilation, reverse engineering, modification, and development of any derivative works are all strictly
prohibited, and any party or person engaging in such will be prosecuted by Automic.
No liability is accepted for any changes, mistakes, printing or production errors. Reproduction in whole or
in part without permission is prohibited.
© Copyright Automic Software GmbH. All rights reserved.

Automation Engine iii
Contents
1 CallAPI 1
1.1 About the CallAPI 1
1.2 Using the CallAPI 1
1.3 Platforms for CallAPIs 3
1.3.1 CallAPI for BS2000 3
1.3.2 CallAPI for GCOS8 5
1.3.3 CallAPI for Java 6
1.3.4 CallAPI for NSK 7
1.3.5 CallAPI for z/OS 7
1.3.6 CallAPI for OS/400 8
1.3.7 CallAPI for SAP 9
1.3.8 CallAPI for UNIX 10
1.3.9 CallAPI for VMS 11
1.3.10 CallAPI for VSE 11
1.3.11 CallAPI for Windows 12
1.4 Using CallAPI with Your Own Programs 12
1.4.1 C, C++ 12
1.4.2 Cobol 15
1.4.3 Java 17
1.4.4 Visual Basic 19
2 Program Exits 21
2.1 Password Exit 21
3 Rapid Automation 24
3.1 Rapid Automation 24
4 AE.ApplicationInterface 26
4.1 Introduction 26
4.2 Using this Interface 27
4.3 Guide to Using the AE.ApplicationInterface 27
4.4 Object Classes 28
4.5 Classes for Workflows and Schedules 30
4.6 Classes for Activities 32
4.7 Classes for Statistics and Reports 33

iv Contents
4.8 Classes for the System Overview 35
4.9 Starting and Stopping Clients by using the Application Interface 35
5 AE Internal Webservices 38
5.1 Introduction 38
5.2 Using the Webservice 38
5.3 Webservice Operations 41
6 AE.ResourceAdapter 46
6.1 ResourceAdapter 46
7 AE Release Manager 48
7.1 Application Release Automation 48
7.2 Executing Deployment Workflows 49
Glossary 51
A 51
C 51
D 51
G 51
I 52
J 52
P 52
R 52
S 53
T 53
U 53
V 53
W 53
Chapter1 CallAPI | 1
1 CallAPI
1.1 About the CallAPI

The CallAPI can be used to process a script in the AE system. Thus, processes in the AE system can be
triggered from externally.
There are numerous ways of using AE - you can start executable objects, set or read contents of Variable
objects, get particular information about task states etc.
Use the script statement :PUT_READ_BUFFER to supply the script variables of an activated object
with values.
Scripts started via a CallAPI are displayed in the Activity Window and a statistical record including a report
is created. Use the selective statistics to search for it specifying type API or its RunID.
See also:
Using the CallAPI
1.2 Using the CallAPI

The CallAPI is available on various platforms and can be used for many purposes. Read more about its
usage and the most important settings below.
CallAPI installation and INI files are described in the Administration Guide.
There are two ways to use the CallAPI. AE Script is limited to 32000 characters for both ways.
CallAPI and Individual Program

The first possible way you can use the CallAPI is to call it from your own programs. These programs can
be written in the following programming languages:
l C, C++
l Cobol
l Java
l Visual Basic
Examples for this way of using the CallAPI are supplied for all supported platforms.
2 | Chapter 1 CallAPI
CallAPI and Utility

No programming knowledge is required in order to use the CallAPI in the second way. A utility is provided
for each supported platform. The utility can be called from jobs, procedures, executable files or directly
from the command line. Different methods are available for use, depending on the operating system.
Write the script in a text file and assign this file when calling the utility. The following syntax applies for all
platforms:
CallAPI file SCRIPT=script file [LOGON=client, user, [department [, password]]] [INI=INI file]
Parameter Description
SCRIPT= Path and name of the script file
Login data can be omitted if it has already been specified in the INI file.
Optional:
LOGON= Login data
INI= Path and name of the INI file
This parameter is required if the INI file has been renamed or moved to another directory.
Example of calling the CallAPI in Windows:
UCXBXXXC SCRIPT=C:\AUTOMIC\CALLAPI\script.txt LOGON=98, SMITH, AE

INI=C:\AUTOMIC\CALLAPI\WINDOWS\ucxbxxxc.ini
The utility supplies several return codes that can be used to monitor script activation:
Return Description
code
0 AE Script was activated without error.
4 AE Script was activated, but then terminated with the script statement :STOP MSG, 50, "Any
text."
8 Error when activating script or the AE Script was terminated with the script statement :STOP
MSG, 51 - 59, "Any text." or :STOP, NOMSG
12 Error when logging on to the Automation Engine.
16 Fatal error: The script file could not be opened or read.
Note that the start parameters for the RFC Server for SAP are different. There is only one parameter, -I,
that specifies the path to the INI file.
l Example for Windows:

UCXBRXXC -IC:\AUTOMIC\CALLAPI\SAP\UCXSAPC.INI
l Example for UNIX:

nohup ./ucxsapc -I./ucxsapc.ini
Note: Return code 8 is displayed if the activation of AE Script has been canceled because of an error
and cannot be continued. This can happen if a script element is not spelled correctly, or if an incorrect
number of function parameters is specified. There are also errors that cause an output in the Message
Window of the UserInterface and/or the report but do not cause the AE Script to abort. This can happen
if the commands ACTIVATE_UC_OBJECT and IMPORT include errors. The utility always ends with
the return code 0 in such a case.
The RunID returned when running the utility is the CallAPI script's RunID.
Login
The CallAPI requires a valid user in order to log on to the AE system. Login data consisting of client, user
name, department and user can either be defined in the INI file or directly assigned when the CallAPI is
called. The latter is preferred if login data is stored in both locations.
The user logging on to the AE system via CallAPI must have the privilege "Logon via CallAPI."
The AE user must have the appropriate authorizations in order to execute scripts.
Your password can be encrypted with the program UCYBCRYP. Note that the encrypted string must
not exceed 64 characters.
The CallAPI can be used without password verification. The advantage of this is that the password is not
stored in programs or procedures. Thus, it is not necessary to change it every time a new password is
assigned. It is also possible to store the data for automatic login in the variable UC_USER_LOGON.
The above description shows that CallAPI usage requires the same procedure as manual login. Therefore,
it uses a free Dialog license for each connection. Use the key RESERVED_API_USERS in the variable
UC_SYSTEMS_SETTINGS (available in system client 0000) to reserve a number of Dialog licenses for
CallAPI logins. This way, CallAPI and manual user logins do not block each other.
Connection to the Automation Engine

The CallAPI requires connection information for relevant communication processes in order to activate the
script in the required AE system. Enter this connection information in the INI file. In CallAPI calls from your
own programs, these can be directly assigned.
Messages
The script statement :STOP assigns message numbers and texts to the CallAPI. These are stored in
variables and can be read with your own programs. The names of these variables depend on the
programming language. Further details are provided in the chapter "Using CallAPI with your own
Programs."
Call the CallAPI's utility with a Job object in order to view report messages.
Depending on the syntax used in the script function :STOP, the script either aborts or continues to run.
See also:
About the CallAPI

:STOP
1.3 Platforms for CallAPIs
1.3.1 CallAPI for BS2000

The following document includes information and notes required for using the CallAPI for BS2000.
The CodeTable to be used is specified in the BS2000 CallAPI's INI file. Enter the name of the
CodeTable object in the parameter codetable= of the section [GLOBAL].
1. CallAPI and own program
The AE CallAPI can be called from your own programs. This requires sound knowledge of the
programming language in which this program was written.
l CallAPI and own program
All the required parameters are assigned within the program. The program using the CallAPI must only
include or dynamically reload the large module UCCALL at runtime.
2. CallAPI and utility
The supplied package includes the utility UCXBB2?C and is applicable in BS2000 procedures or "Enter"
jobs.
l CallAPI and utility
The utility reads the data required for logging on to the Automation Engine via SYSDTA. The AE Script to
be executed can either derive from a file or directly from SYSDTA. If a file is used, it must be assigned
before the program is called using the file-catenation name UCSCRIPT.
Example
In the first example, the file-catenation name UCSCRIPT is not assigned. The AE Script to be executed is
read until it reaches the SYSDTA command /EOF.
/FILE UCXBB22C.INI,LINK=INI
/EXEC UCXBB22C
04,RS,PROG,PASSWORD
:SET &RUNNR = ACTIVATE_UC_OBJECT(JOBS,EXAMPLE1)
:IF &RUNNR = '0000000'
: SET &ERROR = SYS_LAST_ERR_NR
: STOP MSG,51,'ACTIVATION ERROR: &ERROR'
:ELSE
: STOP NOMSG,50,'THE JOB WAS STARTED WITH RunID &RUNNR'
:ENDIF
/EOF
The script to be executed is available in the file MY.SCRIPT.FILE:

/FILE UCXBB22C.INI,LINK=INI
/FILE MY.SCRIPT.FILE,LINK=UCSCRIPT
/EXEC UCXBB22C
04,RS,PROG,PASSWORD
The following example returns the RunID, the error code and the error message from the CallAPI. These
three values will be written in a JV (job variable).
/CREATE-JV JV-NAME=#UC.RETCODE
/SET-JV-LINK LINK-NAME=UCRETC,JV-NAME=#UC.RETCODE
/CREATE-JV JV-NAME=#UC.RETTEXT
/SET-JV-LINK LINK-NAME=UCRETT,JV-NAME=#UC.RETTEXT
/CREATE-JV JV-NAME=#UC.RUNID
/SET-JV-LINK LINK-NAME=UCRUNID,JV-NAME=#UC.RUNID
/EXEC UCXBB23C
*INI
:SEND_MSG RS,DEV,'MESSAGE FROM THE BS2000 CALL INTERFACE &NAME.'

/EOF
/SHOW-JV JV-CONTENTS=*LINK(LINK-NAME=UCRUNNR)
/STEP
/SHOW-JV JV-CONTENTS=*LINK(LINK-NAME=UCRETC)
/SHOW-JV JV-CONTENTS=*LINK(LINK-NAME=UCRETT)
See also:
About the CallAPI

Using the CallAPI
1.3.2 CallAPI for GCOS8

The following document includes information and notes required for using the CallAPI for GCOS8.
1. CallAPI and own Program
The AE CallAPI may be called from your own programs. This requires sound knowledge of the
The program ucxbxxxc.c is available as C source code. The corresponding structure definition is stored in
the file uccall3.h. Update the example with your data and adjust the JCL files to your environment. In doing
so, you create an RU and test the CallAPI.
1. CallAPI and Utility
The CD we supply includes the utility ucxbgc8c which may be called from a job.
The processing steps defined with AE Script are read from the standard input. The INI and script files may
also be defined using file code.
Example
In the first example, the CallAPI for GCOS8 is called.

$$dismiss
$ ident uc4
$ run rufile=uc4/callapi/exec/ucxbgc8c,
$ etc runame=ucxbgc8c
$ privity
$ limits 9999,,,50k
$ dmpopt savdmp=(mini)
$ data cz
$ ascii
ucxbgc8c ini=uc4/callapi/data/ucxbgc8ci \
script=uc4/callapi/data/script
$ endjob
In the second example, the CallAPI is called with the INI and script files being defined with file code.
$$dismiss
$ ident uc4
$ run rufile=uc4/callapi/exec/ucxbgc8c,
$ etc runame=ucxbgc8c
$ privity
$ limits 9999,,,50k
$ dmpopt savdmp=(mini)
$ data cz
$ ascii
$ prmfl SC,r,s,uc4/callapi/data/script
$ prmfl IN,r,s,uc4/callapi/data/ucxbgc8ci
ucxbgc8c ini=fc*IN script=fc*SC
$ endjob
See also:
About the CallAPI

Using the CallAPI
1.3.3 CallAPI for Java

The following document includes information and notes required for using the CallAPI for Java.
The CallAPI may be called from your own Java program.
l CallAPI and own Java program
It is possible to call the file UCCALL3.JAR from the command line or from a batch file. A sample file
(UCCALL3.BAT) explaining how to call it from a batch file is supplied with AE.
Example
The CallAPI is called with the login data of client 0098 and can be accessed without using a password.
The example activates an AE Script which is stored in the file SCRIPT.TXT.
java -jar uccall3.jar script=script.txt logon=98,smith,uc4
See also:
About the CallAPI

Using the CallAPI
1.3.4 CallAPI for NSK

The following document includes information and notes required for using the CallAPI for NSK.
The utility UCXBNS1C is part of the AE package. It may be called from the command line of the relevant
operating system, from a script or a job.
Examples
Example 1
The first example calls the utility with the connection and login information being specified in the form of
parameters. The utility reads the processing instructions (AE Script) from the file "SCRFILE" which is also
specified in the form of a parameter.
run ucxbns1c script=SRCFILE LOGON=1000,SMITH,UC4
Example 2
The utility is called with the script file being specified in the form of a parameter. Connection and login data
as well as additional information are read from the INI file.
run ucxbns1c script=SRCFILE INI=UCXBNS1I
See also:
About the CallAPI

Using the CallAPI
1.3.5 CallAPI for z/OS

The following document includes information and notes required for using the CallAPI for z/OS.
Define the CodeTable to be used in the INI file of the z/OS CallAPI. Enter the name of the CodeTable
object in the parameter codetable= of the section [GLOBAL]. IBM's default code table is used if this
parameter is empty.
1. CallAPI and individual program
The AE CallAPI can be called from your own program. This requires sound knowledge of the programming
language in which this program was written.
l CallAPI and individual program

The delivery directory includes the utility UCXBM25C which is available in the load library. It can be used
in z/OS jobs.
The AE Script which is to be processed in the Automation Engine is read from SYSIN.
You can also use the data definition instead of the dataset names (see example).
If the utility should be used in a job, the user must be authorized to communicate via TCP/IP.
The parameter REGION= should be set at least to 65M, otherwise errors occur.
Example
Dataset names must be adjusted to your installationation and z/OS configuration.

//UC4JOB JOB ......
//UCCALL EXEC PGM=UCXBM25C,REGION=65M,
// PARM='INI=UC4.UCXBM25C.INI LOGON=0004,SMITH,UC4'
//STEPLIB DD DSN=UC4.UCXJM25.LOAD,DISP=SHR
//* You can use the following command
//* instead of the PARM INI=AE-inifile
//*UCINI DD DSN=AE-inifile,DISP=SHR
//SYSIN DD *
:SET &RUNNR = ACTIVATE_UC_OBJECT(JOBS,ExampleL1)
:IF &RUNNR = '0000000'
: STOP MSG,51,'ACTIVATION ERROR: &ERROR'
:ELSE
: STOP NOMSG,50,'JOB WAS STARTED WITH RunID &RUNNR'
:ENDIF
/*
//
See also:
About the CallAPI

Using the CallAPI
1.3.6 CallAPI for OS/400

The following document includes information and notes required for using the CallAPI for OS/400.
The utility can directly be used without any adjustments being required.
The supplied utility UCXBO41C is found in the library and may be used in OS/400 CL scripts.
The AE Script which should be executed is read from a file member.
Example
The libraries are adjusted to your AE installationation.

CALL PGM(UC4/UCXBO41C) +
PARM('INI=UC4/INI(UCXBO41C)' 'LOGON=4,RS,RS' 'SCRIPT=UC4/WRK(SCRIPT)')
See also:
About the CallAPI

Using the CallAPI
1.3.7 CallAPI for SAP

The following document includes information and notes required for using the CallAPI for SAP.
The RFC Server transfers the script to the AE system. It includes a function module called AE which can
be called in your ABAP programs.
The folder "sample" of the delivery directory includes example programs which show how it is best used.
Function Module AE
Sound knowledge of ABAP/4 is required in order to understand the following descriptions:
Parameter Description
Import Parameter client(4) type c AE client
trcflg(1) type c Trace flag
userabtl(200) type c Department of the AE user
username(200) type c Name of the AE user
userpass(32) type c Password of the AE user
Export Parameter msg(255) type c Message
run(10) type c Run number of the scripts
Tables script Script table (a total of 255 characters per line)
Example:
data: uscript(80) type c occurs 30 with header line
Exceptions logon-failed Logging on to AE was not successful
others Other error
Example for Calling the Function Module
call function 'UC4' destination 'UC4'

exporting
client = p_clint
trcflg = '0'
userabtl = p_usera
username = p_usern
userpass = p_userp
importing
msg = omessg
run = orunnr
tables
script = uscript
exceptions
logon_failed = 1
others = 99.
See also:
About the CallAPI

Using the CallAPI
1.3.8 CallAPI for UNIX

The following document includes information and notes required for using the CallAPI for UNIX.
The AE CallAPI can be called from your own programs. This requires sound knowledge of the
programming language in which this program is written.
The program UCXBXXXC.c is available as C source code. The corresponding structure definitions are
stored in the file UCCALL3.h. These files as well as the Makefile for compiling the example are available in
the directory /src. Update the example with your data. Adjust the Makefile MAKEFILE_EXAMPLE.??? to
your environment. Rename it MAKEFILE as otherwise it might be overwritten with the next update. It can
then be called with make because MAKEFILE is the default name. In doing so, you generate an EXE file
and test the CallAPI.
The utility UCXB???C is supplied with AE. It may either be called from the command line or an executable
file.
AE Script is used to define processing steps which are assigned as default input when the program is
called: The entry < file name reads the AE Script from the corresponding file. The entry <<EOF_SCRIPT
reads the AE script from the command line until the text "EOF_SCRIPT" is recognized.
Example
In the first example, the utility is called with the AE Script being read from the file SCRIPT.TXT.
Connection and login specifications are read from the INI file.
./UCXBUI5C SCRIPT=./script.txt
See also:
About the CallAPI

Using the CallAPI
1.3.9 CallAPI for VMS

The following document includes information and notes required for using the CallAPI for VMS.
The AE CallAPI may be called from your own program. This requires a sound knowledge of the
The program UCXBVXXC.C is available as C source code. The corresponding structure definition is
stored in the file UCCALL3.H. This file and a command for compiling the example are found in directory
/src. Update the example with your data. Adjust the command file MAKEXAMP.COM to your
environment. In doing so, you generate an EXE file and test the CallAPI.
The delivery directory includes the utility UCXBV??C.EXE which may be called from a command file.
Processing steps defined with AE Script are read by the standard input.
See also:
About the CallAPI

Using the CallAPI
1.3.10 CallAPI for VSE

The following document includes information and notes required for using the CallAPI for VSE.
The CallAPI utility may be executed using a VSE job. AE Script can be assigned to the utility via SYSIPT,
or made available via a file or a library element. Examples are provided in the supplied files "sample1.jcl"
and "sample2.jcl".
The utility's output provides further call information. The numbers Uxxxxxxx are AE Message numbers.
See also:
About the CallAPI

Using the CallAPI
1.3.11 CallAPI for Windows

The following document includes information and notes required for using the CallAPI for Windows.
The AE CallAPI may be called from your own programs. This requires sound knowledge of the
programming language in which this program is written.
AE supplies the utility UCXBXXXC.EXE which can be called via the command line, in an MS-DOS box or
a batch file.
The CallAPI can be used via the utility without a special installation being required. Just make sure that the
utility can access the file UCXBWI3C.DLL.
Example
In the example, the utility is called with the login data of client 0098. Access is possible without a
password. The aim is to activate a AE Script which is stored in the file SCRIPT.TXT.
UCXBXXXC SCRIPT=SCRIPT.TXT LOGON=98,SMITH,UC4
See also:
About the CallAPI

Using the CallAPI
1.4 Using CallAPI with Your Own Programs
1.4.1 C, C++

The CallAPI can be used to process scripts in the AE system from your own C and C++ programs.
For this, you need to integrate the files uccall3.h and ucxbwi3c.lib. Note that your program requires access
to the library ucxbwi3c.dll.
The delivery directory contains sample programs that provide a detailed description of how a script
activation can be implemented.
The file uccall3.h gives information about structure and functions.
General
Scripts are always activated with the following steps:
1. Log on to the AE system.

2. Transfer the script to the AE system.
3. Log off from the AE system.
You can log on to several AE systems at the same time and process various scripts. In this case, a
Dialog license is used for each connection.
Functions
In your programs, you can use the functions listed below. These supply return code 0 if the action was
successful or a message number if an error occurred.
Description Data type Function

of return
code
Logging on long UCCALL3_Logon (structure, login data, connection)
to the AE
Data type of structure: UCCALL_PARAMS*
system
Data type of login data: char*
Data type of connection: char*
Format for login data:

Client, user, [department, [password]]
Format for connection data for the communication process:

DNS name:port number
or
TCP/IP address:port number
Activating a long UCCALL3_ActivateScript (structure, script)
script
Data type of script: char*
Logging off long UCCALL3_Logoff (structure)
the AE
system
Universal long UCCALL3 (structures)
function
UCCALL3 can be called instead of the functions described above. In this
case, indicate the opcode in the structure in order to have the required
operation processed.

Variables
Information such as the system name or the script's returned RunID is stored in the structure UCCALL_
PARAMS. It contains the following variables:
Data type Variable Description

char [4] cOpCode Operation code
This variable must be set if the universal function should be used.
Allowed values:
"OPC_LOGON" - logs on to the AE system
"OPC_LOGOFF " - logs off the AE system
"OPC_ACTIVATE_SCRIPT" - activates a script
char cErrorCode The error code in cErrorCode is automatically set and can contain one
of the following values:
" " - no error occurred

"P" - invalid parameter(s)
"O" - invalid opcode
"Q" - login failed
"R" - memory allocation failed
"L" - memory release failed
"S" - socket error
"T" - timeout
"U" - error message of the AE system
char [3] cInterface The interface number must always contain the value 3.
char [8] cSystemName Name of the AE system to which the connection should be
established
unsigned sTimeout Period in seconds during which the CallAPI waits for an AE system
short response
char cLanguage Language in which messages are output
unsigned cFlag1 Depending on the specified value, this flag results in one of the
char processing options listed below:
"CALL_FLAG1_INI_SERVER" - connection to communication

process is retrieved from INI file
"CALL_FLAG1_INI_LOGIN" - login data is retrieved from INI file
"CALL_FLAG1_INI_USEMSL" - converts variable message parts to a
complete message text
"CALL_FLAG1_INI_USEALL" - settings made in the INI file section
[GLOBAL] are used
"CALL_FLAG1_TRC_HANDLE" - for internal CallAPI processing only
"CALL_FLAG1_LOG_HANDLE" - for internal CallAPI processing only
"CALL_FLAG1_INI_FILE" - name of INI file
"CALL_FLAG1_TRC_OUTPUT" - for internal CallAPI processing only
unsigned lUnused1 Not used
long [4]
unsigned Output Not used
long
unsigned lUnsued2 Not used

long [4]
unsigned lScriptRunNr RunID of the script
long
unsigned lRetCode Return code of script execution
long
char [256] cRetText Variable message part explaining the return code's value
char* pIniFile Path and name of INI file
unsigned hZuLog For internal CallAPI processing only
long
unsigned hZuTrc For internal CallAPI processing only
long
unsigned hZuHlp For internal CallAPI processing only
long
unsigned lUnused3 Not used
long [11]
void* pOwnPointer For internal CallAPI processing only
See also:
About the CallAPI
1.4.2 Cobol
The CallAPI can be used to process scripts in the AE system from your own Java programs.
General

Call
Call the CallAPI using the command CALL UCCALL3. Return code 0 is supplied if the action was
successful or a message number if an error occurred.
Description Call
Logging on to the AE system CALL UCCALL3 USING structure, login data, connection
Format for login data:

Client, user, [department, [password]]
Format for connection data for the communication process:

DNS name:port number
or
TCP/IP address:port number
Activating a script CALL UCCALL3 USINGstructure, script
Logging off the AE system CALL UCCALL3 USING structure
Variables
The supplied sample program explains the structure AE-RECORD. It contains the following variables:
Variable Data type Description

UC- PIC X(4) Operation code
OPERATION
This variable must be set if the universal function should be used.
Allowed values:
"OPC_LOGON" - logs on to the AE system
"OPC_LOGOFF " - logs off the AE system
"OPC_ACTIVATE_SCRIPT" - activates a script
UC-ERROR- PIC X The error code in cErrorCode is automatically set and can contain one
CODE of the following values:
" " - no error occurred

"P" - invalid parameter(s)
"O" - invalid opcode
"I" - initialization failed
"Q" - login failed
"R" - memory allocation failed
"L" - memory release failed
"S" - socket error
"T" - timeout
"U" - error message of the AE system
UC- PIC X(3) The interface number must always contain the value 3.
INTERFACE-
NR
UC-SYSTEM- PIC X(8) Name of the AE system to which the connection should be
NAME established
UC-TIMEOUT PIC 9(4) Time in seconds during which the CallAPI waits for an AE system
COMP-4 response
UC- PIC X Language in which messages are output
LANGUAGE
FILLER PIC X(2) Not used
UC-FLAG1 PIC X Depending on the specified value, this flag results in one of the
processing options listed below:
"CALL_FLAG1_INI_SERVER" - connection to communication

process is retrieved from INI file
"CALL_FLAG1_INI_LOGIN" - login data is retrieved from INI file
"CALL_FLAG1_INI_USEMSL" - converts variable message parts to a
complete message text
"CALL_FLAG1_INI_USEALL" - settings made in the INI file section
[GLOBAL] are used
"CALL_FLAG1_TRC_HANDLE" - for internal CallAPI processing only
"CALL_FLAG1_LOG_HANDLE" - for internal CallAPI processing only
"CALL_FLAG1_INI_FILE" - name of INI file
"CALL_FLAG1_TRC_OUTPUT" - for internal CallAPI processing only
UC-OUTPUT- PIC 9(8) Not used
LEN COMP-4
UC-RUNNR PIC 9(8) RunID of the script
COMP-4
UC-RETURN- PIC 9(8) Return code of script execution
CODE COMP-4
UC- PIC X(256) Variable message part explaining the return code's value
MESSAGE-
TEXT
UC-PRT-INI PIC S9(8) For internal CallAPI processing only
UC-HND-LOG PIC S9(8) For internal CallAPI processing only
UC-HND-TRC PIC S9(8) For internal CallAPI processing only
UC-HND-HLP PIC S9(8) For internal CallAPI processing only
UC-POINTER PIC S9(8) For internal CallAPI processing only
UC-INIFILE PIC X(45) Path and name of INI file
See also:
About the CallAPI
1.4.3 Java
The CallAPI can be used to process scripts in the AE system from your own Java programs.
This requires the class UCCALL3 to be imported from the package com.uc4.uccall3.
Detailed information about the Java class is provided in the included documentation.
General

Methods
In your program, you can use the functions listed below.
Description Data type of Function

return code
Logging on to the AE boolean logon()
system logon(client, user, [department, [password]])
logon(specifications)
Data type of client: int

Data type of user: java.lang.String
Data type of department: java.lang.String
Data type of password: java.lang.String
Data type of specifications: java.util.Properties
The Java class "Properties" is used for specifications to

be made. The following parameters can be configured:
"system" - name of the AE system to which a connection

should be established
"language" - message language
"timeout" - period in seconds during which the CallAPI
waits for an AE system response
"client" - client
"user" - user
"dept" - department
"pass" - password
"cpn_host" - DNS name or TCP/IP address of the
computer on which the communication process runs
"cpn_port" - port number of the communication process
Retrieving a connection java.lang.String getConnectionError()
error
Specifying INI file void setConfigurationFile(path and name of INI file)
Data type of script: java.lang.String

Activating a script java.lang.String activateScript(script)
Data type of script: java.lang.String

Retrieving the RunID of int getRunNumber()
the last activated script
Logging off the AE void logoff()

system
See also:
About the CallAPI
1.4.4 Visual Basic

The CallAPI can be used to process scripts in the AE system from your own VB programs.
This function is found in the COM object AE.Call3 which must be registered.
Example: regsvr32 c:\AUTOMIC\callapi\windows\bin\ucxbwi3c.dll
The delivery directory contains a sample program that provides a detailed description of how a script
General
1. Scripts are always activated with the following steps:

Methods
In your program, you can use the functions listed below. They supply return code 0 if the action was
successful, or a message number if an error occurred.
Description Method
Logging on to the AE system Logonclient, user, [department, [password]]
Specifying INI file SetIniFile path and name of INI file
Logging on using INI-file data LogonAsDefault
Activating a script ActivateScript script
Logging off the AE system Logoff
Attributes
Information about script execution is automatically stored in variables.
Data type Variable Description

Long lRunNr RunID of the script
Long lRetCode Return code of script execution

String cRetText Variable message part which explains the return code value
See also:
About the CallAPI

Chapter2 Program Exits | 21
2 Program Exits
2.1 Password Exit

The login data of an AE user contains information about the client, user name, department and password.
During the authentication process AE compares the login information that is entered with the stored user
data. Depending on the result of this comparison, access is either granted or denied.
Also, the Automation Engine provides a password exit which can be used to verify or - where necessary -
reject attempts to log on to the AE system via a custom-developed program library. The password exit is
called for any type of AE user logon (UserInterface, CallAPI).
When using the password exit for verifying user authentication, the AE-specific authentication information
(users with the appropriate rights and privileges) must be available in the AE system.
Requirements
It is necessary to implement a program library which contains the following C functions:
Description Data C function

type
of
return
code
Is called in all work processes (WP) long XUC4PASS_Open(AE system, parameter, callback
when the Server starts. The password function)
exit is not active if this function ends on
Data type of AE system: char*
a return code unequal zero. No more
Data type of parameters: char*
calls are made.
Data type of callback function: void*
Use the callback function to print text outputs in the

Automation Engine's log file. Define the callback
function as shown below:
typedef void (WINAPI *UC4_LOGTEXT)(char

*pText);
It is called in all work processes (WP) long XUC4PASS_Close()
when the Server has ended provided the
exit could successfully be opened.
22 | Chapter 2 Program Exits
Is called in the current primary work long XUC4PASS_Execute(client, user name,

process (PWP) with each AE login. This department, password, language, computer name,
function must return a return code of the login type, length of output area, output area)
following table.
Data type of client: int
Data type of user name: char*
Data type of department: char*
Data type of password: char*
Data type of language: char (possible values: "D",
"E" and "F")
Data type of computer name: char*
Data type of the login type: char (possible values:
"D" - Dialog, "C" - CallAPI, "W" - WebInterface, "A"
- ApplicationInterface, "U" - Utility)
Data type of output area length: int
Data type of output area: char*
The output area is any text which is output in the

message box after successful logon. Only login via
UserInterface or WebInterface has the effect that
this text is displayed. It can be read with the
ApplicationInterface.
Note that the text must not exceed the length of

the output area.
The function XUC4PASS_Execute is

synchronously called with each login. A long
processing time in this function blocks the PWP
for other tasks.
Return codes of the function XUC4PASS_Execute:
Value Constant Description

0 XUC4PASS_EXECUTE_ User was successfully authenticated. The password will be
EXIT_OK saved afterwards as user password in the database.
XUC4PASS_EXECUTE_
EXIT_AUTHENTICATED
1 XUC4PASS_EXECUTE_ User was not successfully authenticated (e.g. wrong password
EXIT_DENIED was used).
2 XUC4PASS_EXECUTE_ User is blocked.
EXIT_DENIED_LOCK
3 XUC4PASS_EXECUTE_ The password exit has not checked the user.
EXIT_INACTIVE
4 PEXIT_RETCODE_ The password is valid, but will not be saved in the database
AUTHENT_NO_ after authentication.
PASSWORD
A sample implementation is available in the delivery directory SystemExit\xuc4pass. It includes

makefiles that can be adjusted according to the application development.
The password exit has a higher priority than the LDAP connection if both are activated. If the states
"authenticated" or "access denied" are returned, the LDAP connection is not called at all. It is only
called if the password exit is inactive or has been deactivated.
Chapter2 Program Exits | 23
Installation Procedure
l Copy the generated program library to all computers on which WP Servers are started. The
indicated path must always be the same as it is specified in the variable UC_SYSTEM_SETTINGS
only once.
Automic strongly recommends copying the generated library to the Server installation directory.
l Use the AE UserInterface to log on to client 0 in the AE system.

l Open the variable "UC_SYSTEM_SETTINGS" for editing. Enter the key "PASSWORD_EXIT". If
it does not yet exist, store the name and path of the previously created program library in the value
section. Enter the key "PASSWORD_EXIT_PARAM" if parameters should be assigned.
l Now restart your AE system in order to activate the password exit.
Information about the Password Exit is available in the System Overview.
See also:
variable UC_SYSTEM_SETTINGS
Encoding Passwords
24 | Chapter 3 Rapid Automation
3 Rapid Automation
3.1 Rapid Automation

The term "Rapid Automation" refers to a generic technology that is able to include and process various
automation solutions in AE. The solutions are realized through RA Solutions. RA agents make the
functions of an RA Solution accessible.
Please contact Automic Support if you are interested in using an RA Solution.
RA Solutions
Each RA Solution has its own individual function but there are some similarities in all RA Solutions. The
corresponding RA agent requires specific settings. Therefore, an RA Solution includes a template for the
Agent object that should be used. Connection data can be specified in one or several Connection objects.
The RA Solution also includes the required object templates. The same is true for Job objects. Each RA
Solution includes one or several job types that can be used to call the relevant functions.
The contents of agent, Connection and Job objects depend on the particular RA Solution.
RA Solutions are supplied as JAR files and can be loaded to the AE database by using the utility
AE.DB Load. The utility reads the JAR file and creates the following objects in system client 0000:
l RA Solution object in the folder "RA_SOLUTIONS"

l Template for the Agent object in the folder "TEMPLATE"
l One or several templates for Connection objects in the folder "TEMPLATE"
l One or several templates for Job objects in the folder "TEMPLATE"
The utility AE.DB Load automatically enters the new templates into the variable UC_OBJECT_
TEMPLATE.
Object type Structure of the name

RA Solution The name of the RA Solution.
Agent The AGENT.name of the RA Solution.
Connection The CONN.name of the RA Solution.technical name of the connection.
Job The JOBS.name of the RA Solution.technical name of the job type.
The utility AE.DB Load can also be used to load later versions of an RA Solution. The former version is
automatically replaced in the AE database.
You can delete an RA Solution from the AE system by deleting the corresponding RA Solution object in
client 0 (folder: RA_SOLUTIONS). The object including its entries is not moved to the Recycle Bin but
is completely removed from the AE database.
For Rapid Automation agent documentation, see the Automic Hosted Documentation.
RA Agent
An RA agent can only connect to one RA Solution. If you intend to use several RA Solutions, you need a
separate RA agent for each solution.
Chapter3 Rapid Automation | 25
An Agent object must be created in system client 0000 before the RA agent is put into operation. Use the
supplied agent template for this purpose. An Agent object contains the Connection objects that should be
used for logging on etc. Create these Connection objects by using the supplied templates.
When the RA agent starts, it checks whether the RA Solution has already been stored locally. If not, it
requests the RA Solution's JAR file from the Automation Engine. The RA agent unpacks it in the folder
"cache" (the path has been specified in the INI-file parameter cache_directory=). The name of the created
subfolder is the RA Solution object's latest modification date. While starting, the system checks whether
this time stamp complies with the AE database's time stamp. If they differ from each other because a later
version has been loaded to the AE database, the RA agent retrieves the JAR file and replaces the local RA
Solution.
RA Jobs
RA jobs include two object type-specific tabs. The first one is the RA tabwhich includes the options for
report creation and transfers. The name of the second tab is preset by the RA Solution. It includes the RA
job's specific configurations. Possible attributes that apply to all the RA Solution's job types are displayed
in a separate subtab. In this case, the tab includes two subtabs instead of one.
A traffic-light symbol is displayed in the tab whose content is preset by the RA Solution. It displays the
connection status to the RA agent:
l Green - A connection has been established.

l Yellow - A request is being sent.
l Red - There is no connection, the request has failed or a timeout has occurred.
Note that a positive connection status (green traffic-light symbol) will only be displayed if a valid RA
agent has been specified. In the following cases, it cannot be displayed:
l Agent group has been specified.

l No agent has been specified.
l An invalid agent has been selected (for example, an RA FTP agent has been selected in an RA
VMWare job).
l The selected agent is inactive.
No Login objects are required in RA jobs. Login data is stored in the agent object.
Open the RA Solutions help by clicking "Solution Help" in the RA job's Solution tab (RA Banner job) or
FTP tab(RA FTP job).
Setting and Reading Job Attributes

For attributes that are also available in other Job objects (such as the archive keys or cost centers), you
can set or read the same names with :PUT_ATT, GET_ATT and AE.DB Change.
You can also set and read the attributes of the tab that is preset by the RA Solution via script. To change
these attributes using the utility AE DB Change, see the relevantdescription.
A tooltip text displays the attribute names in the UserInterface. Another method to retrieve the attribute
names including their values is to run the following command in the AE database (replace the JOBNAME
by the job's actual object name):
select OCV_VName,ocv_value from OCV,oh where OCV_OH_Idnr=OH_Idnr and oh_
name='JOBNAME'
To run this command, you can also use an SQLI-type VARA object.
26 | Chapter 4 AE.ApplicationInterface
4 AE.ApplicationInterface
4.1 Introduction
The ApplicationInterface is an interface that facilitates access to the AE system.
The ApplicationInterface is available for Java and .NET programming languages.
The interface comprises hundreds of classes and methods which can be used to call many of the
UserInterface's functions such as creating and editing objects, accessing statistical records, accessing
the System Overview, reading reports, starting tasks, etc. All actions are kept for the Revision Reports
and can be listed using the utility AE Revision.
The ApplicationInterface files are provided in the directory IMAGE:\APPLICATIONINTERFACE.
File Description
uc4.jar ApplicationInterface Java library
*.dll ApplicationInterface .NET library (for .NET programming languages such as C# and
VisualBasic)
*.zip Archive with IKVM runtime libraries which are required for using the .NET library. The
DLL files in the archive must be added to the respective .NET project.
doc.zip Javadoc (Java documentation) which contains a list and description of all classes and
methods.
The names of the Java library classes/methods are the same as those in the .NET
library.
examples.zip Sample Programs
All sample codes in the following documents work with the programming languages Java and C#. For
other programming languages, the syntax in the examples should be adapted as appropriate.
There are numerous ways of using the ApplicationInterface. For example, you can automatically create
many objects at the same time, or release only a relevant processing selection to users. This interface is
an ideal addition to extend your existing programs, as it facilitates access to your AE system.
Access via the ApplicationInterface must be made with an AE user and are subject to the authorization
system.
The ApplicationInterface functions may vary depending on the Automation Engine version in use.
Automic recommends reconverting your projects when you install a new version.
It is important that you do not confuse the ApplicationInterface with the CallAPI for Java, which serves
to execute an AE Script in the AE system.
Note that the ApplicationInterface cannot be called from Enterprise JavaBeans. For this, use the
ResourceAdapter.
Also see:
Using this Interface

Chapter4 AE.ApplicationInterface | 27
4.2 Using this Interface

The classes and methods of the AE ApplicationInterface can be used as soon as the library has been
integrated in your program.
Data between the program and the AE system is exchanged via "Requests". Keep in mind that you should
establish a connection to the AE system and log on to a client, as otherwise requests cannot be sent or
received.
Procedure
The following steps are always required, regardless of how your program is used:
1. Establish a connection to the AE system:

Connection uc4 = Connection.open("PC01", 2217);
2. Log on to the AE system with a user:

uc4.login(98,"SMITH","UC4",null,'D');
3. Any number of requests can be sent now (e.g., searching for an object). These requests are sent
synchronously or asynchronously using the methods "sendRequestAndWait" and "sendRequest".
uc4.sendRequestAndWait(WinJobs);
uc4.sendRequest(WinJobs, Handle);
Now access the request result (e.g., search result).
4. Finally, terminate the connection

uc4.close();
Requests are used for retrieving information from or executing an action in the AE system. The
supplied package includes several examples which describe how the AE.ApplicationInterface is best
used. Additionally, the documents shown below provide information about the most important classes.
See also:
Classes for Objects

Classes for Workflows and Schedules
Classes for Activities
Classes for Statistics and Reports
Classes for the System Overview
4.3 Guide to Using the AE.ApplicationInterface

There is some important information to note when using the AE.ApplicationInterface.
Do's
l Log on - execute all actions - log off.
l Open objects in read-only mode if no modification is being made.
l Modify rather than delete and recreate.
l Only use what is required.
l Use mass functions instead of many individual actions if applicable (no mass function available:
contact Automic Support).
l Execute complex mass modifications via the AE.ApplicationInterface in a non-production AE
environment and transfer your modifications to the production system using the corresponding
utility.
Don'ts
l Loops without waiting time (especially for status queries)
l Creating/modifying an object and storing it repeatedly
l Huge and numerous searches using the class "SearchObject"
Important Notes
l The AE.ApplicationInterface mainly facilitates the automation of user interactions.
l When reviewing applications, put the main focus on recurring processes (especially in processing
loops) as performance gains are most likely here.
l In high-volume processing using the AE.ApplicationInterface, weigh up the importance of a fast
processing time with the importance of non-impaired production system performance. If the
performance of the production system is more important, use the AE.ApplicationInterface in such a
way that processing is distributed evenly over a longer period of time (e.g. through waiting queues).
l The aim should be to send as few queries as possible to the Automation Engine. Only call the
methods Connection.sendRequest() and Connection.sendRequestAndWait() if necessary.
Negative Effects of Badly Designed Applications

l Dialog users rank second because the AE.ApplicationInterface also uses the dialog processes.
l The performance of the whole AE system is negatively affected because calling the
AE.ApplicationInterface represents a write access to the AE database, resulting in increased I/O
database activity.
4.4 Object Classes

AEObject is the basic class from which other classes can be used to create and edit objects.
Creating Objects
First retrieve the client's folder structure using the class "FolderTree". As this is a request, method
sendRequestAndWait is called. Now determine the folder in which the object should be created. Object
names must not contain particular characters; hence they have been implemented in an extra class.
Select an object name via "UC4ObjectName". The object is created via the class "CreateObject".
Subsequently, call the method sendRequestAndWait in order to transfer the request to the AE system.
FolderTree tree = new FolderTree();
uc4.sendRequestAndWait(tree);
IFolder folder = tree.getFolder("/MATERIAL_MANAGEMENT/DAILY_CLOSING");
UC4ObjectName name = new UC4ObjectName("MM_CLOSING");

CreateObject create = new CreateObject(name, Template.JOBS_UNIX, folder);
uc4prod.sendRequestAndWait(create);
Creating Folders
Folders are objects and are created in the same way as all other objects.
UC4ObjectName fname= new UC4ObjectName("PRODUCTION");
CreateObject create = new CreateObject(fname, Template.FOLD, folder);
uc4.sendRequestAndWait(create);
Editing Objects
Use the class "OpenObject" to open the object to be edited. This class contains methods which can be
used to query particular information. The example shown below checks whether the object is a UNIX job.
If so, the class "Job" can be used to set specifications and attributes in the Job object. Note that the
names of users, agents and TimeZone objects have been implemented in extra classes because different
naming conventions apply to them.
After the object has been edited, it must be transferred and stored using a request. This is done via the
class "SaveObject" which contains the relevant methods. Keep in mind to close the object afterwards.
OpenObject open = new OpenObject(name);
uc4.sendRequestAndWait(open);
if (open.getType().equalsIgnoreCase("JOBS_UNIX"))
{
Job job = (Job) open.getUC4Object();
job.header().setArchiveKey1("Material_Management");
job.attributes().setPriority(100);
job.attributes().setHost(new UC4HostName("UNIX01"));
job.setPostProcess(script);
AttributesUnix hostattributes = (AttributesUnix) job.hostAttributes();

hostattributes.setShell("csh");
hostattributes.setReportDatabase(true);
hostattributes.setReportErrorOnly(true);
SaveObject save = new SaveObject(job);

uc4.sendRequestAndWait(save);
uc4.sendRequestAndWait(new CloseObject(job));
}
Deleting Objects
Use the class "DeleteObject" to delete objects:
DeleteObject delete = new DeleteObject(name);
uc4.sendRequestAndWait(delete);
Searching Objects
The class "SearchObject" can be used to search for objects. Search parameters can be defined the same
way as in the UserInterface. The example shown below searches for workflows whose names commence
with "FIAC". The request supplies a result which can be filtered with an iterator. Information such as the
object name can be retrieved for each result.
SearchObject search = new SearchObject();
search.setTypeJOBP(true);
search.setName("FIBU*");
uc4.sendRequestAndWait(search);
if(search.size() > 0)
{
Iterator it = search.resultIterator();
while(it.hasNext())
{
SearchResultItem result = (SearchResultItem) it.next();
System.out.println("Result: " + result.getName());
}
}
See also:

4.5 Classes for Workflows and Schedules

Both object types administer tasks. As numerous settings can be specified for them, specific classes are
available.
Adding Tasks to Workflows

Open the relevant workflow. You get the tasks that should be inserted in the workflow by using the class
"AddJobPlanTask". Then you use the class "JobPlanTask" to modify the properties. The example that is
shown below includes some of the various methods that are available. For example, a calendar condition
is added to the task "FILE.INCOME". The task "MM.CLOSING" only starts when this task shows the
status ENDED_OK. You define these predecessor conditions with the method "addDependencies" that
connects the two tasks to each other. Now you can integrate the tasks in the workflow by using the
method "addTask". The method "closeJobPlanTasks" is helpful for connecting tasks that do neither have
a predecessor nor a successor with a workflow's start and end. Using method "format" has the effect that
tasks are clearly arranged.
For compatibility reasons, the class names still show the name JobPlan that has been used prior to AE
v8 instead of the new name workflow.
OpenObject open = new OpenObject(new UC4ObjectName("MM.DAY"));

JobPlan jobplan = (JobPlan) open.getUC4Object();
AddJobPlanTask add1 = new AddJobPlanTask(new UC4ObjectName("FILE.INCOME"));

uc4.sendRequestAndWait(add1);
AddJobPlanTask add2 = new AddJobPlanTask(new UC4ObjectName("MM.CLOSING"));
AddJobPlanTask add3 = new AddJobPlanTask(new UC4ObjectName("MM.GROUP"));
JobPlanTask task1 = add1.getJobPlanTask();

UC4ObjectName cale = new UC4ObjectName("FIRM_CALENDAR");

UC4ObjectName calekey = new UC4ObjectName("WORKING_DAYS");
CalendarCondition calecond = new CalendarCondition(cale, calekey);
task1.calendar().addCalendarCondition(calecond);
task2.dependencies().addDependency(task1,TaskState.ENDED_OK);
jobplan.addTask(task1);
jobplan.closeJobPlanTasks(null);
jobplan.format();
SaveObject save = new SaveObject(jobplan);

uc4.sendRequestAndWait(new CloseObject(jobplan));
Adding Tasks to Schedules

Tasks are added to Schedules in the same way that they are added to workflows. Only class names and
methods are different.
OpenObject open = new OpenObject(new UC4ObjectName("JAPI_JSCH"));
Schedule schedule = (Schedule) open.getUC4Object();
AddScheduleTask add1 = new AddScheduleTask(new UC4ObjectName("MM.DAY"));

AddScheduleTask add2 = new AddScheduleTask(new UC4ObjectName("MM.WEEK"));
ScheduleTask task1 = add1.getScheduleTask();

ScheduleTask task2 = add2.getScheduleTask();
task1.setStartTime(new Time("08:00"));
task2.setStartTime(new Time("10:30"));
UC4ObjectName cale = new UC4ObjectName("FIRM_CALENDAR");

UC4ObjectName calekey = new UC4ObjectName("WORKING_DAYS");
CalendarCondition calecond = new CalendarCondition(cale, calekey);
task1.calendar().addCalendarCondition(calecond);
schedule.addTask(task1);
schedule.addTask(task2);
SaveObject save = new SaveObject(schedule);

uc4.sendRequestAndWait(new CloseObject(schedule));
See also:
Classes for Objects

4.6 Classes for Activities

The AE ApplicationInterface also facilitates access to the activities of your AE system.
Starting Objects
Use the class "ExecuteObject" to activate objects and get information about the activated object.
ExecuteObject execute = new ExecuteObject(new UC4ObjectName("MM.DAY"));
uc4.sendRequestAndWait(execute);
System.out.println("RunID of the activated task: " + execute.getRunID());
Reading the Activity Window

Define a filter using the class "TaskFilter" to read the Activity Window. Then send this request to the AE
system via the class "ActivityList". The result can then be checked with an iterator.
TaskFilter filter = new TaskFilter();
filter.setTypeJSCH(false);
filter.setObjectName("MM*");
ActivityList list = new ActivityList(Filter);

uc4.sendRequestAndWait(list);
Iterator it = list.iterator();
if(list.size() > 0)
{
while(it.hasNext())
{
Task task = (Task) it.next();
System.out.println("result: " + task.getName());
}
}
Stopping, Canceling or Ending Tasks

Extra classes are available for all of these actions.
// Stop task
SuspendTask stop = new SuspendTask (task1.getRunID(), false);
uc4.sendRequestAndWait(stop);
// Restart task
ResumeTask go = new ResumeTask (task1.getRunID(), false);
uc4.sendRequestAndWait(go);
// End task
QuitTask quit = new QuitTask (task1.getRunID());
uc4.sendRequestAndWait(quit);
// Deactivate task
DeactivateTask deactivate = new DeactivateTask (task1.getRunID());
uc4.sendRequestAndWait(deactivate);
// Cancel task
CancelTask cancel = new CancelTask (task1.getRunID(), true);
uc4.sendRequestAndWait(cancel);
Starting Tasks with Prompts

You can set the PromptSet variables of tasks before they start when one or several PromptSet objects
have been assigned to them. You use the method "putPromptBuffer" of the class "ExecuteObject" for this
purpose.
//Start Task
ExecuteObject exec = new ExecuteObject(new UC4ObjectName("GEN.SCRI_PROMPT_
DEMO"));
//Set Prompt buffer

exec.putPromptBuffer("FIRSTPROMPTSET1", "a");
exec.putPromptBuffer("FIRSTPROMPTSET2", "b");
exec.putPromptBuffer("SECONDPROMPTSET1", "c");
exec.putPromptBuffer("SECONDPROMPTSET2", "d");
System.out.println("Run ID:"+exec.getRunID());
//Read report
Report act = new Report(exec.getRunID(), "ACT");
System.out.println(act.getReport());
See also:
Classes for Objects

4.7 Classes for Statistics and Reports

Not only the Activity Window, but also the statistical overview and reports can be read.
Reading Statistical Records

The class "GenericStatistics" provides access to the statistical overview. Use the various filter settings to
specify the statistical records to be requested. The result can then be checked with an iterator via the
class "StatisticSearchItem".
GenericStatistics statistic = new GenericStatistics();

statistic.setObjectName("MM.CLOSING");
statistic.setTypeJOBS(true);
uc4.sendRequestAndWait(statistic);
if(statistic.size() > 0)
{
Iterator it = statistic.resultIterator();
while(it.hasNext())
{
StatisticSearchItem result = (StatisticSearchItem) it.next();
System.out.println("Result: " + result.getParentRunNumber());
System.out.println("Result: " + result.getReturnCode());
System.out.println("Result: " + result.getStatusText());
}
}
Reading Reports
The class "Report" and the RunID of the execution are required for reading reports. The RunID is retrieved
using the class "LatestReport" which supplies the particular report pages in the form of a string. Keep in
mind that a request must be sent for each individual page.
int i = 1;
UC4ObjectName name = new UC4ObjectName("MM.CLOSING");

LatestReport runnumber = new LatestReport(name);
uc4.sendRequestAndWait(runnumber);
Report report = new Report(runnumber.latestRunNumber(), "REP");

uc4.sendRequestAndWait(report);
while(i <= report.getNumberOfPages())

{
String page;
System.out.println("current page: " + report.getCurrentPage());
page = report.getReport();
if( (page.indexOf("cd Temp")) != -1)
{
System.out.println("found");
}
report.nextPage(i);
uc4.sendRequestAndWait(report);
i++;
}
See also:
Classes for Objects

4.8 Classes for the System Overview

Use the available classes to get information about the status of processing.
Reading the System Overview

The AE.ApplicationInterface provides classes which can be used to read the different areas of the System
Overview. This includes the classes of the package com.uc4.api.systemoverview. First request the
System Overview's particular area to be read. It is supplied without the specification of filter criteria being
required. The cells of the overview (which is provided in table form) can then be checked with an iterator.
The example shown below reads server processes.
ServerList list = new ServerList();
uc4.sendRequestAndWait(list);
Iterator it = list.iterator();
while(it.hasNext())
{
ServerListItem item = (ServerListItem) it.next();
System.out.println(item.getName());
}
See also:
Classes for Objects

4.9 Starting and Stopping Clients by using the

Application Interface
The following topic will show you a sample program that allows you to start or stop any client by using the
Java Application Interface.
You can use the existing Java code or adjust it according to your requirements.
Use the following command-line parameters in order to call the sample program:
java aeClientGoStop <go/stop> <cp> <port> <client> <user> <dep> <pwd>
l <go/stop>
Possible values: "go" or "stop".
"go" - Starts the client and "stop" - Stops the client.
l <cp> = The IP address or the name of the CP computer.
l <port> = The port number of the CP.
l <client> = The four-digit client number.
l <user> = The name of the AE user.
l <pwd> = The user password.
To be able to call the program successfully, you will need the Java Application Interface (uc4.jar).
import java.io.IOException;
import com.uc4.communication.Connection;
import com.uc4.communication.requests.CreateSession;
import com.uc4.communication.requests.ResumeClient;
import com.uc4.communication.requests.SuspendClient;
import com.uc4.communication.requests.XMLRequest;
public class aeClientGoStop {
public static void main(String[] args) throws IOException {
new aeClientGoStop().gostop(args);
}
private void gostop(String[] args) throws IOException {
int count = args.length;

if(count < 6){
System.err.println("not enough arguments: min = 6 -> found only: " +
count);
System.exit(1);
}
//System.err.println("arguments passed on: " + count);
String action = null;
String cp = null;
String port = null;
String client = null;
String user = null;
String dep = null;
String pwd = null;
if(count < 7){

action = args[0];
cp = args[1];
port = args[2];
client = args[3];
user = args[4];
dep = args[5];
pwd = "";
}else if(count == 7){
action = args[0];
cp = args[1];
port = args[2];
client = args[3];
user = args[4];
dep = args[5];
pwd = args[6];
}
//Create a connection to the Automation Engine

Connection uc4 = Connection.open(cp, Integer.parseInt(port));
//Login
CreateSession login = uc4.login(Integer.parseInt(client),user,dep,pwd,'E');
//Test if the login was successful

if (!login.isLoginSuccessful()) {
System.err.println(login.getMessageBox().getText());
uc4.close();
System.exit(1);
}
XMLRequest rqr = null ;

if (action.equals("go")){
rqr = new ResumeClient();
} else if (action.equals("stop")){
rqr = new SuspendClient();
}
uc4.sendRequestAndWait(rqr);
if (rqr.getMessageBox() != null) {
System.err.println(rqr.getMessageBox().getText());
uc4.close();
System.exit(3);
}
uc4.close();
System.out.println("done action: " + action + " client: " + client);
}
};
38 | Chapter 5 AE Internal Webservices
5 AE Internal Webservices
5.1 Introduction
The AE Internal Webservice is a Web service that you can use to access the AE system. Numerous
operations are available. For example, you can start objects, access task details or read System Overview
areas.
The supplied WSDL file AE.wsdl includes a description of all available operations. Therefores, you can
quickly and easily create Web clients which call the AE Internal Webservice.
Accesses made via the AE.ApplicationInterface require an AE user and are subject to the authorization
system.
The AE Internal Webservice is bound to a particular AE system. You can deploy this Webservice several
times if you want to use it in several AE systems.
See also:
Using the Webservice
5.2 Using the Webservice

The AE Internal Webservice is the connecting link between Web client and AE system. The Web client
calls Webservice operations. The Webservice uses an AE user to log on to the AE system and process
the selected operations. The result is then sent to the Web client.
Two methods are available for accessing the AE system via the Webservice.
You can use any programming language to create a Web client. The following examples are written in
Java.
Method 1: Default User

Indicate the AE user to be used for accessing the AE system in the Configuration WebInterface. The
Webservice will always use the default user if the Web client does not supply a session ID (see Method 2).
A port of type "Uc4PortType" is required in order to communicate with the Webservice.

Uc4PortType port = new UC4Service().getUc4Port();
This port can be used to call Webservice operations and, for example, a list of all the client's agents.
List<AgentListItem> list = port.getAgentList();
Method 2: Session With Any User

The default user is limited to one client. A session must be created if you intend to access several clients
or log on with different users.
A port of type "Uc4PortType" is again required for the communication with the Webservice.
Chapter5 AE Internal Webservices | 39
Uc4PortType port = new UC4Service().getUc4Port();
Log on using the operation logon. The AE user is assigned via the corresponding parameters. The return
code is a session ID which can be set in the HTTP Header. By doing so, it will automatically be assigned
whenever this operation is called.
try{
String sessionID = port.logon(100, "SMITH", "UC4", "top-secret password",
(bytes) 'D');
Map<String, List<String>> requestHeaders = (Map<String, List<String>>)

context.get(MessageContext.HTTP_REQUEST_HEADERS);
if(requestHeaders == null) {
requestHeaders = new HashMap<String, List<String>>();
context.put(MessageContext.HTTP_REQUEST_HEADERS, requestHeaders);
}
requestHeaders.put("id", Arrays.asList(sessionID));
} catch(UC4WSException e){
System.out.println("ERROR: " + e.toString());
}
You can use the port to call the Webservice operations and, for example, read database information from
the System Overview:
DatabaseInformation dbInfos = port.getDatabaseInfo();
String dbName = dbInfos.getDbName();
End sessions using the operation "logoff":

port.logoff(sessionID);
The Webservice automatically closes connections that have not been used for a particular period of
time. You can define this timeout length in the configuration web interface.
Filling :READ Masks

The Webservice contains the operation executeObject which can be used to start objects. One of its
parameters serves to assign values for script variables via :READ masks as the following example will
explain:
The workflow MM.DAY contains the following :READ mask:

:BEGINREAD "Print parameters"
:READ &TITLE#,"00","Please enter a title"
:READ &NUMBER#,"0-5","Please enter a number",,"N"
:ENDREAD
A value is assigned to a script variable via the entry field label and not via the variable name. The following
excerpt will explain this in more detail. First, create a list in which the values should be stored. Then, define
the value for the script variable &TITLE#. Label it "Please enter a title". It should obtain the value "Final
account". Now, define the script variable &NUMBER#. Finally, call the operation "executeObject" and
assign this list of values.
List<InputParameter> read = new ArrayList<InputParameter>();
InputParameter p1 = new InputParameter();

p1.setName("Please enter a title");
p1.setValue("Final account");
read.add(p1);
InputParameter p2 = new InputParameter();

p2.setName("Please enter a number");
p2.setValue(2);
read.add(p2);
int runID = port.executeObject("MAWI.TAG", "", read, null, false);
Only one value list is required even if an object has several :READ masks.
Because values are assigned via entry field labels, Automic recommends creating unique labels in
order to avoid confusion.
For performance reasons, Automic recommends using one larger :READ mask instead of using
several individual ones.
Error Handling
Errors occur for the following three reasons:
1. The Webservice cannot establish a connection to the Automation Engine (e.g. the communication
process is not available, invalid login data etc.)
2. Runtime error while processing an operation (e.g. the object to be started does not exist)
3. The SOAP message the Web client sends to the Webservice is invalid.
The Webservice provides the exception UC4WSException. It contains an information field which includes
the message number and text. It also informs about the type, which can either be "CONNECT" if the error
occurred while attempting to establish a connection or "REQUEST" if operation processing was
erroneous.
try{
String priority = port.getHighestNotificationPriority();
} catch(UC4WSException e){
System.out.println("Error number: " + e.getFaultInfo().getId();
System.out.println("Error text: " + e.getFaultInfo().getMessage);
}
The language that is used to transfer message texts to the Web client depends on the time the error
occurred:
l It is always English if the error occurred while logging in.

l The text is displayed in the language in which the user logged on if the error occurred after a
successful login attempt. Exception: Variable parts of the error message (for example, for
exceptions) may be displayed in English.
l SOAP faults generally include English texts.
See also:
Webservice Operations
5.3 Webservice Operations

Operations are also described in the supplied file uc4.wsd.
Logon/Logoff
Description Operation Parameters Return code
Logon logon Client, user name, Session ID
department, password,
language
Allowed values for the

language: "68" (German),
"69" (English) and "70"
(French)
Logoff logoff Session ID -
AE System Information
Retrieving the getVersion - Automation Engine
Automation version
Engine version
Example: 8.00A909-
including the
001
hotfix number
Retrieving getDatabaseInfo - Type
database DatabaseInformation
information (see
Use this type to
System
query individual
Overview -
information such as
Database)
the database name.
Client Information
System client 0000 supplies a list of all the AE system's users, agents etc. If you log on to a user-
defined client, only this client's objects will be supplied. This list corresponds to the content of the
System Overview.

List of server getServerList - List of type
processes ServerListItem
Use this type to

query individual
information such as
the server process
name.

Server process getSystemWorkload - List of type
workload list WorkLoadItem
Use this type to

query individual
information such as
the average.
List of clients getClientList - List of type
ClientListItem
Use this type to

query individual
information such as
the TimeZone.
List of users getUserList - List of type
UserListItem
Use this type to

query individual
information such as
the name.
List of agents getAgentList - List of type
AgentListItem
Use this type to

query individual
information such as
the roles.
List of agent getAgentGroupList - List of type
groups AgentGroupListItem
Use this type to

query individual
information such as
the mode.
Content of the getActivityList Filters List of type Task
Activity Window
The parameter is of type Use this type to
TaskFilter. query individual
tasks.
Top priority of getHighestNotificationPriority - Top priority of all
active running
notifications notifications.
Possible values:
"LOW" - Low
"MEDIUM" -
Normal
"HIGH" - High
Starting and Stopping Clients

Starting a client resumeClient - -
Stopping a client suspendClient - -
Starting, Ending etc. Tasks

Starting an object executeObject Object name, TimeZone, RunID of the
Input parameter for READ started task
masks, Start time, Waiting
for manual release
See also Filling :Read masks
The parameter "Waiting for

manual release" is of type
boolean.
Starting a executeRecurring Object name, TimeZone, RunID of the
recurring task Frequency, Time frame, started period
Days, Range container
The parameter "Frequency"

is of type ExecuteFrequency.
The parameter "Time frame"

is of type
ExecuteTimeFrame.
The parameter "Days" is of

type ExecuteDays.
The parameter "Range" is of

type ExecuteRange.
Repeating a task restartTask Reference RunID, Restart -
point, Keep start type,
Waiting for manual release,
Restart for canceled child
tasks only
The 3rd, 4th and 5th

parameters are of type
boolean.
Stopping a task suspendTask RunID, Recursive -
The parameter "Recursive" is

of type boolean.
Setting a stopped resumeTask RunID, Recursive -
task to active
of type boolean.
Ending a task quitTask RunID -

Canceling a task cancelTask RunID, Recursive -

of type boolean.
Deactivating a deactivateTask RunID -
task
Adopting a task adoptTask RunID -
Tasks During Execution

Reloading a setReloadNextTurnaround Schedule name -
Schedule at the
next period
turnaround
Ignoring Sync ignoreTaskSyncCondition RunID -
conditions
Unregistering a unregisterTask RunID -
reservation
Setting a task's setTaskStartTime RunID, Start time, TimeZone -
start time
Setting a task's setTaskState RunID, Old status, New -
status status
In both status parameters,

indicate the system return
code.
Starting a task startTaskImmediately RunID -
immediately
Reading a task's getTaskDetails RunID List of type
Detail Window DetailGroup
Use this type to

query individual
information such
as the status.
Workflow and Workflow Tasks

Setting a setWorkflowBreakPoint RunID -
breakpoint in a
workflow
Removing a removeWorkflowBreakPoint RunID -
breakpoint from a
workflow
Unblocking a task unblockWorkflowTask RunID -
in a workflow

Activating a task setWorkflowTaskActive RunID -
in a workflow
Deactivating a setWorkflowTaskInactive RunID -
task in a workflow
See also:
Using the Webservice

46 | Chapter 6 AE.ResourceAdapter
6 AE.ResourceAdapter
6.1 ResourceAdapter
With the ResourceAdapter, you can use the ApplicationInterface from Enterprise JavaBeans (EJB). Due
to technical limitations, you cannot use the ApplicationInterface directly from an EJB. The
ResourceAdapter does not run in the Enterprise JavaBean Container. It is therefore not bound to these
limitations.
Using the ResourceAdapter and the ApplicationInterface differs in only two points:
l Connection establishment
l Logon
All other classes are used in the same way as when the ApplicationInterface is directly accessed.
Connection Establishment
The J2EE Server administers a pool of connections in the Java Connector Architecture (JCA). The EJB
must request a connection from it (if required). The J2EE Server either uses a suitable connection from the
pool or generates a new one via the ResourceAdapter which is then stored in the pool.
The computer and port number of a communication process are required for establishing a connection via
the ApplicationInterface.
Connection uc4 = Connection.open("PC01",2080);
Both parameters are part of the configuration if the connection is established via the ResourceAdapter.
You obtain a pre-configured instance of a ConnectionFactory via a JNDI Lookup. At this point in time, it is
not necessary that a connection to the communication process exists.
Context initctx = new InitialContext();
ConnectionFactory factory = (ConnectionFactory) initctx.lookup
("java:comp/env/eis/UC4");
Logon
The JCA distinguishes two logon types:
1. Component-managed sign-on
The EJB supplies login data.
2. Container-managed sign-on
The J2EE Server supplies login data. The EJB does not require access data such as user name or
password.
Login data is required in order to establish the connection using the ApplicationInterface. The method
isLoginSuccessful can be used to query whether the login procedure was successful.
CreateSession login = uc4.login(98,"MEIER","UC4","pass",'D');
if (!login.isLoginSuccessful()) {
...
}
Chapter6 AE.ResourceAdapter | 47
When establishing a connection using the AE.ResourceAdapter, the method getConnection of a factory is
used (supplied via a JNDI Lookup) to execute a TCP/IP connection plus login. The following methods are
possible:
l getConnection without parameters
AdapterConnection uc4 = factory.getConnection();
The configuration of the ResourceAdapter is used for the Server, port, client, department and
language. The J2EE Server supplies the user name and password which have been used to log on
to the J2EE Server (Single Sign-on).
l getConnection with parameters
AdapterConnection uc4 = factory.getConnection(97, "SMITH", "UC4",

"pass", 'E')
With this method, all login data is entered in the EJB. This data has a higher priority than data used
for configuring the ResourceAdapter. If one or several parameters are not indicated, the
corresponding one of the configuration is used. If the attempt to log on was not successful, a
ResourceException is triggered whose text describes the error in more detail.
l getConnection with parameters but without user name and password
AdapterConnection uc4 = factory.getConnection(97, "UC4", 'E')
Only the client, department and language must be indicated in the EJB. User name and password
are supplied by the J2EE Server (see method 1).
Usage
Java classes of the ApplicationInterface are used in the same way as when the ApplicationInterface is
used directly (except for connection establishment). A simple example is shown below; it executes the
object MM.DAY.
Context initctx = new InitialContext();
ConnectionFactory factory = (ConnectionFactory) initctx.lookup
("java:comp/env/eis/UC4");
AdapterConnection uc4 = factory.getConnection();
ExecuteObject execute = new ExecuteObject(new UC4ObjectName("MM.DAY"));

uc4.sendRequestAndWait(execute);
...
uc4.close();
See also:
ApplicationInterface
48 | Chapter 7 AE Release Manager
7 AE Release Manager
7.1 Application Release Automation

Application Release Automation is an application that can be used to define and activate the installation
procedures of any applications of your choice and to administer their versions. The deployment procedures
are handled through Workflow objects of the Automation Engine that are specifically configured for
deployment. This document describes the interaction between the products Application Release
Automation, Automation Engine and Enterprise Control Center (ECC) and explains how deployment
workflows work.
You require an Automation Engine for both, the Enterprise Control Center and the ARA because they use
the Automation Engine's user and authorization system.
Deployment workflows are defined in the ECC or the UserInterface of the Automation Engine. Note that
you must define them in a way that they can be used and activated by Application Release Automation.
When you use the UserInterface for your definitions, you must configure the Deployment tab of the
related workflow that should be used as the deployment workflow.
You can only define deployment workflows in AE clients in which the setting DEPLOYMENT_CLIENT
of the variable UC_CLIENT_SETTINGS is set to "Y".
When you have created the required deployment workflows, you can activate the installation procedures
using Application Release Automation. The parameters of the applications are now passed from the
Release Manager to the Automation Engine and the related deployment workflows start.
You can also start deployment workflows directly in the Automation Engine or the Enterprise Control
Center. For this purpose, the relevant data is retrieved from Application Release Automation and the
workflow is updated.
Product Deployment task

Chapter7 AE Release Manager | 49
Enterprise Control Center l Definition of deployment workflows in the

Automation Engine (Process Assembly
perspective)
l Activation of deployment workflows
Automation Engine l User and authorization system for the
ECC and the Application Release
Automation
l Definition of deployment workflows
l It processes the deployment workflows.
l Activation of deployment workflows
Application Release Automation l Definition of the deployment procedures of
applications
l Deployment workflows
7.2 Executing Deployment Workflows

Deployment workflows can be performed via Application Release Automation as well as via the
Automation Engine or the Enterprise Control Center. The following description provides information on the
requirements and the process.
General
Deployment workflows are workflows that were specially defined for Application Release Automation.
Deployment workflows are usually activated via Application Release Automation and all
values/parameters are forwarded to the Automation Engine. However, it is also possible to start workflows
like this via the Automation Engine UserInterface. In this case, all parameters/values required to execute
the deployment workflow are determined by Application Release Automation.
Requirements
JWP
Within the Automation Engine system, a Java-based work process (JWP) must be installed and started.
The JWP installation instructions can be found in the Administration Guide.
UC_CLIENT_SETTINGS
The following settings must be set in the UC_CLIENT_SETTINGS VARA object in every client in which
deployment workflows are to be started:
UC_CLIENT_SETTINGS Description
Setting Value
ARA_WS_INT URL to the desired Full URL (including protocol and port) of the Application
Application Release Release Automation instance
Automation instance
50 | Chapter 7 AE Release Manager
DEPLOYMENT_ Y Specifies whether the client should be used for Application

CLIENT Release Automation deployments. The Deployment tab of
workflows is only displayed if this setting is activated.
Importing the HTTPS Certificate

In order to enable communication between JWP and ARA, the ARA Web application certificate must be
added to the keystore of the Java runtime environment, under which the JWP is started. To do this, import
the certificate (e.g., "test.cer" file) with the Java keytool, which is located in the BIN directory of the Java
home directory:
keytool -import -keystore cacerts -file <Path and file name of the certificate>
Next, enter the Java keystore password and confirm the "Trust this certificate?" request with "yes".
How the HTTPS certificate for the ARA Web application is set and exported is described in the
Application Release AutomationARA documentation.
Workflow
If a workflow that was configured as a deployment workflow via the Deployment tab is activated, the
Automation Engine sends a request to the ARA instance (1). Specifically, the deployment descriptor is
requested – a package with all of the parameters required to execute the deployment workflow. In the next
step (2), general parameters of the Automation Engine (workflow RunID, content of the Deployment tab
such as workflow name and application name), which are required for the request, are transmitted to ARA.
In the final step (3), the ARA instance transmits all of the parameters/ values to the Automation Engine and
the workflow is continued.
Workflows waiting for the ARA parameter have the following status:
l Task status: RESOLVE_EXTERNAL_PARAMETER

l Status text: Waiting for external pre-condition
l Remote status: Waiting for external parameters
Chapter Glossary | 51
Glossary
This glossary lists all specific technical terms in alphabetical order.
ABCDEFGHIJKLMNOPQRSTUVWXYZ
A
l ARA Client
Refers to a computer on which a ARA/Deployment Manager/Automation Engine user works.
l admin computer
Admin computer refers to the computer that is used by an administrator for e.g. Automation Engine
or database administration purposes.
C
l configuration
A set of constituent components that make up a system. This includes information on how the
components are connected including the settings applied.
D
l Download Center
The Download Center (http://downloads.automic.com/) is the place where you find everything you
need to know about your Automic solution to make sure you are using our products to their fullest
potential.
l database
A database is an organized collection of data including relevant data structures.
l department
Department name to which the Automation Engine user belongs.
G
l graphical user interface
A graphical user interface (GUI) is a human to machine interface based on windows, icons and
52 | Chapter Glossary
menus which can be operated by a computer mouse in addition to a keyboard. In contrast to

command line interface (CLI).
I
l ILM
Stands for Information Lifecycle Management, which refers to a wide-ranging set of strategies for
administering storage systems on computing devices.
J
l Java work process
The Java work process, implemented in Java, is used to host special services, which have been
developed in Java.
P
l package module
A package module is a group of related package types, e.g. Feature, Change Request, or Bug. It
defines how the packages are displayed in the GUI and the features enabled for each package type.
l password
A secret combination of characters for a Automation Engine user.
R
l RichClient
Deprecated Term. Replaced by: UserInterface
l rollback scope
The scope of a workflow to roll back. For a rollback on a job the scope is this single task while for a
rollback on a workflow the scope is this workflow and all sub-workflows in arbitrary depth.
Chapter Glossary | 53
S
l Service Manager
The Service Manager serves to start, stop and access components such as the Automation Engine
processes or agents from a central point.
T
l token
A token is used for authentication within a session between a client and a server. A (soft) token is a
unique identifier which is generated and sent from a central server to a client software. The client
uses the token to authenticate each request.
U
l user name
Name of the Automation Engine user.
V
l vSphere
vSphere is a virtualization platform for building cloud infrastructures by VMware.
W
l web application
A web application is an application that is accessible over a network (Internet or intranet) and is
typically coded in a programming language like Java or JavaScript, combined with a markup
language like HTML. Web applications are provided on web servers and web browsers are used as
GUI on client computers.

Automation - Engine APPLICATION INTEGRATION GUIDE en PDF

Diunggah oleh

Informasi Dokumen

Judul Asli

Hak Cipta

Format Tersedia

Bagikan dokumen Ini

Bagikan atau Tanam Dokumen

Opsi Berbagi

Apakah menurut Anda dokumen ini bermanfaat?

Apakah konten ini tidak pantas?

Hak Cipta:

Format Tersedia

Automation - Engine APPLICATION INTEGRATION GUIDE en PDF

Diunggah oleh

Hak Cipta:

Format Tersedia

Automation Engine 11

ONE Automation Platform

© Copyright Automic Software GmbH. All rights reserved.

1.1 About the CallAPI 1

1.2 Using the CallAPI 1

1.3 Platforms for CallAPIs 3

1.3.1 CallAPI for BS2000 3

1.3.2 CallAPI for GCOS8 5

1.3.3 CallAPI for Java 6

1.3.4 CallAPI for NSK 7

1.3.5 CallAPI for z/OS 7

1.3.6 CallAPI for OS/400 8

1.3.7 CallAPI for SAP 9

1.3.8 CallAPI for UNIX 10

1.3.9 CallAPI for VMS 11

1.3.10 CallAPI for VSE 11

1.3.11 CallAPI for Windows 12

1.4 Using CallAPI with Your Own Programs 12

1.4.4 Visual Basic 19

2.1 Password Exit 21

3.1 Rapid Automation 24

4.2 Using this Interface 27

4.3 Guide to Using the AE.ApplicationInterface 27

4.4 Object Classes 28

4.5 Classes for Workflows and Schedules 30

4.6 Classes for Activities 32

4.7 Classes for Statistics and Reports 33

4.8 Classes for the System Overview 35

4.9 Starting and Stopping Clients by using the Application Interface 35

5.2 Using the Webservice 38

5.3 Webservice Operations 41

7.1 Application Release Automation 48

7.2 Executing Deployment Workflows 49

1.1 About the CallAPI

Using the CallAPI

1.2 Using the CallAPI

CallAPI and Individual Program

CallAPI and Utility

Example of calling the CallAPI in Windows:

UCXBXXXC SCRIPT=C:\AUTOMIC\CALLAPI\script.txt LOGON=98, SMITH, AE

l Example for Windows:

l Example for UNIX:

Connection to the Automation Engine

About the CallAPI

1.3 Platforms for CallAPIs

1.3.1 CallAPI for BS2000

1. CallAPI and own program

l CallAPI and own program

2. CallAPI and utility

l CallAPI and utility

The script to be executed is available in the file MY.SCRIPT.FILE:

:SEND_MSG RS,DEV,'MESSAGE FROM THE BS2000 CALL INTERFACE &NAME.'

About the CallAPI

1.3.2 CallAPI for GCOS8

1. CallAPI and own Program

l CallAPI and own program

1. CallAPI and Utility

l CallAPI and utility

In the first example, the CallAPI for GCOS8 is called.

About the CallAPI

1.3.3 CallAPI for Java

1. CallAPI and own program

The CallAPI may be called from your own Java program.