DI Server License info

[Former Member]

I accidentally replied to an answered thread, but this is a slightly different question.

How is the license specified for DI Server? Is the license I need called SDK Tools? (Looked at the License administration in SAP and there's one for SDK Tools)

I assume the demo database already has the DI Server license because the login works for that, but it doesn't work on the company database.

Can anyone confirm this?

[former_member201110]

Hi Victor,

The DI Server requires its own license and is different from the SDK Tools (it should appear as DI-Server in your license file).

I'm actually surprised that you can test on a demo database but not a production database (ie if you are not licensed then I would expect it to fail regardless of the database). Is it possible that your testing on the demo database was done during the first 30 days (when it would be running under an evaluation license)?

Also note that SAP are stating that the client needs to have CPU licensing for SQL Server if they wish to use the DI Server.

Kind Regards,

Owen

[Former Member]

Oh ok thanks for that.

Yes the testing was done in the first 30 days under evaluation license.

When you say the client must have CPU licensing for SQL server, is that the client in which the DI Server service is running?

I'm running the DI Server on the same server as the production database so it does have SQL Server installed.

[former_member201110]

Hi Victor,

By client I was referring to the company who is running SBO (ie SAP's client or customer).

SQL Server has two types of licensing; by CAL or by CPU. CAL (client access licensing) is per workstation and CPU is licensing for each CPU on the database server. CPU licensing is not restricted by the number of workstations connecting to the database so it is used in situations where you've got a large number of users connecting concurrently. The bad news is that CPU licensing is not cheap and you need to buy a separate license for each physical CPU that is in the database server if you want to make use of all processors (dual or quad core CPUs still count as a single CPU).

In order to use DI Server, SAP require you to purchase CPU licensing for the SQL Server software. This is a SAP requirement due to Microsoft licensing rules. This makes it a very expensive purchase if you have a small number of SBO users (and assuming you are currently using SQL CAL licensing) because you'll have to upgrade your SQL licensing at the same time.

Kind Regards,

Owen

[Former Member]

The SQL Server installed is the one that came bundled with SAP. So would that have CPU licensing?

[former_member201110]

Hi Victor,

I'm afraid you'll need to check with your SAP Partner as to which SQL licensing you have. Typically, if you bought SQL licensing as part of a SBO purchase then the licensing will be CAL licensing. However, if you are a larger site, it may have been more cost effective to have bought CPU licensing. Another way to check is to look at your software purchase documentation. If you see references to CAL licensing or if the SQL license is being quoted per user then you are running under CAL licensing.

Kind Regards,

Owen

[Former Member]

ok great I'll look into it.

Just another question, which is slightly off-topic. At the moment I'm using DI API to create the quotes in SAP for an online order entry.

I'm just worried that if the number of orders coming in is large, the performance will degrade quite a bit.

So in my case would you recommend switching over to DI Server? or is there a way to use DI API, but limit the degradation in performance, when up to 100 orders (on average) are being placed within an hour.

I've found that at the moment the web application uses quite a bit of memory, i.e., it can easily go up to 200MB.

I'm not sure whether it's because of the DI API being used as a web service or if it's my poor programming skills.

[former_member201110]

Hi Victor,

Yes, the DI Server would be a better option in this case. Alternatively, you could look at a third-party integration tool such as iBolt (which doesn't use the DI Server and therefore wouldn't have the SQL CPU licensing requirement).

The DI API does have a habit of leaking memory which is particularly noticeable once you start looping through larger numbers of transactions, updating or adding. You can alleviate a lot of that by explicitly disposing of any DI API object once you've finished with it and calling the garbage collection.

For example

System.Runtime.InteropServices.Marshal.ReleaseComObject(sboRec)
sboRec = Nothing
GC.Collect()

where sboRec is my DI API object (eg SAPbobsCOM.RecordSet)

Kind Regards,

Owen

[Former Member]

>

> In order to use DI Server, SAP require you to purchase CPU licensing for the SQL Server software. This is a SAP requirement due to Microsoft licensing rules. 
> 

Does this mean I can actually get a DI Server license, test out the application and then decide whether I want to continue with it by getting the CPU license for SQL Server?