IBM BS029ML Self Help Guide - Page 178

Portal administration tools, XML configuration interface

Page 178 highlights

Login delay. There are a number of components involved with the Portal login, such as the database, LDAP, WMM configurations, and so on. Portal login is explained in Chapter 4, "WebSphere Portal security" on page 85. In our environment, we had IBM WebSphere Portal V6 with Active Directory. The login time was a bit long (around 18-20 seconds). We performed a TCP dump and analyzed the dump file and found out that there is a 12 second delay from the LDAP server after a request is sent. We then analyzed the search base for Portal and narrowed the cause down to the user and group objectclasses being used and indexed those object classes in the Active Directory server, which immediately reduced the login time from 15-20 seconds to 2 seconds. However, be aware that the indexing might actually cause some impact on the LDAP server, so before implementing our solution or a similar one, take the LDAP server's processing power and memory into consideration. So, it is not the Portal alone that is entirely responsible for the delay; it is worth looking at the other involved components as well. 5.4 Portal administration tools There are some very efficient administration tools available to you to automate the deployments, move the configuration across environments, and so on. You can administer and configure portal resources by using one of the following tools: Portal administration portlets Portal administrative users can use the administration portlets to perform administrative tasks and actions on portal resources, depending on the access rights that the administrative user has on those resources. This includes: Configuring individual portal resources. Configuring individual portal resources, together with their dependent resources. For example, this can be pages and the pages derived from them. Giving other users, for example, subadministrators, limited access rights on selected portal resources. These subadministrators can then perform administrative tasks to the extent that their access rights allow. As the master administrator, you can widen or limit that extent by modifying the access rights for these users on the portal resources. This way, you can delegate administrative tasks as required., or even deploy your own custom developed artifacts, such as portlets, themes, or skins. You cannot use the administration portlets to perform scripted or automated administration or configuration tasks. For more information about the Portal Administration tools, refer to the InfoCenter at: http://publib.boulder.ibm.com/infocenter/wpdoc/v6r0/index.jsp?topic=/com.ibm.wp .ent.doc/wps/adpltadm.html XML configuration interface The XML configuration interface works as follows The XML configuration interface provides a batch processing interface for portal configuration updates. It allows you to export an entire portal configuration or parts of a configuration, for example, specific pages, to an XML file. You can then re-create the exported configuration from such a file on another portal. 164 IBM WebSphere Portal V6 Self Help Guide

  • 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

164
IBM WebSphere Portal V6 Self Help Guide
±
Login delay.
There are a number of components involved with the Portal login, such as the database,
LDAP, WMM configurations, and so on. Portal login is explained in Chapter 4, “WebSphere
Portal security” on page 85.
In our environment, we had IBM WebSphere Portal V6 with Active Directory. The login
time was a bit long (around 18-20 seconds). We performed a TCP dump and analyzed the
dump file and found out that there is a 12 second delay from the LDAP server after a
request is sent. We then analyzed the search base for Portal and narrowed the cause
down to the user and group objectclasses being used and indexed those object classes in
the Active Directory server, which immediately reduced the login time from 15-20 seconds
to 2 seconds. However, be aware that the indexing might actually cause some impact on
the LDAP server, so before implementing our solution or a similar one, take the LDAP
server’s processing power and memory into consideration.
So, it is not the Portal alone that is entirely responsible for the delay; it is worth looking at
the other involved components as well.
5.4
Portal administration tools
There are some very efficient administration tools available to you to automate the
deployments, move the configuration across environments, and so on.
You can administer and configure portal resources by using one of the following tools:
Portal administration portlets
Portal administrative users can use the administration portlets to perform administrative tasks
and actions on portal resources, depending on the access rights that the administrative user
has on those resources. This includes:
±
Configuring individual portal resources.
±
Configuring individual portal resources, together with their dependent resources. For
example, this can be pages and the pages derived from them.
±
Giving other users, for example, subadministrators, limited access rights on selected
portal resources. These subadministrators can then perform administrative tasks to the
extent that their access rights allow. As the master administrator, you can widen or limit
that extent by modifying the access rights for these users on the portal resources. This
way, you can delegate administrative tasks as required., or even deploy your own custom
developed artifacts, such as portlets, themes, or skins.
You cannot use the administration portlets to perform scripted or automated administration
or configuration tasks.
For more information about the Portal Administration tools, refer to the InfoCenter at:
.ent.doc/wps/adpltadm.html
XML configuration interface
The XML configuration interface works as follows
±
The XML configuration interface provides a batch processing interface for portal
configuration updates. It allows you to export an entire portal configuration or parts of a
configuration, for example, specific pages, to an XML file. You can then re-create the
exported configuration from such a file on another portal.