IBM BJ0NJML Integration Guide - Page 87

AddChange action, Default action attributes, Comparison of the, change, replace, and add

Page 87 highlights

AddChange action Default action attributes Comparison of the change, replace, and add change actions Object Structure Element The AddChange action is like the replace action, except that any existing child record that is not specified in the message is not deleted. An AddChange action on the primary object adds the primary record and all the sub-records that are provided in the message, if the primary record does not exist in the database. If the primary record does exist, it is updated along with any child record that is provided. Existing child records that are not provided in the inbound message are not deleted. The AddChange action does not apply to child objects. The AddChange action is useful in cases where the object structure definition contains elements that are not available in the external system. For example, the MXVENDORInterface enterprise service contains both vendor and contact information. If the database maintains the contacts for a vendor, and external systems maintain the vendor definition itself, sending an inbound vendor record with the action value equal to null results in the deletion of contact information in the database. However, sending a vendor record with the action value equal to AddChange results in the update of vendor information; the contact information remains. The system processes the message in the following ways when an inbound XML message does not contain an action attribute: T If the primary record does not exist in the database, the system performs add action processing. T If the primary record exists in the database, the system performs replace action processing. The following diagram contrasts the Change, Replace, and AddChange actions applied to a hypothetical purchase order. The Original PO diagram shows the initial purchase order. It contains three line items, each with two cost lines. The Changes to the PO diagram shows the changes to the purchase order that originated in the Purchase Orders application. T A change to the POCOST2 record associated with POLINE1 T Deletion of the POCOST3 record associated with POLINE1 T A change to POLINE2 Integration XML and Schemas 73

  • 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
  • 314
  • 315
  • 316
  • 317
  • 318
  • 319
  • 320
  • 321
  • 322
  • 323
  • 324
  • 325
  • 326
  • 327
  • 328
  • 329
  • 330

Object Structure Element
Integration XML and Schemas
73
AddChange action
The AddChange action is like the replace action, except that any existing child
record that is not specified in the message is not deleted. An AddChange action
on the primary object adds the primary record and all the sub-records that are
provided in the message, if the primary record does not exist in the database. If
the primary record does exist, it is updated along with any child record that is
provided. Existing child records that are not provided in the inbound message are
not deleted. The AddChange action does not apply to child objects.
The AddChange action is useful in cases where the object structure definition
contains elements that are not available in the external system.
For example, the MXVENDORInterface enterprise service contains both vendor
and contact information. If the database maintains the contacts for a vendor, and
external systems maintain the vendor definition itself, sending an inbound
vendor record with the action value equal to null results in the deletion of contact
information in the database. However, sending a vendor record with the action
value equal to AddChange results in the update of vendor information; the
contact information remains.
Default action attributes
The system processes the message in the following ways when an inbound XML
message does not contain an action attribute:
If the primary record does not exist in the database, the system performs
add action processing.
If the primary record exists in the database, the system performs replace
action processing.
Comparison of the
change, replace, and add
change actions
The following diagram contrasts the Change, Replace, and AddChange actions
applied to a hypothetical purchase order.
The Original PO
diagram
shows the initial purchase order. It contains three line
items, each with two cost lines.
The Changes to the PO diagram
shows the changes to the purchase order that
originated in the Purchase Orders application
.
A change to the POCOST2 record associated with POLINE1
Deletion of the POCOST3 record associated with POLINE1
A change to POLINE2