Administrator Manual
From Empweb
Contents[hide] |
Empweb Administrator Manual
Administration tasks can be accessed through the "Administration" tab in the top menu.
This section explains:
- Empweb status
- Empweb database operations.
- Operators.
- Calendars.
- Transaction pipelines, rules and processes.
- Policies and Profiles.
Empweb Status
Through this tab, transactions can be disabled.
This is useful if the system needs maintenance, for example, to change the user or object database contents and prevent transactions during the process, without bringing the whole system down.
By disabling the transactions, the GUI keeps working but users get a clear error message when trying to perform a transaction, that they can retry later.
Empweb database operations
This tab allows the following operations in the database:
* Perform a manual database dumps. * Initialize the transaction database contents, deleting everything but performing a backup before.
The backups are stored in the directory specified in the engine/WEB-INF/conf/engineconf.xml configuration file. This directory must exist, or it will not be possible to initialize the databases.
Operators
Operators can be managed through this tab.
The special operator "admin" has full access to the operator tabs. He can modify other users, and also grant permission to administer. This special cannot be removed.
Allow connections from Operator access can be restricted to a certain IP or list of IP addresses. A list of IPs can be entered, separating the values with comma. The wildcard * is valid.
For example, the following IP address list is valid: 192.168.0.*,127.0.0.0
Libraries list Operator accecss can be restricted to one or more Libraries. This allows, for example, that a certain operator can perform tasks in one or more libraries, but the others are invisible to him.
Group List The group list, when editing an operator, shows which sections of the Empweb GUI are accessible by him. For example, to grant suspension cancellation priviledges, the trans-suspension-cancel group must be checked.
Default Databases Different operators can have different default user and object databases selected. This will avoid the operator to select the database each time he performs a transaction.
Calendars
A calendar is used to indicate which days count and which do not count when calculating the duration of a loan or a suspension.
Days marked as "skip days" are not counted by the transaction rules (unless the rules are configured to ignore skip days).
If a calendar has not been created for the working year, the system uses a default calendar with no skip days. This means that even saturday and sunday are counted when processing a loan or counting the suspension days.
Policies and Profiles
A policy is a set of profiles.
A profile is a relationship between a category (type of User) and a class (type of Object). i.e.: a category may be "Professor" and a class may be "Technical magazine". Therefore, a profile could be comprised of the "Professor,Techincal magazine" pair. Having these profiles (category-class pairs) allows you to customize Empweb's behavior when some transaction involves the profiled user's category and object's class. Following with the Professor-Tech Magazine example, you may want to allow professors to borrow any technical magazine for a month, instead of the regular one week loan time applied to students. This kind of situation is when profiles come in handy.
As mentioned before, a policy is nothing but a set of profiles. By creating several policies, you can have different sets of profiles that can be applied during particular circumstances or periods of the year. For instance, you may want to define a "Spring Break" policy, which may allow all students to borrow up to five books for one month. Of course you would also define a "Regular" policy, which establishes the usual limits for transactions.
This would allow you to easily change the active profiles from "Regular" to "Spring Break" when the time comes, just by activating the "Spring Break" policy. Once spring break is over, you could switch back to the regular limits by merely activating the "Regular" policy.
Obviously, there can only be ONE active policy at a time, but you can have any number of defined policies to choose from.
Creating a new Policy
Once you've clicked on the "Policies" tab, a list of currently defined policies will be displayed. If there aren't any policies defined yet, the list will show empty.
In order to create a new policy, just click on the "Create new policy" link. You will be prompted to enter a name for the new policy as well as a confirmation for the creation of this policy.
As an example, let's create the policy named "My first policy". After entering "My first policy" as the new policy's name and confirming its creation, a "Succesful Request" message will be displayed. Next, we click on the "Back to Policies" link to go back. This recently created policy should now appear listed under "List of Policies" .
Note that once a policy has been created, new actions can be performed on it; namely you can "Activate", "Edit", "Copy" or "Delete" each listed policy.
The next logical step once the policy has been created, is to define the profiles it is made up of. In order to do that, click on the "Edit" link next to the "My first policy" policy. The Edit Policy screen shows up, along with Policy Details information and the Profiles List.
Since the policy we just created is brand new, the set of profiles that define it is empty. We must proceed then, to create all the profiles that make up this policy.
Creating a new Profile
Clicking on the Create new profile link under Actions brings up the New profile form, where you will be prompted to enter the user class and object category that defines this particular profile (remember that a profile is a Object Class - User Category pair.)
Let us recall the Professor-Tech Magazine example once again. In order to reflect that example on this new profile we're creating, all we need to do is specify the New profile user class as "Professor" and the New profile object category as "Technical Magazine". After the creation of this new profiled has been confirmed, a "Succesful request" message should be displayed. Click on Back to Policy My first policy to go back.
You can create as many profiles as you need by repeating the previous step several times.
Note: This previous example assumes the Users and Objects databases contain some users and objects whose category and class have been defined as "Professor" and "Technical Magazine" respectively. Always remember Empweb isn't able to modify the Users and Objects databases, so the names used here derive from the fields used in the databases.
Note that you can easily delete any profile just by clicking on the respective Delete link.
We have created a new policy. We have also created the profiles that make up that policy. All that's left is setting the limits associated with each profile. (Remember the one month period we wanted to allow professors to borrow magazines? Well, that would be a limit we should set in the Professor-Tech.Magazine profile created.)
Editing a Profile
By clicking on the Edit link next to any given profile in the Profiles List, you can customize the limit values for the selected profile. The Edit Profile form allows you to change the User Class, Object Category and all the limits associated.
Transaction pipelines, rules and processes
Pipelines are the most important feature of Empweb.
A pipeline is a sequence of rules and processes that, executed in order, perform a desired action. A rule or process is a small program that performs some action.
The easiest to understand are Transaction Pipelines. These are used to perform the typical transactions carried out in a library, as loans, returns, reservations, etc. Pipelines are also used for other kinds of processing as well. Configuration Pipelines are used for setting up the environment parameters. Statistics Pipelines are used to process transaction information and obtain library status and listings.
To lend a book from the GUI, a operator has to enter the user id and the object id, and then process the transaction. Behind the scenes, the GUI perfomrs a request to the engine web service. The engine gathers all the information from the databases and then runs the rules and process in the loan transaction pipeline, returning a success or failure and additional info for the GUI to display to the operator.
The power of Empweb resides in that the administrator can add new rules to the pipeline. By writing customized code the system can do almost any kind of processing or run all kinds of checks.
For example, a rule could check if the user is up to day with the university payments by going out and checking his status on another system, through a web service.
A very useful rule has been included with Empweb: a Groovy interpreter. Groovy is a scripting language that works very well with Java. So creating new rules is very simple. You can tell when a rule is written in Groovy by the (Script) word in the Type column. This will be explained in depth in the Programmer Manual.
Loan Pipeline
Let's now examine the Loan transaction pipeline. By choosing edit, we see some basic information about the pipeline and the process/rules sequence. Rules and processes are executed in sequence, starting from the top, so the order is very important.
At the begining of the sequence we can find some rules used to obtain the information required to perform the transaction. For example the GetUser rule obtains the user information form the user database, using the user id and database provided to the pipeline by the GUI.
The ExtractUserClass rule obains the user classs to be used along with the object category to obtain the profile to use for this transaction (as explained in the previous section, a profile es a set of limits assigned to a combination of user class and object category).
Once all information has been gathered, the checks start. There are some basic checks, such as if the user has not expired (validUser), or if the object is already lent (objectAlreadyLent), etc.
But how does the information from the ExtractUserClass reach the other rules so they can test them? Each transaction has what is called a Transaction Context where the rules can put and grab information to be shared with each other (it is a hash map).
If we edit the objectAlreadyLent we see 4 sections:
- Process Information: where the basic info about the rule is shown, including the name and the java class, in this case the Groovy interpreter.
- Process Documentation: where an explanation of the rule is given.
- Process Limits: this tells which limits are used by the rule, so they will automatically show up when editing the profile.
- Process Parameters: Where other parameters can be passed to the rule, and in case of the Groovy interpreter, where the script is provided.
Let's take a look at the script for objectAlreadyLent:
objectStatus = tc.get('objectStatus');
copyId = tc.get('copyId');
loansList = objectStatus.getLoans();
for (loan in loansList)
{ if (loan.getCopyId() == copyId)
{ msg.addText('es', '¡Este objeto ya está prestado al usuario '+loan.getUserId()+'!');
return false;
}
}
return true;
In the first two lines we obtain the object status and the id of the copy we are trying to lend from the transaction context (tc). Then we extract the list of loans for that object. Then we check each loan to see if the copy is already lent, in which case we add an error message (this time in spanish), and then we return false, which stops processing the pipeline and returns an error to the GUI. If the copy is not aready lent, we return true and proceed with the following rule.
Let's go back to the pipeline, so click over the pipeline name (loan) or press back in the browser.
The last part of the pipeline sequence is in charge of storing the transaction. If one of the checks failed, we will never get this far, so we can be sure that if we're here, everything is ok. AddLoanToStatus actually puts the loan into the user status and object status, that is later commited to the database by the UpdateDB rule.
![[Main Page]](./administrator_manual_files/logo_kalio_solo_50x50_transp.png){kind=logo}