HP BL680c XenEnterprise Management API - Page 9

Making XML-RPC Calls

Page 9 highlights

1.4. MAKING XML-RPC CALLS CHAPTER 1. INTRODUCTION Value 81547a35-205c-a551-c577-00b982c5fe00 61c85a22-05da-b8a2-2e55-06b0847da503 1d401ec4-3c17-35a6-fc79-cee6bd9811fe 1.4 Making XML-RPC Calls 1.4.1 Transport Layer The following transport layers are currently supported: • HTTP/S for remote administration • HTTP over Unix domain sockets for local administration 1.4.2 Session Layer The XML-RPC interface is session-based; before you can make arbitrary RPC calls you must login and initiate a session. For example: session_id session.login_with_password(string uname, string pwd) Where uname and password refer to your username and password respectively, as defined by the Xen administrator. The session id returned by session.login with password is passed to subequent RPC calls as an authentication token. A session can be terminated with the session.logout function: void session.logout(session_id session) 1.4.3 Synchronous and Asynchronous invocation Each method call (apart from methods on "Session" and "Task" objects and "getters" and "setters" derived from fields) can be made either synchronously or asynchronously. A synchronous RPC call blocks until the return value is received; the return value of a synchronous RPC call is exactly as specified in Section 1.3.2. Only synchronous API calls are listed explicitly in this document. All asynchronous versions are in the special Async namespace. For example, synchronous call VM.clone(...) (described in Chapter 2) has an asynchronous counterpart, Async.VM.clone(...), that is non-blocking. Instead of returning its result directly, an asynchronous RPC call returns a task-id; this identifier is subsequently used to track the status of a running asynchronous RPC. Note that an asychronous call may fail immediately, before a task-id has even been created-to represent this eventuality, the returned task-id is wrapped in an XML-RPC struct with a Status, ErrorDescription and Value fields, exactly as specified in Section 1.3.2. The task-id is provided in the Value field if Status is set to Success. The RPC call (ref_task Set) Task.get_all(session_id s) 9

  • 1
  • 2
  • 3
  • 4
  • 5
  • 6
  • 7
  • 8
  • 9
  • 10
  • 11
  • 12
  • 13
  • 14
  • 15
  • 16
  • 17
  • 18
  • 19
  • 20
  • 21
  • 22
  • 23
  • 24
  • 25
  • 26
  • 27
  • 28
  • 29
  • 30
  • 31
  • 32
  • 33
  • 34
  • 35
  • 36
  • 37
  • 38
  • 39
  • 40
  • 41
  • 42
  • 43
  • 44
  • 45
  • 46
  • 47
  • 48
  • 49
  • 50
  • 51
  • 52
  • 53
  • 54
  • 55
  • 56
  • 57
  • 58
  • 59
  • 60
  • 61
  • 62
  • 63
  • 64
  • 65
  • 66
  • 67
  • 68
  • 69
  • 70
  • 71
  • 72
  • 73
  • 74
  • 75
  • 76
  • 77
  • 78
  • 79
  • 80
  • 81
  • 82
  • 83
  • 84
  • 85
  • 86
  • 87
  • 88
  • 89
  • 90
  • 91
  • 92
  • 93
  • 94
  • 95
  • 96
  • 97
  • 98
  • 99
  • 100
  • 101
  • 102
  • 103
  • 104
  • 105
  • 106
  • 107
  • 108
  • 109
  • 110
  • 111
  • 112
  • 113
  • 114
  • 115
  • 116
  • 117
  • 118
  • 119
  • 120
  • 121
  • 122
  • 123
  • 124
  • 125
  • 126
  • 127
  • 128
  • 129
  • 130
  • 131
  • 132
  • 133
  • 134
  • 135
  • 136
  • 137
  • 138
  • 139
  • 140
  • 141
  • 142
  • 143
  • 144
  • 145
  • 146
  • 147
  • 148
  • 149
  • 150
  • 151
  • 152
  • 153
  • 154
  • 155
  • 156
  • 157
  • 158
  • 159
  • 160
  • 161
  • 162
  • 163
  • 164
  • 165
  • 166
  • 167
  • 168
  • 169
  • 170
  • 171
  • 172
  • 173
  • 174
  • 175
  • 176
  • 177
  • 178
  • 179
  • 180
  • 181
  • 182
  • 183
  • 184
  • 185
  • 186
  • 187
  • 188
  • 189
  • 190
  • 191
  • 192
  • 193
  • 194
  • 195
  • 196
  • 197
  • 198
  • 199
  • 200
  • 201
  • 202
  • 203
  • 204
  • 205
  • 206
  • 207
  • 208
  • 209
  • 210
  • 211
  • 212
  • 213
  • 214
  • 215
  • 216
  • 217
  • 218
  • 219
  • 220
  • 221
  • 222
  • 223
  • 224
  • 225
  • 226
  • 227
  • 228
  • 229
  • 230
  • 231
  • 232
  • 233
  • 234
  • 235
  • 236
  • 237
  • 238
  • 239
  • 240
  • 241
  • 242
  • 243
  • 244
  • 245
  • 246
  • 247
  • 248
  • 249
  • 250
  • 251
  • 252
  • 253
  • 254
  • 255
  • 256
  • 257
  • 258
  • 259
  • 260
  • 261
  • 262
  • 263
  • 264
  • 265
  • 266
  • 267
  • 268
  • 269
  • 270
  • 271
  • 272
  • 273
  • 274
  • 275
  • 276
  • 277
  • 278
  • 279
  • 280
  • 281
  • 282
  • 283
  • 284
  • 285
  • 286
  • 287
  • 288
  • 289
  • 290
  • 291
  • 292
  • 293
  • 294
  • 295
  • 296
  • 297
  • 298
  • 299
  • 300
  • 301
  • 302
  • 303
  • 304
  • 305
  • 306
  • 307
  • 308
  • 309
  • 310
  • 311
  • 312
  • 313

