Patent Grant
7167874
Ser. No. 10/334,269 filed Dec. 31, 2002 entitled “SYSTEM AND METHOD FOR THE AGGREGATION OF PLACE INFORMATION IN A MULTI-SERVER SYSTEM” (pending);
Ser. No. 10/334,261, filed Dec. 31, 2002 entitled “SYSTEM AND METHOD FOR AGGREGATING USER PROJECT INFORMATION IN A MULTI-SERVER SYSTEM” (U.S. Pat. No. 6,904,439, issued 7 Jun. 2005);
Ser. No. 10/334,296, filed Dec. 31, 2002, entitled “SYSTEM AND METHOD FOR CENTRAL REFRESH OF PLACE OBJECTS” (pending);
Ser. No. 10/334,268, filed Dec. 31, 2002, entitled “SYSTEM AND METHOD FOR SEARCHING A PLURALITY OF DATABASES DISTRIBUTED ACROSS A MULTI SERVER DOMAIN” (allowed, issue fee paid);
Serial No. 09/752,120, filed 29 Dec. 2000, entitled “METHOD AND SYSTEM FOR CREATING A THEME OF A PLACE TO BE USED AS A TEMPLATE FOR OTHER PLACES” (U.S. Pat. No. 7,028,262, issued 11 Apr. 2006);
Ser. No. 10/349,412, entitled “SYSTEM AND METHOD FOR HIERARCHICALLY INVOKING RE-ENTRANT METHODS ON XML OBJECTS” (pending);
Ser. No. 10/349,427, entitled “SYSTEM AND METHOD FOR INTEGRATING PROJECTS EVENTS WITH PERSONAL CALENDAR AND SCHEDULING CLIENTS” (pending);
Ser. No. 10/349,356, entitled “SYSTEM AND METHOD FOR INTEGRATING ONLINE MEETING MATERIALS IN A PLACE” (pending);
are assigned to the same assignee hereof and contain subject matter related, in certain respect, to the subject matter of the present application. The above identified patent applications are incorporated herein by reference.
1. Technical Field of the Invention
This invention relates to administration of project spaces. More particularly, it relates to command line administration of places using XML objects.
2. Background Art
Similar approaches include command line piping in OS shells, but none that use object representations of XML. It allows the transfer of object as input and output in this way. It is important to note that this revolves around working with places.
IBM® Lotus® QuickPlace™ is a self-service Web tool for team collaboration. QuickPlace allows a user to publish, share, and track all information relevant to a project. Teams can then use QuickPlace to store resources (such as files, discussions, and schedules) related to a project in a common place, where everyone can access the latest information.
QPTool newsletter command is used to send daily and weekly newsletters to members of places. This command replaces the QuickPlace (QP) 2.0 quickplacenightly send newsletter feature.
In QP 2.0 administration functions were scattered amongst various tools. Some required the use a web user interface (UI), the Notes client, and a special QP administration utility. These various administration utilities did not provide for a simple batching or automatic mechanism to be built according to the administrator's policies.
The Lotus K-Station product presents QuickPlaces as projects or project spaces for a user. All pertinent project spaces on one QuickPlace server for a particular user are presented here. However, K-Station has no notion nor facility for aggregation across multiple QuickPlace servers.
The Extensible Markup Language (XML) is a W3C-endorsed standard for document markup. It defines a generic syntax used to mark up data with simple, human-readable tags and provides a standard format for computer documents which may be customized for domains such as web sites, electronic data interchange, and so forth. XML is a meta-markup language for text documents, and XML documents are trees. Data is included in XML documents as strings of text, and the data are surrounded by text markup that describes the text. A particular unit of data and markup is called an element. As a meta-markup language, XML does not have a fixed set of tags and elements, and elements may be defined as needed. (See Elliotte Rusty Harold & W. Scott Means. XML in a Nutshell. Sebastopol, Calif.: O'Reilly and Associates, 2001).
Domino, IBM, the IBM Logo, Lotus, Notes, QuickPlace and SameTime are trademarks of International Business Machines in the United States, other countries, or both.
It is an object of the invention to provide an improved system and method for administering project spaces.
A method is provided for command line administration of project spaces using extensible markup language objects by storing project data in a data store, the data store including a project catalog database and a plurality of objects in project spaces; receiving a first user command including an output command and arguments with respect to an object in the data store; executing the first user command against the object in the data store to generate a first extensible markup language file; receiving at least one subsequent user commands, each subsequent user command including an input command; and executing a first subsequent second user command against the first extensible markup language file and the data store to manage the objects in the data store and generate a resultant output extensible markup language file when needed for reentrant processing.
A system is provided for command line administration of project spaces using extensible markup language objects including a data store for storing project data, the data store including a project catalog database and a plurality of objects in project spaces; a command line element for receiving a first user command including an output command and arguments with respect to an object in the data store; a first command processor for executing the first user command against the object in the data store to generate a first extensible markup language file; a second command processor for receiving at least one subsequent user commands, each subsequent user command including an input command, and executing a first subsequent second user command against the first extensible markup language file and the data store to manage the objects in the data store and generate a resultant output extensible markup language file when needed for reentrant processing.
In accordance with an aspect of the invention, there is provided a computer program product configured to be operable for command line administration of project spaces using extensible markup language objects.
Other features and advantages of this invention will become apparent from the following detailed description of the presently preferred embodiment of the invention, taken in conjunction with the accompanying drawings.
In accordance with the preferred embodiments of the invention, system and method are provided for administering multiple places deployed on multiple servers. The QuickPlace command line interface (CLI), also referred to as the QPTOOL, provides server administrators with a familiar, efficient way to leverage QuickPlace administration functions. The CLI makes it possible for administrators to run QuickPlace administration utilities from the server console and from the operating system shell, and to automate common tasks and batch operations using standard tools. The implementation approach to the CLI features enables a remote server administration API. Thus, QPTool accepts XML inputs and couples to XML outputs to provide flexibility in creating administration scripts that can run automatically to carry out administration policies.
In an exemplary embodiment, using the IBM® Lotus® Domino™ console, the administrator can tell the QuickPlace server to run any command against a specified input file, with results logged to a specified output file. The administrator can run the same commands using the OS shell C\: prompt. Common tasks can be automated by the administrator writing batch processes using OS shell scripting techniques. All commands are wrappers onto an exposed QuickPlace Java API, and thus are Web serviceable. A wrapper is code implementation that protects or buffers callers from an inner code implementation and complexity, usually for ease of use, or to provide an abstraction for callers to insulate them from a particular detail of the implementation, so that the inner implementation can be altered without a caller needing to change any code.
Referring to
Throughout this specification, the generic term “project” and more specific terms “place” or “QuickPlace” are used substantially interchangeably. Place and QuickPlace, terms used primarily connection with the IBM QuickPlace and IBM Lotus Domino products, are specific examples of projects. “Places”, and as used herein “projects”, are databases or other entities containing searchable data to which access is controlled, such as by access control lists in the place itself.
As illustrated in
In a preferred embodiment, this service is implemented in an abstract sense, in that each server 100 implements a notion of service, which in this sense is a multi-server deployment of QuickPlace servers 101 that can be treated as a consistent unit of service for administration and in the user interface.
A QuickPlace service 100 comprises multiple QuickPlace servers 101 and/or QuickPlace clusters, which: (1) are in the same Domino domain; (2) share the same user directory and authentication system; (3) are on the same user network (i.e., are not separated by a firewall); and (4) are administered by the same administration team. These constraints are enough to ensure across the service that: (1) servers 101 can be configured consistently; (2) servers 101 can communicate and share data with each other; (3) user identities are in the same name space and do not collide; and (4) single sign on authentication can be implemented.
Referring to
Referring to
Referring to
XML is created to represent, for example, a QuickPlace object. Each API capable object 82 has an action attribute associated with it. This action attribute represents the API to be invoked. The XML 70 is passed 86 into a Java method 76, which then processes the XML and returns 87 an updated form 72 of the input XML 70. Upon completion, XML 72 similar to input XML 70 is returned. Table 1 shows an example input document 70.
The XML of Table 1 (input tree 70) is used to lock the place haikuteam on the local server. After the lock API is invoked (that is, node 82 is processed) the XML (resultant tree 72) of Table 2 is returned. This resultant tree 72 includes as child node 90 the action result element at lines 6–8, and new script or child node 92 at line 5. (Places element at lines 3–7 is represented by node 80, but
When an action (Table 1 lines 4) is executed on a QuickPlace object, a child node 90 (Table 2 lines 6–8) is created with the action status (Table 2 lines 7) . That is, this status represents if the action was successful through the returned status code (Table 2 lines 7) in the action_result node (Table 2 lines 6–8).
In accordance with the exemplary embodiment based on a QuickPlace environment, all object representations adhere to the QuickPlace Object DTD of Table 3.
Referring to
QP service 100 represents the service (Table 1 lines 1, Table 2 lines 1, Table 3 lines 2) . A service is an object that signifies a group of servers in an organization. There is one instance of a service 100 for any group of servers. Thus, a QuickPlace service is a multi-server deployment of QuickPlace servers that can be treated as a consistent unit of service for administration and in the user interface.
Server 101 represents a physical or virtual server entity or element (Table 1 lines 2, Table 3 lines 4–10) that is addressable and may contain a group of places and place types.
A QuickPlace cluster is treated as a single virtual server in the service model.
A PlaceType 102 is a mechanism for software reuse. By using it, a user may take a snapshot of a QuickPlace 114 and make a template or PlaceType for other users to create new QuickPlaces. A PlaceType allows the user (administrator, author, etc.) to control the design logic and content of a child QuickPlace 101 by refreshing it with changes made its it PlaceType.
Place 103 is an object that represents a place or project (Table 1 lines 4–6, Table 3 lines 19–26). This is the entry point into a particular project and all its data and all its manipulations—including logical methods such as lock, remove, member, and so forth.
QP members 104 (Table 3 line 57) represents members of place 114. There are many kinds of members, including person 115 (Table 3 lines 27–39), local person 116 (Table 3 lines 27–39 with attribute local=true at line 32), group 117 (Table 3 lines 40–46) and local group 118 (Table 3 lines 40–46 with local attribute=true at line 44). Members 104 are the seed of any membership operation done in place 103. Each member has an associated identity and profile (Table 3 lines 58, 60).
Room 105 (Table 3 lines 48–52) represents a room 113 (Table 3 line 47) within a project 114 (or place, Table 3 lines 19 –26).
In an exemplary embodiment, a project is a place, which is content and membership (Table 3, line 19, |members?|, and line 57) associated with that content.
A room 105 (Table 3, lines 48–52) controls access to a subset of the data in the project 114.
Each place 114 may contain many themes 110. A theme (Table 3 line 78) is an object that represents how to lay out the user interface for this project, and how to brand the user interface.
Rooms 113 (Table 3 line 47) represent multiple rooms (Table 3 lines 48–52) in a place 114 (Table 3 lines 19–26).
Places 114 (Table 3 line 18) represents multiple places (Table 3 lines 19–26) on a server 119.
Each object represents itself as xml 70 and recreates itself from the exported xml 72.
Referring to
Some entries 331–334, 341–345 are created or updated in the Host catalog 120 in real time—substantially the moment an event happens. Other entries are created or updated manually by a server task, or on a scheduled basis.
As is represented by line 300, it is essential that certain data be sent in real time to avoid conflicts. For example, in a QuickPlace service 100 there cannot be two places 114, 139 with the same name. The creation of a new place 139 is an event that creates a new entry in Catalog 120 in real time. When a user creates a new place, QuickPlace server 101 first checks catalog 120 database 129 for that name 323 before creating a new entry. If it finds an existing place with that name, the user is prompted to choose a different name. If the creation of a place 139 did not immediately create an entry, it would be possible for two users to successfully create two places with the same name, which would cause a conflict when QuickPlace attempted to create entries for both in the catalog 120. To increase availability of host catalog 120, the Domino clustering feature can be used to make several host catalog servers 280 available.
Data can be updated in catalog 120 using a QPTool placecatalog-push command or on a schedule on the QuickPlace server 101.
Host catalog 120 contains information in servers view 127 about servers and in places view 129 about places. Thus, in host catalog 120, there is an entry 331 for server A 101. For simple case aggregation, or data update, projects 114, 139 are preconfigured as is represented by line 300 to point to host catalog server 280 immediately when changes occur, or as is represented by line 302 at a particular time (say, each day at 2:00 a.m.) Immediate changes may thus be made when change actions occur such as place create, place remove, place lock, change access (add/remove readers, authors, managers), and change title. Scheduled updates may be made, for example, for changes such as last modified, title, size, last accessed.
Complex aggregation is required when working with clusters 318.
Each entry in catalog 120 has a virtual indicia entry 325, 326 and master indicia entry 328, 327. A master entry, such as entry 343, is the entry through which all access to the catalog occur for a given cluster of servers 312, 314, 316. In
A virtual server is a server that does not have project (aka, place) data, but knows how to connect place users to the project servers 314, 316 which do have place data 320, 322. Server LB1312 is a virtual server because it does not have place data in a database. Project servers A 101, B 314, and C 316 are not virtual servers because they do have place data in databases X 114, Y 139, and Z 320, 322. Databases Z 320, 322 are clustered, so they are identical; a change to one is immediately replicated to the other.
Complex aggregation for clusters is done by sending immediate updates as are represented by lines 304 and 306 to master entries 334, 343. All other updates as are represented by lines 308 and 310 to the corresponding place entry 344, 345 for the respective servers B 314, C 316. For scheduled update, host catalog server 280 executes a process to merge entries from the virtual master LB1312 (see entry 343, which as virtual field 235 and master field 327 set) to merge entries from the virtual master entry 343 to entries 344, 345 for other servers B 314, C 316.
The Host catalog feature is enabled by the administrator creating a host catalog database 120 and a configuration file.
Host catalog 120 may be created by using a PlaceCatalog.ntf template to create a Notes database. The template is put in the Domino data directory where QuickPlace is installed. Access control on catalog 120 is granted only to all the project servers 101, etc. and to administrators of the system.
The PlaceCatalog feature is configured for each server 101, etc., that interacts with PlaceCatalog server 280 through a configuration file formatted as xml. That is, each QuickPlace server 101, etc., that wishes to operate with a PlaceCatalog 120 must have its own configuration file. The name of the file is qpconfig.xml, and is set forth in Table 4.
Cluster_settings (Table 1, lines 8–12) contains settings related to the clustering feature as it relates to the server associated with this configuration file. The PlaceCatalog understands the clustering configuration so it can make the proper decisions when registering places with the Host catalog. This cluster_settings section includes the following:
1. Master
In QuickPlace clustering there is a concept of a “master” server 312. It specifies which server in the cluster 318 acts as the “entry point” to a QuickPlace 320, 322. It can be a QuickPlace server or it can be a network dispatcher which acts as a “virtual” server. The following argument is available in this section:
virtual=“yes”
virtual=“no” (default)
which specifies if the master server is a device other than a QuickPlace server such as a network dispatcher or local director 312. Master includes:
2. Hostname
which specifies the hostname in tcpip format of the master server 312 in a QuickPlace cluster 318 (i.e. qp.acme.com). This is the host name of a network dispatcher or local director (virtual must be “yes” above) or the hostname of a QuickPlace server (virtual must be “no” above)
Each time a place is created, it is registered in real-time with host catalog server 280. This means that PlaceCatalog 120 is configured on a QuickPlace server 101, and the host catalog server 280 must be operational for users to be able to create places.
When a QuickPlace manager adds, removes or changes a member's access level, an update is done to host catalog 120.
Host catalog 120 may be queried to retrieve a list of places 114 in which a user, or one of the groups 117, 118 of which the user is a member 104, 116, is a member 104.
When a user performs a search scoped to a number of QuickPlaces 114, 139, 320, 322 on one or more servers 101, 312, the system uses a search domain server to perform the search and it also uses the host catalog server 280 to properly construct the URLs to the places found in the search request. For this reason, the search domain server (not separately shown, but similar to server 101) is configured to recognize host catalog server 280.
Last accessed updates may be made in real time (every 1 minute) to host catalog 120.
Certain information maintained in host catalog 120 may not updated in real-time. Examples include place size and the last time it was accessed or modified. This information must be updated in batch mode. This is accomplished by running a qptool utility function “UpdatePlaceCatalog” on, for example, a daily basis. This can be automated as a Domino program entry similar to the QuickPlaceNightly tool.
When using QuickPlace clusters 318, host catalog 120 data is maintained for each node 312, 314, 316 in the cluster as well as for a virtual place representing the combination of all nodes if and only if a network dispatcher or local director has been configured and the proper settings reflect it in the qpconfig.xml configuration file (Table 4). In this case, real-time updates to the catalog are done to the virtual place entry 343 and the non-real time updates are done to each of the cluster node entries 344, 345. This allows the administrator flexibility in knowing differences in access and size for each of the nodes in the cluster.
The last accessed time updates may present a problem in large installations. For this reason, a replica of the Host catalog 120 may be created for each QuickPlace server 101.
There are two QuickPlace server cluster environment alternatives for storing QuickPlace server cluster data in Host catalog 120.
A QPTool placecatalog command with the -update flag set synchronizes the place entries 344, 345 that correspond to the physical servers 314, 316, and the place entries 343 that correspond to the virtual server 312.
To set up a virtual server 312 for a QuickPlace cluster 318, a network dispatcher is configured, such as IBM Network Dispatcher Version 3.6, with proper settings configured on each server 312, 314, 316 in the cluster 318.
Referring to
In a preferred embodiment, this search projects facility uses the Domino domain search capability. A Domino domain can include many project servers 101, 127.
User authentication is required to search places 114, etc. By use of a Domino server multi server single sign on (msso) feature, once a user has been authenticated for access to any server 101 in a domain or service 100, it has valid or authenticated access to all servers 101, 127 in that domain—which means that the user authentication is valid when accessing the domain catalog server. (The terms “domain” and “service” both refer to a plurality of project servers.)
Two interfaces provide access to the search places feature. First is through a URL. The other is through an API. URL access is used in a QuickPlace search places user interface (UI) when search places is enabled on a user's QP server 280.
A search project url request includes search criteria, information about, and the ID of, the user requesting the information, and when executed will generate a search result. When the search places facility is used from each place 114, it redirects the search places UI provided by a special place on Domain Catalog server 280, which UI collects search criteria information from a user. Search requests collected at the search places UI is handled by the domain catalog server 280 (rather than the place server 101).
Referring to
There are two types of command lines: input commands 202 and output commands 204. Output commands 204 include report. Input commands 202 include lock, unlock, archive, remove, and sendmail. These and other input and output commands are described in more detail hereafter.
Data file 200 stores place data, and includes a place catalog. As is represented by lines 205 and 207, output command 204 is processed through user input 206 to define command 208. As is represented by lines 201 and 209, command processor 208 operates on data file 200 to generate an XML file 210. As is represented by lines 211 and 213, XML file 210 is fed to any of a plurality of servers 101, 123, 127 in a service. As is represented by line 203, input commands are also fed to servers 101, etc. in the service. As is represented by lines 223, 225, and 227, administration commands 222 perform data manipulation 224 to generate an XML file 226 and log 228. XML files 210 and 226 conform to the format set forth in Table 3.
Referring further to
QuickPlace server administrators can run the command line tool qptool from the server console, the program directory, or from a batch file or other program.
Administrators use the administration utilities in the QPTool application to complete a variety of tasks, including locking and unlocking places, changing user names, registering and unregistering places, generating reports, as will be more fully described hereafter.
The reports that are generated by qptool can be input for other qptool commands. For example, the administrator can generate a report of all the places over 100 Mh, and then feed that report to any command, e.g. archive. This tool will know which places to run archive on and create a log for the places on that server. This same report can be run on all the servers and the relevant subset of places will only get the command run on.
The qptool model is:
QPTool 244 produces XML output. QP Java API 246 can accept XML inputs. The above “API able” statement means that the XML produced by QPTool can in turn be passed to the Java API 246 as is.
The following scenario is an example of how administrators automate administration tasks:
To implement cross-charging, when a place is created, the creator is required to specify a cost center number, and the creator's name and the cost center are stored in custom fields in place catalog 120. A list of usage records is sent to a financial relational database (RDB) on a monthly schedule. Each usage record includes the name of the place to be charged for, the cost center, and the name of the creator of the place. If a place is not used in a given month, no usage record is submitted.
To implement expiration, the last-accessed date of each place is evaluated once per month, and expired places are archived then deleted from the host servers.
In this example, a QuickPlace system 101 is operated to run as follows, on a monthly schedule:
To implement the automated solution example described above, a number of mechanisms outside of place server 101 are required, including:
QuickPlace server administrators can run a command line tool called QPTool from a server 101 console, the program directory, or from a batch file or other program. Administrators use the administration utilities in the QPTool application to complete a variety of tasks, including locking and unlocking places, changing user names, registering and unregistering places, generating reports.
QPTool is a server task that is run with arguments to do administrative tasks. The QPTool command is used to complete the following tasks:
QPTool commands are designed to be used while the QuickPlace server is running. To run QPTool from a server console, the user enters:
load qptool [command] [arguments]
To run QPTool from the Domino program directory on the Windows NT platform, the user enters:
nqptool [command] [arguments]
To run QPTool from the Domino program directory on a UNIX platform, the user enters:
qptool [command] [arguments]
QPTool can also be run from a batch file or other program.
Place catalog 120 reflects changes that result from QPTool commands.
QuickPlace server administrators running QuickPlace for iSeries™ systems can also run QPTool commands from the OS/400@ command interface. The OS/400 command interface syntax is different from the Domino server console syntax.
When a QPTool command is run on a server in a cluster 318, QuickPlace applies the command immediately only to the server on which the command is run. The command is applied to other servers in the cluster after cluster replication next occurs to those servers. For example, if a place 320 on one server 314 in a cluster 318 is locked, the place 320 is locked immediately only on that server 314. After cluster replication replicates the place to other servers 316 in the cluster however, the place 322 is also locked on those servers.
The QPTool report command can gather information from all servers in a cluster. However, if the results of the report command are supplied as input to another qptool command, the other qptool command only acts immediately on the server from which the command is issued.
The QPTool changemember command is used to change the name of a local user 116, external user 115, or external group 117 in specified places. The original name is the source name and the name changed to is the target name.
Using changemember, the following administrative tasks may be done:
1) Local user name to local user name
2) Local user name to external user name
3) External user name to external user name
4) External group name to external group name
The following combinations of name changes may not be made:
1) External user name to local user name
2) External group name to local user name
3) External group name to external user name
4) Local user name to external group name
5) External user name to external group name
The syntax for the changemember command is:
Table 4A defines the arguments which may be used. When a name specified as an argument contains spaces, quotation marks are included (“ ”) around the name. dn means defined name.
Following are several examples of using the qptool changemember command.
The QPTool changehierarchy command is used to change the hierarchy in the names of external users 115 and groups 117 in places 114. For example, if the company name changes and the names of users and groups in an external directory are changed to reflect the change, the changehierarchy command is used to change the names in places. Or if a new group is created with a new hierarchy in an external directory to encompass what was previously two groups, the names of the original groups are changed in places to the name of the new group., The changehierarchy command does not operate on local users 116, 118. The syntax for the changehierarchy command is:
load qptool changehierarchy arguments
Table 5 describes the arguments that can be used with the command.
Following are two examples of using the changehierarchy command.
The QPTool password command is used to reset passwords (Table 3 lines 74, 76) for a local user 104. To change the password for an external user, the entry for the user is changed-in the external directory. The syntax for the password command is:
Table 6 describes the arguments for the command.
Following are examples of using the password command.
The QPTool removemember command is used to remove members 104 (Table 3 lines 58–61) from a place. The syntax for the removemember command is:
load Qptool removemember arguments
Table 7 describes the arguments to be used with the command.
Following are examples of using the removemember command.
The QPTool newsletter command is used to send daily and weekly newsletters to members 104 of places 114. Members of a place can receive daily newsletters if daily newsletters are enabled for the place, and can receive weekly newsletters if weekly newsletters are enabled. To receive a newsletter, a member subscribes to newsletters in a member information page 104 and must have a valid e-mail address. The syntax for the newsletter command is:
qptool newsletter arguments
Table 8 describes the arguments.
A QPTool sendmail command is used to broadcast an e-mail message to all managers or all members 104 of a place 114. The Send Mail command is useful for communicating administration issues to place managers. For example, a broadcast e-mail may be sent to the managers of places if the places have exceeded a predetermined size limit and will be archived. The syntax for the sendmail command is:
load qptool sendmail arguments
Table 9 describes the arguments available for the command.
Table 10 is a sample template file for use with the sendmail command.
The QPTool register command is used to do the following:
The QPTool unregister command is used to remove a place's document from place catalog 120. For example, if place catalog 120 is down for any period of time, all places 114 are unregistered and then the register command is used to register the places again so that place catalog 120 contains up-to-date place information. When the remove command is used to remove a place 114, the unregister command does not have to be used because the remove command automatically removes the place document.
The syntax for the register/unregister command is:
qptool register[unregister] arguments
Table 11 describes the arguments.
If port or protocol settings for the server are changed, “qptool unregister -server” is first run, and then “qptool register -server” to reset the information in place catalog 120.
Following are several examples of using the qptool register/unregister command.
After the creation of new places 114, rooms 113, and PlaceTypes 102, a QPTool replicamaker command is used to create replica stubs for the new places, rooms, and PlaceTypes on other servers in a cluster 318. After creation of the replica stubs, cluster replication or standard replication replicates the new places, rooms, and PlaceTypes to populate them initially and then keep them synchronized.
The replicamaker command does the following:
PlaceTypes replicate and the replicamaker command creates replica stubs for PlaceTypes 102 the same way it creates replica stubs for places 114. The syntax for the replicamaker command is:
load qptool replicamaker arguments
Table 12 describes the arguments used with the replicamaker command. XML input and output files are not used with this command.
Examples of using the replicamaker command are as follows.
Use either of the following commands:
Use either of the following commands:
The replicamaker command, when run in verbose mode, logs all activity and errors to the server console and helps identify any problems as they arise.
Turning on verbose logging for replicamaker on a server is done by:
Ensuring that replica stubs of new places 114, rooms 113 and PlaceTypes 102 are created quickly and that replication then populates the places, rooms, and PlaceTypes quickly, is done by:
The QPTool upgrade command is used to upgrade existing places 114 and PlaceTypes 102 from QuickPlace 2.0.6 or higher, to upgrade to achieve full QuickPlace Release 3.0 functionality. The syntax for the upgrade command is:
load qptool upgrade arguments
Table 13 describes the arguments used with the upgrade command.
Following are examples of use of the upgrade command.
The QPTool refresh command is used to refresh places 114 and PlaceTypes 102 on QuickPlace server 101. The syntax for the refresh command is:
load qptool refresh arguments
PlaceTypes can also be refresh using the PlaceTypes view in the administration place. Table 14 gives the arguments for the refresh command.
When the NOTES.INI file on a QuickPlace server 101 includes the setting ServerTasksAt4=qptool refresh -a all child places 114 (not PlaceTypes) are refreshed nightly at 4 AM.
Following are examples of use of the refresh command.
The QPTool lock/unlock command is used to take places 114 in and out of service 100 without stopping the server 101. The lock command is used to put places temporarily out of service 100 during maintenance operations and then the unlock command is used when the maintenance operations are complete. When a place 114 is locked, an end user trying to access that place receives a message that is specified by an administrator which explains that the place is temporarily out of service.
Other qptool commands lock places 114 specified in the command automatically before running and then unlock the places when the operations are complete. However, it may be desired to lock a place 114 before running multiple qptool commands to prevent users from accessing the place until the commands have finished running. For example, a place 114 may be locked while using the changemember command to change several member 104 names within the place to prevent members from accessing the place until all the name changes are complete. When a place 114 is locked, the only QPTool command that can be run on it is unlock.
The syntax for the lock/unlock command is:
Table 15 describes the arguments for the lock and unlock commands.
Several examples of use of the qptool lock/unlock command are as follows.
The QPTool archive command is used to copy places 114 to a specified directory. This archive command is used when:
load qptool archive arguments
Table 16 describes the arguments.
Examples of using the archive command are as follows.
If a place 114 is archived and then deleted from the QuickPlace server 101, the register command may be used to restore it.
For example, if the archive and remove commands were executed to archive a place and then to remove it from the data directory, as follows:
1. >load qptool archive -p placename -dir d:\archivedir
2. >load qptool remove -p placename -now
the archived place could later be restored so that users can access it again from a browser, by doing the following:
1. Copy d:\archivedir\placename back to the program\data\QuickPlace directory.
2. Specify this QPTool command:
The QPTool remove command is used to remove places 114 or PlaceTypes 102 from the QuickPlace server 101, such as a place or PlaceType that is no longer used or that hasn't been used for a long time. The syntax for the remove command is: load qptool remove arguments
Table 17 describes the arguments for the command.
When using search places 114 on server 101, the -now argument is not used to remove places. Instead the remove command without the -now argument is used and the places 114 marked for removal. After marking the places for removal, Catalog and Domidx tasks are run on the domain catalog server 280. After the Domidx task has completed, the remove command is used with the -cleanup argument to remove the places. This removal procedure is followed to ensure that information in documents from the deleted places is also removed from the search index.
Following are several examples of using the remove command.
The QPTool placecatalog command is used to update statistics in place catalog 120, and is used for two purposes: (1) to update PlaceLastModified and the PlaceSize statistics, and (2) to synchronize statistics in place 320 documents between a master server 312 and the other servers 314, 316 in a cluster.
Generally when a statistic for a place changes the place document in database 129 in place catalog 120 is automatically updated to reflect the change. This automatic update occurs immediately, or in the case of the PlaceLastAccessed statistic, within a minute of the change.
Changes to the PlaceLastModified or the PlaceSize statistic are not updated in place catalog 120 automatically however. To update these statistics in place catalog 120 the placecatalog command is used with the -push argument on the place server 101. By default the NOTES.INI file on a QuickPlace server 101 includes the following setting so that this command runs nightly at 3 AM to update place catalog 120 with these two statistics for all places.
ServerTasksAt3=qptool placecatalog -push -a
This command is run manually, for example, before using the report command so that up-to-date statistics are reported.
Within a cluster 318, a place's place document for the master server 312 might contain different statistics than place documents for the other servers 314, 316. The placecatalog command is used with the -update argument on place catalog server 280 to synchronize a place's statistics across all place documents. The placecatalog -update is used, for example, before using the report command in a cluster environment to ensure that the report contains up-to-date statistics.
The syntax for the placecatalog command is:
Table 18 describes the arguments.
The QPTool report command is used to pull information from place catalog 120 to generate reports about places 114 in QuickPlace service 100 and about servers 119 that use the service. The report command is used to retrieve the following information from place catalog 120 database 129 about places 114:
Name
Title
Server name
Size
Date last accessed
Date last modified
Locked state
Although place catalog 120 lists the Readers, Authors, and Managers (Table 3 line 53) of places, the report command is not used to generate this information in a report. The report command is used to retrieve the following information from place catalog 120 about servers that use the QuickPlace service 100:
Name
Access Protocol
Access TCP Port
Access URL Prefix
If more than one server 101 shares place catalog 120, a report specifies data for all servers 119 in service 100.
Before using the report command, the following is done:
The syntax for the report command is:
Table 19 describes the arguments for this command.
Following are several examples of using the report command.
Repairing broken places 139 on server 101 is done by running the QPTool repair command. The repair command fixes very specific problems that are described below.
The repair command is intended to get QuickPlace up and running as soon as possible, but it does not necessarily fix the source of the problem; rather, it re-normalizes data that is no longer synchronized. That is, until the source of the problem is addressed, or until QuickPlace source code is fixed, the repair command will work as a temporary solution.
The syntax for the repair command is:
The QPTool deadmail command is used to clean up QuickPlace dead mail.
The syntax for the deadmail command is:
Table 21 describes the arguments.
By default the NOTES.INI file on a QuickPlace server includes the setting ServerTasksAt3=qptool deadmail -cleanup so that the QuickPlace server cleans up dead mail nightly at 3 AM.
The QPTool execute command is used to execute an XML API file 70. The syntax for the execute command is:
The administrator of a QuickPlace server, for example, is provided with an improved system and method for:
It will be appreciated that, although specific embodiments of the invention have been described herein for purposes of illustration, various modifications may be made without departing from the spirit and scope of the invention. In particular, it is within the scope of the invention to provide a computer program product or program element, or a program storage or memory device such as a solid or fluid transmission medium, magnetic or optical wire, tape or disc, or the like, for storing signals readable by a machine, for controlling the operation of a computer according to the method of the invention and/or to structure its components in accordance with the system of the invention.
Further, each step of the method may be executed on any general computer, such as IBM Systems designated as zSeries, iSeries, xSeries, and pSeries, or the like and pursuant to one or more, or a part of one or more, program elements, modules or objects generated from any programming language, such as C++, Java, Pl/1, Fortran or the like. And still further, each said step, or a file or object or the like implementing each said step, may be executed by special purpose hardware or a circuit module designed for that purpose.
Accordingly, the scope of protection of this invention is limited only by the following claims and their equivalents.
| Number | Name | Date | Kind |
|---|---|---|---|
| 20020152234 | Estrada et al. | Oct 2002 | A1 |
| 20020156929 | Hekmatpour | Oct 2002 | A1 |
| 20020194200 | Flank et al. | Dec 2002 | A1 |
| Number | Date | Country | |
|---|---|---|---|
| 20040143599 A1 | Jul 2004 | US |
