|
|  |
| get started |
|
| |
| |
|
|
|
Open the Enterprise Context Design console [oberon.bat (.sh)] and define the administrative objects
|
|
 |
|
There are 4 basic questions to consider when you create a new application:
a) What are the basic object types, their properties and their interconnections?
after identifying these aspects of the application domain you can easily map them inside OBEROn:
- class : is a business object type, can be abstract or instantiable, can be organized in a hierarchy where sub-classes inherit properties of parent classes
- linktype : is a type of connection between two classes of objects
- field : represents an object or link property , it is characterized by a data type (text , number, date ... ) and sometimes it is associated to a unit measure
b) Who performs the operations or manipulates the object instances?
there are three levels of authorizations for accessing the object manipulation:
- user : is a simple identity, it is used as account for application login
- team : is a group of users belonging to the same organization, department or sector
- assignment : it represents a specific role and it is generally associated to a restricted set of actions
c) How to allow users to access the object data or to perform action on them?
application policies are described inside OBEROn by:
- lifecycle : specifies the rules that govern user access, state transitions, revision rules, type of attachments, allowed documents and so on
- workflow : is a depiction of a sequence of operations (steps), declared as work of a person or group
- program : provides a way to customize the application behavior by implementing business rules (perform checks and actions when the events occur)
d) Where to store the object instances and the attached documents?
data, metadata and files are organized into:
- objectspace : it is used to collect business object instances with similar characteristics within the OBEROn database
- filespace : is a storage location for application files, defines a physical place where files attached to objects are stored
- localarea : is a replication of a filespace or of a part of it, used to increase file transfer performances during the user active work |
| |
| |
|
|
 |
Open the Domain Object Manipulation console [oberon.bat (.sh)] for creating object instances and testing the processes and the access rules |
|
Here is a list of tests you may perform to check the validity of your application schema:
- create and manage object instances : create new object instances or new object revisions, modify, clone destroy objects
- make connections between objects : create links, edit the link properties, clone or remove links
- work with object's attached files : attach documents to object instances, retrieve, rename or remove attached files; synchronize files among the filespace and the remote localareas
- change the object status : move an object from its current stage toward the next stage of the associated lifecycle, regress the status to the previous stage; validate signatures for moving the object state along the lifecycle branches
- check and execute workflow pending activities : list the pending activities for the logged user and test the correctness of workflows after their completion
- alter the object access: activate/remove the object lock, delegate other users to perform some specific actions
- perform checks and actions when events occur : verify that all trigger-programs work fine
|
| |
| |
|
|
|
OBEROn discerns the user interface into two levels:
-
the rough (low) level; it is a common interface and it doesn't depends on the final user presentation
-
the detailed (high) level; it is strictly related to the visualization media and it is based on the transformation of the generic level made by a rendering engine |
 |
 |
Basic elements of the generic interface are:
- menu : defines the list of actions that each user can execute after the login; the root of menu tree is the application or the portfolio (a set of application modules)
- command : is a terminal node of the menu tree and represents an actual menu action (opens a page/panel, runs a program etc. )
- form : is a structured set of input fields; it allows a user to enter data that is sent to the server for updating the object instance properties or the link instance properties. They can be also used for displaying or printing information, for composing the body of a mail message and for applying query filters.
- view : it defines a set of columns in a specific order used to show or edit properties for multiple objects in a tabular format. |
 |
Multi-language management
OBEROn reduces the complexity of multi-language management and lets you to focus on the application content. It provides an internal translation dictionary able to manage all label translations. The Dictionary Check process extracts all potential labels from the the schema and verifies that they are correctly mapped inside the dictionary; otherwise you can decide to add them automatically in such way that you need only to edit the translations for the different languages.
|
| |
| |
|
 |
The OBEROn platform provides transformation tools for deploying the generic user interface to the main application contexts. These rendering engines are open source and fully customizable. You can release your application in a very fast way because they cover about the 70% of standard functionalities ( user access control , object search , edit the object and link properties , object connections, object lifecycle management, workflow activities, document and file management , charts generation, etc. ). Tha same application can be released as: |
Desktop applications
The rendering engine is a set of java classes and the user interface is implemented with Eclipse SWT widgets. The SWT widget library is available for Windows, Linux, Solaris 10, HP-UX, AIX ,Mac OSx, so, the generated java code is portable and compatible with all these platforms.
Connections between the desktop clients and the OBEROn database can be set up in 3 different ways: directly through jdbc drivers, with client-server architecture through a java RMI server or through an Http server. |
|
Web applications
The rendering engine is a set of JSPs (java server pages) and the user interface is implemented with HTML form controls, javascript/AJAX code and the displaytag library for views.
Under deployment is also the Vaadin integration for more fascinating graphical look.
Web applications require a java Application server (such as Tomcat or Weblogic). |
|
RAP / web-applications
The rendering engine is a set of java classes running on the server side and the user interface is implemented with Eclipse Remote Access Platform. The RAP tools allow to re-use the SWT classes implemented for desktop clients with a minimal effort. RAP lets you develop modern web UIs with a real widget toolkit with SWT API, which includes powerful features like drag & drop, loading data on demand, inline editing, and drawing.
RAP runs in all relevant web browsers, without any add-ons required; it uses standard servlet technology and runs on any JEE servlet container (such as Tomcat or Weblogic). It integrates well with OSGi, but can also be used stand-alone.
|
|
Mobile applications
The rendering engine is a set of java classes and the user interface is implemented with Android widgets. The Android platform for mobile devices is nowadays the most diffused mobile system in the world and it is available for millions of smartphones, tablets and PCs.
Like web applications, the connections between the mobile application and the OBEROn database is possible through a java Application server with a minimal configuration.
|
 |
|
|
