This presentation covers the most important concepts for application development of the new Financials.

Most of the concepts are important to fully understand the application’s built-in, non-intrusive Customization capabilities.

Encapsulation of services. Each layer offers a number of clearly defined services. These services have interfaces that describe how the services can be used.

Responsibility on each of the layers:

The fact that an application is layered allows components evolve to other technologies much easier and independent than in a non-layered application. We know that the UI technology is moving in a much faster than the technology used for the business logic. This is why it is very important to have the separation in layers and for the access to the services in the layers to always go through predefined interfaces.

Besides having services in separate layers with clear interfaces, it is important that the application functions follow a limited number of application patterns. This enables easier Customization and extensions of standard functionality on a later stage.

Business components offer us the possibility to provide a level of abstraction in the business application. This enables us to develop the application based on infrastructure code that supports some standard application patterns out of the box. Through this type of generic code, the application gets some typical characteristics as stability, easier maintenance of overall functionality, non intrusive customizability, etc… It also ensures that application services can be developed within the context of components.

Two mechanisms are mostly used to obtain the required level of abstraction. Through encapsulation, specific implementations and data are hidden from the callers. This simplifies the design of functionality. Inheritance gives us the possibility to bring generalized interfaces to the application infrastructure. It ensures more reuse of code in a natural way.

The business components consist of methods, queries and data items. All of these have a scope level. This way functionality and data can be hidden away for other components or applications.

All business services are available on a central host in the system. These services are available through from a client through the network layer. In order to use the central business service, it is typically necessary to know:

Proxies allow you to centrally develop a business service in a certain technology, and yet expose the interface for the business service in the correct technology (C#, Progress, XML, Java, …). If you generate the proxies, and the way of connecting to the central business service layer is generic, the complexity of the connection can be hidden for the client.

 

Patterns are crucial to new type of layered, component-based applications. The patterns drive the requirements for the generic coding in the infrastructure and give the guidelines for the design of the specific application components or classes.

Patterns also ensure more consistency in the program code for the application, which ensures easier maintenance, because program code written by other developers is easier to understand.

The defined patterns in the application infrastructure determine a developer’s ability to implement standard functions in the application.

The typical properties of a business field are:

Typically, the client UI uses business field information to show the business information on the screen.

The business field information is language-independent. The current UI is written in C#.NET, but any other UI might use the business field information to format the screens.

The business activities are defined on a higher level than the methods and the queries on components. Typically, the activities are exposed directly to end users. This is not the case for normal methods (even if they are public).

A business activity typically represents a certain program flow, mostly implementing one of the high-level application patterns (like “Journal Entry Create”)

The list of business activities can be retrieved in a generic way for each component. The generic infrastructure code uses the business activity code to verify access for the user/consumer of the service against the role-based security in the application.

 

It is important to have a uniform way to pass object data between layers. As soon a business component is instantiated, and an object from the database is “loaded”, all relevant information is stored in the object dataset. The object dataset is the only way of passing the object state / information between the different layers.

Besides being used as transportation vehicle, the dataset also lends its structure to external parties wanting to integrate with the business application. For example, when the business application exposes objects through configured events, the data that is published has always the same format, which is defined by the XML schema of the object dataset for the specific component. Also, when data is loaded, the business application backend requires the data to be in the official object dataset format.

By having the proper documentation in place for the object dataset, the application business layer is much better documented.

In a component-based application, the principle of “instantiation” must be very clear. Each consumer of a business service needs to instantiate a business component before being able to call a method on the business component. The consumer can be internal in the business layer, or it can be an external client (like the UI).

The instantiation process ensures that for the component, the necessary properties (data items) are initialized or loaded, so that the logic in the methods can be executed properly.

Every component instance is identified by its instance ID. This is a number generated at the moment of initial instantiation, and which can be used to identify the instance every time a consumer wants to communicate with the instance again.

Typical example: The UI to create a supplier invoice will first need to start an instance for supplier invoice, before being able to send data to it, validate it, and save it.

 

Physical transactions are de facto linked to one process, and require a statefull application model, because the logic within one function must be guaranteed to be executed by the same process. If you work with a multi-layer model, in which the business logic is used in a stateless way, the logical transaction is used to logically link different updates in business components. The logical transaction is living on the level of the database and is available every time the client uses a different process on the server.

Every time a component instance is created, the instance must know if it is “standalone” or it takes part in a bigger transaction.

If instance is “standalone”, the logic itself is responsible for initiating and committing the transaction at the correct time. If the instance is part of a bigger transaction, it is assumed that the consumer (client) initiates the transaction and also decides when to commit the transaction.

Typical example: The creation of a supplier invoice is started from the UI screen, but includes besides the supplier invoice a Financials posting. Both the instance for the supplier invoice and for the posting belong to the same logical transaction.

A session component is instantiated at the moment a user logs on to the system. The instance stays available throughout the user session until the user logs off or until a time-out occurs. As long as the session stays active, some data (specific for the user or specific to the context in which the user is working) stays available as properties of the session instance.

A session instance is only valid if the user is authenticated and granted access to the application.

Because a valid session is required for all business logic execution, external consumers must provide the required authentication information in order to execute business functions.