1.4. MAKING XML-RPC CALLS
CHAPTER 1. INTRODUCTION
<member>
<name>Value</name>
<value>
<array>
<data>
<value>81547a35-205c-a551-c577-00b982c5fe00</value>
<value>61c85a22-05da-b8a2-2e55-06b0847da503</value>
<value>1d401ec4-3c17-35a6-fc79-cee6bd9811fe</value>
</data>
</array>
</value>
</member>
</struct>
1.4
Making XML-RPC Calls
1.4.1
Transport Layer
The following transport layers are currently supported:
HTTP/S for remote administration
HTTP over Unix domain sockets for local administration
1.4.2
Session Layer
The XML-RPC interface is session-based; before you can make arbitrary RPC calls you must login
and initiate a session. For example:
session_id
session.login_with_password(string uname, string pwd)
Where
uname
and
password
refer to your username and password respectively, as defined by the
Xen administrator.
The
session
id
returned by
session.login
with
password
is passed to
subequent RPC calls as an authentication token.
A session can be terminated with the
session.logout
function:
void
session.logout(session_id session)
1.4.3
Synchronous and Asynchronous invocation
Each method call (apart from methods on “Session” and “Task” objects and “getters” and “set-
ters” derived from fields) can be made either synchronously or asynchronously. A synchronous
RPC call blocks until the return value is received; the return value of a synchronous RPC call is
exactly as specified in Section 1.3.2.
Only synchronous API calls are listed explicitly in this document. All asynchronous versions are
in the special
Async
namespace.
For example, synchronous call
VM.clone(...)
(described in
Chapter 2) has an asynchronous counterpart,
Async.VM.clone(...)
, that is non-blocking.
Instead of returning its result directly, an asynchronous RPC call returns a
task-id
; this identifier
is subsequently used to track the status of a running asynchronous RPC. Note that an asychronous
call may fail immediately, before a
task-id
has even been created—to represent this eventuality,
the returned
task-id
is wrapped in an XML-RPC struct with a
Status
,
ErrorDescription
and
Value
fields, exactly as specified in Section 1.3.2.
The
task-id
is provided in the
Value
field if
Status
is set to
Success
.
The RPC call
(ref_task Set)
Task.get_all(session_id s)
9