+++ Mark your diaries – release planned for mid-2007! +++
This is part 2 in a 3-part series. If you missed part 1, see SAP BR*Tools Studio for Oracle: Features.
When we developed the first sketches of BR*Tools Studio, we quickly realized that it wouldn’t work to tightly link the graphical interface with BR*Tools (as in BRGUI). We decided that we needed a more modular approach to implement the reconnect function and browser-supported navigation, allowing users to jump directly to different tool areas.
The solution is a client-server architecture in which BR*Tools users no longer directly control jobs, but instead create job packages on the client and pass these packages over to the server for independent execution. Adding a favorite tasks feature and putting all items in a role-based, user-specific context is a natural consequence of this architecture. The BR*Tools Studio engine executes and keeps track of these items.
Part 2: The Engine
BR*Tools Studio is divided into two large parts, the BR*Tools Studio Wizard which represents the interface to BR*Tools, and the BR*Tools Studio Administration which covers the entire maintenance of the Studio itself. Two major tabs provide access to the parts.
You can see the individual elements of the BR*Tools Studio Engine on the overview page of BR*Tools Studio Administration:
Each user in BR*Tools Studio has their own password-protected account with a user profile. The user profile contains details of the default database user and initialization profile for BR*Tools. The user account also contains all jobs and favorite tasks created by the user.
Ordinary users can only view their own accounts, whereas users with special authorization can view and change the accounts of other users and also create new users. Users each have a role, specifying what functions they are allowed to perform.
You can use the role concept in BR*Tools Studio to grant or restrict access rights to tool areas for individual users. Each user receives a single role. To guarantee a highly flexible distribution of access rights, BR*Tools Studio offers these four different roles:
So you can easily and quickly run operations that you often need, you can save your own personal set of favorite tasks. Next time you need it, you can run a favorite task with a single click, without having to reenter all the parameters. But if you do need to change a parameter in a favorite task, you can do this easily too.
You choose the required BR*Tools operation from the menu and select the required parameters. When you release the operation, BR*Tools Studio server takes over the job, either for immediate or delayed execution.
With delayed execution you can specify a date and time in the future and, if required, a recurrence of anything from hourly to monthly. For example, you can specify weekly execution on Fridays, starting next Friday.
When BR*Tools Studio server recognizes that a job is ready for execution, it enters it in the job queue for execution as soon as possible.
A user logs on with a browser client to BR*Tools Studio server. The client is defined by the browser session. Users can log on with multiple browser sessions to BR*Tools Studio server. In this case you can see any changes you make in one client session in all other client sessions of your user.
The server is the engine room of BR*Tools Studio. It executes incoming jobs and administers all items. If the server is down, all jobs scheduled for the downtime period fail. No clients can connect or log on to BR*Tools Studio until the server is up again.
Now we’ve introduced you to BR*Tools Studio engine, in the final part of this series we’ll look at the main purpose of BR*Tools Studio, the graphical connection to BR*Tools with BR*Tools Studio Wizard: