This section describes functional modules which group functions. More about them in a less technical manner and more about the functionality itself of the functional modules can be found in the modules section.
This section is NOT about logical modules which group entities, more about those can be found in the entities section
The system is written using a highly modular architecture, as much functionality as possible is implemented in independent and loosely coupled modules. The reason for that is, that any given functionality should be not only easily configurable, but for very specific and custom needs, easily replaced with the help of a new module. This approach helps due to how line of business apps tends to need custom functionalities per organization, as each organization has it's own specific needs.
We can divide the systom in following two main parts:
let's take a close look at those parts
The backend is composed of following components
So we could sum it up, that the kernel is responsible for security, server modules and configuration
The frontend, having a similar architecture to the backend, is composed of following components:
For the same reason why we decided to make the system as modular as possible, the system is as configurable as possible.
As mentioned above, line of business systems vary from organization to organization because of the specifics of each organization. It's not possible to create a line of business application that would comform even a big part of organizations.
That is why the a7 EBusiness platform focuses heavily on configurability making it easily customizable without the need to code a single line of code. Obviously, not everything is possible to be made based purely on configuration, that's why for edge cases, we can always develop simple modules which will expose any imaginable functionality for the organization.
However, without the need for writing any new module we can:
Because ebusiness systems usually contain a big amount of data, searching through that data is crucial. Even when the data is optimally distributed between several boxes, at some point at least some boxes will contain a huge amount of data.
The easiest way is the quick search, by simply typing in a single field, the systems searches for the best matches.
When the user wan't to filter data based on a certain set of fields, the column filter is the fastest way to decrease the amount of displayed records.
The most advanced is well.. the advanced filter which allows to build sophisticated filter with a few clicks. The created filters can be as complex as normally they would be created for example in SQL by data engineers.
For example, the below screenshot show a filter, for activities of which Jennifer Mouser, or the Support Team is the owner of, and which are high priority and are regarding the Mennick company.
Additionally, we can configure custom quick filters for entities for which we need a functionality to quickly filter data based on fields specific for the entity, like below for activities based on time, owner and status of the activity
Associations between objects are in the system at least as important as the data in the objects itself.
They allow to have a deeper undestanding about the contained data, like for example the associations between a phone call, a task, a project and a client.
Associations are defined by configuration in the system, following association types are available:
In the user interface the associations are mostly visualized by:
Embedded lists in data forms
The relation bar
The relation tree
In the a7 EBusiness Platform we have the concept of summary entities which doesn't have any data on itself, but are used to display aggregation of data from other entities.
Aggregations allows to group data based on dictionary fields (like offer, category, is cancelled etc.) and datetime fields (like sales time, created on etc.), then in such grouped data we can make various calculations on numeric fields (price, sum, count etc.) like calculating the sum, mean, max, min etc. for grouped rows.
Let's for example take a look at a sample set of sales records, where every row is a single ticket sale, with pretty standard fields like offer, unit price, tax etc.
Based on those sales records, we can create a summary entity called sales summary which will allow us, to aggregate the sales data.
We can prepare preconfigured boxes for summary entities, which group the records based on predefined fields, like we can see on below screenshot on the left, there are boxes that group the sales records on the sales date, daily, monthly and yearly.
A not preconfigured box for a summary entitiy, display initially one row, which groups all the records into one group, and display the sum of all numeric records.
At the bottom of the table we can see a summary which summs all the fields in the table.
On summary entities we can apply column and advanced filter to display the aggregated data from a filtered out set of records. More about filters. For example if we wan't to display the sales summary of not cancelled sales records, we can apply a column filter:
As mentioned, we can apply any filter described in the searching paragraph. To see the numbers of the data which we need.
For summary entities we have an additional UI element, which allows us to set up the aggregation. The summary settings allows to select what calculation should be performed for numeric fields, and on which fields we want to group the data.
We can see bellow, that the aggregation settings display all fields, and have different settings for groupable fields, datetime fields and numeric fields.
Above settings together with the filtering options are a powerfull tool to generate various data aggregations and calculations for analysis. The resulting data set can be then saved using my boxes or exported to MS Excel
A example summary, let's say we wan't look at the sales between January 1st 2013 and March 30th 2013, of not cancelled tickets, grouped by device type and month of the sales time. That's how such summary looks like:
To see more details of a row, we can look up the row details by selecting a row:
All the functionality, which fields are visible, which can be grouped, which calculated, what is in the row details visible (which are available after a row is selected), what in the summary at the bottom - basically everything is build based on configuration, the framework takes care of the proper data loading from the database and calculations, no code is needed for any data source.
Most of the workspaces give the user the possibility to customize the view of the workspace accordingly to his preferences.
For example he can turn on or off the object preview
Display objects in another view than the standard table view, like for example the cards
or in a calendar if the objects uses the calendar module
Basic rules regarding security in the a7 EBusiness System
The permission set is defined by the concept of a mask which defines what permissions the role owner has.
There are three types of masks:
The entity and relation masks are a group of permissions either for whole entities, or for entities in context of a relation.
Each permission definition is based on two properties:
We have following permission types available in the system for entity and relation masks:
And we have following permission scopes available to configure the security in the system:
If a user/group/team has several roles with mixed scopes, the scopes are summed.
For example if in one role the user can only access documents that were explicitly made available for him, but in another role he has access to all documents of the category "Specsheets", he will see all documents with "Specsheets" category, as well documents that were explicitly made available for him, even if those are of different category.
The entity mask is defining the scope for each type of permissions for a given entity.
Let show a sample entity mask with following permissions:
The entity mask definition would look like this:
And below we can see the defined filters for types with the scope filtered, as we can see the advanced filter control is used, with which it's easy to build sophisticated filtering rules.
Sample of a more sophisticated entity mask:
The relation mask is a specific variation of the entity mask, additionally to the permission scopes and types available in the entity masks, it definition is based on a given relation for which the mask is used.
Each relation between two objects is defined in the system and has it's own id, e.g. the folder-document relation, or the company-contact person relation.
So relation masks are used to determine permissions to objects in context of the defined relation.
A example of a defined relation mask with following permissions:
And that are the filters used for the permissions with scope "filtered":
The system has also the logic for a more granular security management, by managing the permissions not only to entities, objects and relations, but also to single fields.
In contract to the object level of permissions, where we must explicitly set the access, in case of fields, it's the other way around - by default, if the user has access permission to a entity, he will have access permission to all the fields of the entity, and if the user has edit permission to a entity, he will have write permissoins to all the fields of that entity.
However, with the help of the field masks, we can explicitly deny access and or write permissions to a given field.
If the user has a role which denies access to a field, he will not see and/or will not be able to edit the value of that field.
Permissions to a record can be managed in following dialog:
If a user doesn't have the "publish" permission for this object, this dialog will be read-only for him, so that he can see, for whom there were granted permissions.
If the user has the "publish" permission, with this dialog he can make the object available for selected users/groups/teams.
The job server service is designed to perform in the background time consuming tasks during set up intervals.
It can be things like email synchronization, thumbnail generation of documents, converting documents to PDF format, and many more.
The job server is just as the whole system based on modules and configuration. Tasks that are performed by the job server are implemented in independent modules, basically the tasks are server module functions (SMF) implemented in server modules (SModules), more about modules in the modularity section.
Which server module functions should be performed by which job server, and in what time intervals, can be freely configured without any code changes.
On the right we can see the job server monitor, a seperate application which displays information about the running tasks. The functions implemented in the modules can also define what should be displayed by the job server monitor.