Creating attribute types
Object class definitions within the application consist of an unique name and a set of attributes. Each ettribute has its own value type like STRING, INTEGER or TIMESTAMP. Assigning these atomic values types directly would strip down the possibility to have a differentiated handling per attribute. Take an object class person having attributes firstname and lastname both of type STRING for example. When an user approves the order of an instance of type person the application could not handle the values of firstname and lastname in different ways but as every STRING in the context. The reason is that attribute names are just free text values having no impact on the processing.
In order to remove that limitation, mshop introduces own attribute types where each type is assigned a concrete value type like STRING or INTEGER. Take the example above. We would create an attribute type FIRSTNAME of value type STRING and maybe a type BIRTHDAY of value type TIMESTAMP. This gives the user the option to modify the handling of approved instances according the attribute types, eg combining the values of types FIRSTNAME and LASTNAME to a value givenName that is provided to a ldap server.
Creating object class orders
The driving force behind mshop are user defined object classes which serve as blueprints for concrete object instances (eg. class com.mnxfst.blog.Person is the defining type for instance Christian Kreutzfeldt). Therefore you need to define classes before your users are able to order instances of those types.
Creating an object class requires you to provide some more detailed information and must be carried out with a certain amount of care since it is the foundation of the later running system.
The definition dialog has three different tabs. The first tab lets you provide common information about the class like its name, if it is an abstract class, the activation date or the set of attributes.
The second tab lets you specify detailed information on how certain object class instances will behave in the approval workflow. You can define for each configuration (attribute value setting) the required audit level (how many people must approve the order) and what kind of operations are allowed for specific value settings.
The attached screenshot shows a configuration where object instances of the ordered type which are referencing the city of Hamburg and the specific street Kehrwieder need to be approved by two people for the operations create, update and delete.
These settings alone do not configure the concrete workflow path afterwards but represent the building bricks for it. In case an user orders an instance of type Person the application checks the attribute value settings and matches them against the associated workflow configuration in order to look up the required audit level.
The third tab finally lets you define approvers for ordered object class instances. Compared to the second tab, this one behaves nearly the same but adds another field: priority level. The audit level defines on which approval level the named user is provided with an workflow item for a specific order. The priority level gives you the opportunity to define proxy rules in case a named approver does not answer within a defined timespan.
Approving object class order
After having fully specified an object class, it needs to be approved by at least one object class approver. The object class approver opens the dialog displayed below and chooses to view all open/unanswered object class orders. In order to have the chance to validate the object class configuration he is allowed to browse through all the settings the originator made. The handling and behavior is quite straight forward and needs only little description.
Order object class instance
In case an object class has been approved its available to all users which are allowed to order instances of that type. The screenshot down below shows a set of classes the user can choose from.
The next step shows a set of available parent classes the user can choose from to define a hierarchy.
The third step lets the user specify values for the assigned attributes. The last step finally sends the object class instance order into the workflow process.
Approve order object class instance
The final view I would like to present today is the dialog for approving object class instance orders. Each approver is presented a list of all orders that he is allowed to approve / reject. By selecting a single workflow item he is able to see all required order details like common information (audit level, priority level, object class name and alike) and the attribute value settings.
Actually most of the dialogs do not look very fancy and colorful but I will try to improve on that until the first release of the application.
