4.7.2 SAP B1 Decoupling

In this document we are going to try to describe the process we made in order to OneDealer application operate without B1 Service layer.

SAP B1 Switch mechanism

We introduced a switch mechanism and we are able to configure if an OneDealer application has SAP B1 environment or not.

This is configured from database table field "HasSAPB1",  in the common database,  table "Company". The type of the field is tinyint and the expected values are the following

When the field has null or 1 value, then the OneDealer makes use of SAP B1 Service Layer and when the field has 0 value, the OneDealer communicates directly with the database.

Login

OneDealer application was already capable of user login without the need of SAP B1 existence (web.config app settings key: ODLoginType).

User Management

In OneDealer app we use a lot the B1 User entity, but it could be configured only by B1 environment. In the user management section we made some minor changes and now when we create an OneDealer user, we create also the "B1 User" , "Employee info" and "Sales person" entities.

Data Access Layer

In OneDealer we make use of classes called 'Managers' where they inherit from a base class BusinessCaseBaseManager, whick contains a set of generic methods for the data access.

We won't describe here how 'Managers' are working, but we will be referencing on how we change the behavior based on the HasSAPB1 flag.

As we mentioned above, each tenant-company, has a flag that indicates whether it has SAP B1 or not. This information is loaded to the Manager, by the reference of the SystemOptionsProvider , which contains information regarding the data access configuration, among them is the HasSapB1 flag.

If the flag is false, then it is loaded through Dependency Injection the SqlEntityRepository, whick operates as a Service Layer substitution.

SQL Entity Repository

This repository implements the same methods to the Service Layer Repository and can handle entities with sub collections (Lead / Vehicles of Interest), Series, Historical data and Primary Keys.

Entities with Sub collections

Each Entity definition has a declared relationship with the child entity , by using associations of LinqToDb ORM Library.

Every time an entity is operated with a CRUD command, we search if it has associations, and we apply also to them CRUD operations.

Series

Before the creation/insert of an entity we search to find if the entity has any series declared in order to retrieve the next number that must assigned for the primary key.

Primary Keys & Sequences

If the entity does not have any series declared, we search for the sequence of the table and assign the next number of the sequence to the primary key.

History Tables

Service Layer and SAP B1 , when a change is applied to a table, it stores the previous record to it's own historical data table.

It was considered as important , so we implemented also this logic.

Note: Not all tables have historical tables and we have created a view that contains them.