Using EntityFramework with SAP Business One without losing warranty?

Question

i'd like to know if someone is using EntityFramework with SAP Business One? If yes how do you handle the warranty. SAP only allows to Insert/Update/Delete through their DI Server API otherwise you lose the warranty. So if i am only allowed to select i can only use Entity Framework for reading data, is that correct?

Anyway would you recommend to use EntityFramework with SAP Business One or are there performance issues with an high amout of data?

Greetings.

Answer 1

You absolutely cannot use anything other than the DI to insert, update or delete data from the SAP Business One database! As someone who has spent the last 9 years working with SAP as a partner, my honest advice is do not even try it. As soon as you break the database, SAP will not support it, and you'll end up paying someone a lot of money to fix it...

Leaving aside the issues of warranty, even the simplest operation in SBO (let's say, adding a single Invoice with 1 line) causes an object model update encompassing at least 10 or 11 "major" tables and their own related sets of "minor" tables....fire up SQL Profiler and create an invoice in the SBO client, and watch how much SQL is generated, not just the inserts but the selects as well....plus the business logic of what SAP is doing with all this data is totally hidden from the you the caller. You have got very little chance i.e zero chance of modeling this correctly yourself....

---

As regards using the EF to read data from the database, again I would not bother - much of the data that you see in the SAP client is not taken out by correctly defined relationships which means your models will never be quite right. Better to sick with plain old SQL, by all means you can map this data into your own in-memory models.

In this respect SQL Profiler is your friend; nothing will give you 100% exactly how SBO does it but it will at least give you access to the same data it uses by executing operations in the client and watching the resultant queries.

Also just to correct one point - there are two ways to do this. One is the DI Server, which is an XML-based service, and the other is via the DIAPI which is a COM-based library you can link with your project and lets you work in a more object-oriented way (for certain, extremely limited values of "object oriented"!)

Update October 2019:

With respect to my previous advice about not using EF to read the data from the SAP tables, what I've found myself doing more and more - especially with EF Core Query Types is creating views against the various tables that make it simpler to read the data my applications need. A big advantage of this is that you can join in multiple tables from SBO and clean up column names, etc. And being views they are read-only and thus safe to use.