IBM E02HRLL-G Administration Guide - Page 75

Considerations when creating your own import data, Manual validation of the import file

Page 75 highlights

Considerations when creating your own import data If you decide to create your own import file or to edit an import file that was created by the export utility, there are several things that you must consider. Not only does your XML file need to conform to the XML schema for an import file, but there are rules about the content of the file that are not controlled by the schema. Manual validation of the import file If you invoke your migration utility from the command line using the partner migration script, your data is not validated as it is not using the console. For instance, it is possible to create an incorrect partner ID using a migration script whereas this is not possible using the console. Data entered into the console is validated by the console. For example, you may enter a DUNS ID containing alphabetic characters from the command line, but this is not possible from the console because a DUNS ID must contain numeric characters only. Remember: It is important to manually validate all of your data before you enter it from the command line. Migration configuration type dependencies Configurable items can be broadly classified into three sections based on dependencies, namely Independent Items, First level dependent items, and Complex dependent items. Some configuration types have no dependencies. For example, a partner definition can be created without referring to any other configured entity in the system. Independent items are the configurable items that do not have any dependency before importing them into the target system. Other configuration types cannot exist by themselves because they depend on other entities in the system. For example, a destination is associated with a partner, so it cannot exist unless the partner also exists. To ensure that dependency items are always available, the content and ordering of the items in export and import files are important. When an export is performed, any item that has dependencies must be exported after any dependency items. The XML file reflects this ordering. Using the same logic, when the import is performed, the dependency items are imported before the dependent items. If you selectively export configuration types, you must ensure that you specify dependency types for all dependent types. It is also important if you create an import file using the schema definition. The schema enforces the ordering, but not the content. So if you define an import file incorrectly, for example, you forget to provide a dependency item or incorrectly defining a dependency item, that item will fail when you attempt an import of it. Independent configuration items The following configurable types are independent. Other configuration types depend on these items, but these items do not directly depend on other system items. v Enveloper Scheduling v Event codes v Transport types v Destination types v Envelope profiles v Connection Profiles Chapter 6. Administering partner migration 69

  • 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

Considerations when creating your own import data
If you decide to create your own import file or to edit an import file that was
created by the export utility, there are several things that you must consider. Not
only does your XML file need to conform to the XML schema for an import file,
but there are rules about the content of the file that are not controlled by the
schema.
Manual validation of the import file
If you invoke your migration utility from the command line using the partner
migration script, your data is not validated as it is not using the console. For
instance, it is possible to create an incorrect partner ID using a migration script
whereas this is not possible using the console. Data entered into the console is
validated by the console. For example, you may enter a DUNS ID containing
alphabetic characters from the command line, but this is not possible from the
console because a DUNS ID must contain numeric characters only.
Remember:
It is important to manually validate all of your data before you enter
it from the command line.
Migration configuration type dependencies
Configurable items can be broadly classified into three sections based on
dependencies, namely Independent Items, First level dependent items, and
Complex dependent items. Some configuration types have no dependencies. For
example, a partner definition can be created without referring to any other
configured entity in the system. Independent items are the configurable items that
do not have any dependency before importing them into the target system.
Other configuration types cannot exist by themselves because they depend on
other entities in the system. For example, a destination is associated with a partner,
so it cannot exist unless the partner also exists.
To ensure that dependency items are always available, the content and ordering of
the items in export and import files are important. When an export is performed,
any item that has dependencies must be exported after any dependency items. The
XML file reflects this ordering. Using the same logic, when the import is
performed, the dependency items are imported before the dependent items.
If you selectively export configuration types, you must ensure that you specify
dependency types for all dependent types. It is also important if you create an
import file using the schema definition. The schema enforces the ordering, but not
the content. So if you define an import file incorrectly, for example, you forget to
provide a dependency item or incorrectly defining a dependency item, that item
will fail when you attempt an import of it.
Independent configuration items
The following configurable types are independent. Other configuration types
depend on these items, but these items do not directly depend on other system
items.
v
Enveloper Scheduling
v
Event codes
v
Transport types
v
Destination types
v
Envelope profiles
v
Connection Profiles
Chapter 6. Administering partner migration
69