Compatible versions with ECC 6.0

[jonlarruzea]

Hi,

We are planning the upgrade of our SAP installations:

- R3 4.6C, 4.7 --> ECC 6.0

- BW 3.1, 3.5 --> BI 7.0 (NW2004s)

- SRM 2.0 --> SRM 5.0

- CRM 4.0 --> CRM 5.0

Of course we can't do all the upgrades at the same time, so, in order to decide in which order we make the upgrades, we must be sure that the new versions will be compatible with the old ones.

In the quicklink "service.sap.com/r3-plug-in", menu option "SAP R/3 plugin --> Integration of SAP R/3 / Enterprise, ERP and SAP Components" there are some tables where we can analyze the compatibility between all the BW, SRM and CRM versions and R3 versions prior to ECC 6.0 (4.6C, 4.7, ECC 5.0), according to the plug-in version. From 2005 there seems to be a strategy change in the integration interfaces:

"SAP ECC 6.0 and subsequent releases will automatically contain all integration interfaces that so far have been contained in the SAP R/3 Plug-In and that ensured the technical integration with other SAP Components."

As I understand, ECC 6.0 will automatically contain all the integration interfaces and there will be no more R/3 Plug-In versions. How can I check the compatibility between ECC 6.0 and the other BW, SRM and CRM versions? In the quicklink there are integration matrix available for R3 Enterprise and ECC 5.0 but there is no information for ECC 6.0. Are the versions compatible with ECC 5.0 too compatible with ECC 6.0? As ECC 6.0 seems to "automatically contain all integration interfaces that so far have been contained in the SAP R/3 Plug-In", does it mean that the integration matrix available for ECC 5.0 is too valid for ECC 6.0?

We have found a specific note (931020 "SRM connection to an ERP 2005 (ECC 600) backend") for the integration between ECC 6.0 and SRM but we didn't find any note regarding BW or CRM.

How can we check wich versions (BW, SRM, CRM) are compatible with ECC 6.0? Can we use the integration matrix available for ECC 5.0 in the quicklink "service.sap.com/r3-plug-in", are there specific notes like the one available form SRM (931020)?

We need to be sure as soon as possible that after the upgrade of our R3 4.6C and 4.7 versions to ECC 6.0 they will be compatible with our actual BW (3.1, 3.5), SRM (2.0) and CRM (4.0) versions.

Thanks in advance!!

[Former Member]

Hi,

Finally did you get any reply from SAP ? I have similar requirement and was searching thread and got to know about this.

Please share if you got any info on this. Appreciate it.

Thakns

Best Regards,

CK

[jonlarruzea]

Hi,

Following Markus recommendations I contacted SAP local support and they requested me to open a new OSS message. I did it (message 0000640197/2007), on 08.08.2007 they changed the component to "XX-SER-REL" but since then I had no answer from SAP.

As soon as I get any answer from SAP about the compatible versions (BW etc) with ECC 6.0 I will post it in this thread.

Regards,

Jon

[jonlarruzea]

Hi,

Finally got an answer from SAP:

-

---

About the question of the interfaces contained in R/3 Plug-in in

ECC 6.0, it is true that all interfaces released so far for R/3 Plug-in

are contained in the core system of SAP ECC 6.00. Then the interfaces

which connects the SAP ECC with your old other products like SRM, BW

should still work normally.

-

---

So I guess that the R/3 Plug-in integration matrix available in "service.sap.com/r3-plug-in" for ECC 5.0 is valid for ECC 6.0 too...

Regards,

Jon

[Former Member]

to followed unicode rules.

ABAP Development under Unicode

Prior to Unicode the length of a character was exactly one byte, allowing implicit typecasts or memory-layout oriented programming. With Unicode this situation has changed: One character is no longer one byte, so that additional specifications have to be added to define the unit of measure for implicit or explicit references to (the length of) characters.

Character-like data in ABAP are always represented with the UTF-16 - standard (also used in Java or other development tools like Microsoft's Visual Basic); but this format is not related to the encoding of the underlying database.

A Unicode-enabled ABAP program (UP) is a program in which all Unicode checks are effective. Such a program returns the same results in a non-Unicode system (NUS) as in a Unicode system (US). In order to perform the relevant syntax checks, you must activate the Unicode flag in the screens of the program and class attributes.

In a US, you can only execute programs for which the Unicode flag is set. In future, the Unicode flag must be set for all SAP programs to enable them to run on a US. If the Unicode flag is set for a program, the syntax is checked and the program executed according to the rules described in this document, regardless of whether the system is a US or a NUS. From now on, the Unicode flag must be set for all new programs and classes that are created.

If the Unicode flag is not set, a program can only be executed in an NUS. The syntactical and semantic changes described below do not apply to such programs. However, you can use all language extensions that have been introduced in the process of the conversion to Unicode.

As a result of the modifications and restrictions associated with the Unicode flag, programs are executed in both Unicode and non-Unicode systems with the same semantics to a large degree. In rare cases, however, differences may occur. Programs that are designed to run on both systems therefore need to be tested on both platforms.

Other Changes

1. Bit Statements

2. Adding Field Sequences

3. Loops with VARY and VARYING

4. Creating Subroutines

5. Saving Programs

6. Assigning Types for GET/SET PARAMETER

7. Unreachable Statements

8. Function Modules with Incorrect Parameter Names

1. Bit Statements

Previously, the system checked for the bit statements SET BIT i OF f [TO g] and GET BIT i OF f [INTO g]whether the field f is character-type; X fields, X strings, and flat structures are usually regarded as character-type. For Unicode programs this is no longer useful, because the types X and XSTRING no longer count as character-type and the bit by bit access to character-type fields or structures is no longer platform-independent. Therefore, with these operations in Unicode programs, the field f must be type X or XSTRING.

For the bit mask operations f O x, f Z x, and f M x you could previously use all number-type and hence all character-type types for the left operand f. In Unicode programs, the f operand must now be type X or XSTRING.

2. Adding Field Sequences

When adding field sequences, restrictions apply to the following statements in Unicode:

ADD n1 THEN n2 UNTIL nz [ ACCORDING TO sel ] GIVING m ...

ADD n1 THEN n2 UNTIL nz TO m [ RANGE str ].

1. The operands n1, n2, and nz must be type-compatible with one another.

2. The distance between nz and n1 must be an integral multiple of the distance between n2 and n1.

3. A syntax or runtime error occurs if the fields n1, n2, and nz are not in a structure. This structure must be recognizable statically or its valid area must be marked explicitly using the RANGE addition.

4. At runtime, the system ensures that the RANGE area is not left.

ADD n1 FROM i1 GIVING m [ RANGE str ].

1. Field n1 must be within the structure. The structure must be explicitly defined using the RANGE addition if it is not recognizable statically.

2. For this variant, the system also checks at runtime whether n1 and the addressed values are within the structure.

3. Loops

Loops with the VARY or VARYING addition are also problematic in Unicode, since a type-a access to memory contents cannot be ensured and memory can be overwritten inadvertently.

DO ... VARYING f FROM f1 NEXT f2.

For this statement, the fields f, f1, and f2 must be type-compatible with each other. To prevent memory contents being overwritten, a RANGE for valid accesses is introduced implicitly or explicitly for the following statements:

DO ... TIMES VARYING f FROM f1 NEXT f2 [ RANGE f3 ].

WHILE ... VARY f FROM f1 NEXT f2 [ RANGE f3 ].

A syntax or runtime error is caused if f1 or f2 are not included in f3. If the RANGE addition is missing, it is defined implicitly from FROM f1 NEXT f2 as follows:

1. If both f1 and f2 are statically recognizable components of the same structure, the valid RANGE area is defined from the smallest structure that comprises f1 and f2.

2. A syntax error is triggered if it is recognizable statically that f1 and f2 are not part of the same structure.

3. A valid area must be defined explicitly using the RANGE addition if the connection between f1 and f2 is not recognizable statically.

If you specify a deep structure as the RANGE addition, the system checks for every loop pass that there are no field references, object references, tables, or strings in the area read.

4. Creating Subroutines

When automatically generating subroutines using the statement GENERATE SUBROUTINE POOL itab NAME name, the generated program inherits the content of the Unicode flag of the generating program.

5. Saving Programs

When automatically generating programs using the statement INSERT REPORT prog FROM itab, default values are set for the TRDIR entry as before. Amongst other things, this statement has the new addition UNICODE ENABLING uc, with which the Unicode flag of the inserted report receives the value of uc. If this addition is missing, the following applies:

1. A Unicode program creates a Unicode program.

2. A non-Unicode program in turn creates a non-Unicode program.

3. A non-Unicode program becomes a Unicode program if it is overwritten by a Unicode program.

4. A Unicode program remains a Unicode program if it is overwritten by a non-Unicode program.

6. Assigning Types for GET/SET PARAMETER

For the statements GET PARAMETER ID pid FIELD f and GET PARAMETER ID pid FIELD f, f must be character-type. You can use the EXPORT and IMPORT statements for storing non-character-type fields and structures.

7. Unreachable Statements

In Unicode programs, unreachable statements cause a syntax error. In non-Unicode programs, there was previously only a syntax warning.

8. Function Modules with Incorrect Parameter Names

In Unicode programs, calling a function module, whose parameter names are specified statically as a literal or constant, causes an exception that can be handled if an incorrect parameter name was specified. This only applies to function modules that are not called via Remote Function Call. In non-Unicode programs, an incorrect name was previously ignored.

[markus_doehr2]

Can you tell me, what this has to do with the topic questioned? I have seen you posting the same text to many threads here - contextless...

--

Markus

[jonlarruzea]

Hi,

Thanks for your help Markus. I already opened an OSS message but SAP complains that it is a "consulting" issue... I don't agree with that, I think that SAP must publish the compatibility of their software versions in any place (Sapnet, Notes etc) and I don't think it must depend on consulting experiences...

In the "r3-plug-in" quicklink it is published a "Overview Strategy Change 2005", informing that "SAP ECC 6.0 and subsequent releases will automatically contain all integration interfaces that so far have been contained in the SAP R/3 Plug-In..". That means that from ECC 6.0 up there will be no Plug-in component and it will be automatically contained in ECC components.

That is quite clear for us but before the strategy change in "r3-plug-in" quicklink some integration matrix were published in the link:

+ SAP Plugin --> SAP R/3 Plugin --> Integration of SAP R/3...

From ECC 6.0 up there is no integration matrix available. The "Overview Strategy Change 2005" says that "ECC 6.0 will contain ALL INTEGRATION INTERFACES THAT SO FAR HAVE BEEN CONTAINED IN THE SAP R/3 PLUG-IN". From this statement can we assume that ECC 6.0 can be integrated with the actual releases supported by PI 2004.1? Thus, can we use for ECC 6.0 the integration matrix available for ECC 5.0 in the following link?

+ SAP Plugin --> SAP R/3 Plugin --> Integration of SAP R/3... --> SAP

ERP Central Component

According to this link ECC 6.0 should be compatible with BW 3.1, BW 3.5 and CRM 4.0 and not compatible with SRM 2.0.

After the "Strategy Change 2005" how will we know which ECC future versions will be compatible with future BW, SRM, CRM etc. versions if no integration matrix is published?

Thanks again!

Jon

[markus_doehr2]

Hi,

Thanks for your help Markus. I already opened an OSS

message but SAP complains that it is a "consulting"

issue... I don't agree with that, I think that SAP

must publish the compatibility of their software

versions in any place (Sapnet, Notes etc) and I don't

think it must depend on consulting experiences...

Really? This is ridiculous... I would INSIST of getting an answer. Sometimes the first level support is giving that statement way too fast. Sent the message back and ask if they are really serious about what they say. If that does not help, I would contact the sales department and/or the complaint management.

After the "Strategy Change 2005" how will we know

which ECC future versions will be compatible with

future BW, SRM, CRM etc. versions if no integration

matrix is published?

SAP will make sure the interfaces will be compatible, everything will go into PI_BASIS, they may, however, be a dependency between the PI_BASIS version on the two systems. SAP must assure that it´s working in future version, if it is not it´s certainly an error - that´s at least what I understand.

--

Markus

[jonlarruzea]

Hi Markus,

Thanks again for your help. I insisted 3 times but SAP's response was always the same (message 0120025231 0000619519 2007):

-

---

Dear Jon,

As earlier my Colleagues already confirmed that this is a consulting

issue. Which is beyound our scope of support activities. So I would

request you to contact through componant XX-RC-EOD (Expertise-on-Demand)for cunsulting support issue.

With best regards,

Pratip Bhattacharyya

Support Consultant

Active Global Support - Technology

SAP Asia Pacific

-

---

So I finally confirmed the message. I agree that it is ridiculous, SAP support used to be better in the past...

Could someone please be able to answer where can I find any detail information about compatible versions (BW, SRM, CRM) with ECC 6.0??

Thanks again!

Jon

[markus_doehr2]

This is really a BAD thing...

Contact your sales department and I would also call the complaint management and tell them, that the information you request, is not available. Make some noise

--

Markus

[Former Member]

SAP support was one of the best in the past, but lately it became one of the worst. Long wait time for answers, now they take 3-4 days just to change the status of the OSS message from send to sap to In Processing!!! Their first replay will be with a generic note, they don’t even bother to open the attachment (error log, screen etc ) we attach with the message . Seems their first level support doesn’t have much experience with the product and they think the people working in client place doesn’t have knowledge

I will get required support within minutes for a HP or Dell laptop which cost $1000 not from SAP which cost $$$$……..  . Other side is , if I am not satisfied with HP or Dell , I Can put another 1K and go for Sony Vaio or Mac , unfortunately that cant be done with SAP and they I think they are taking advantage on that ..  . I was just wondering anyone else have the same experience ..

Thanks

Prince Jose

[markus_doehr2]

I would say "it depends". My experiences are (12+ years) that it´s VERY component dependent.

What I remark is, that the BASIS parts (BC) usually works pretty good, especially the database components. We use mainly SAPDB/MaxDB and their support is really superior, they answer fast, they call, they communicate with updates etc. it´s just great working. Other components (e. g. SV - Solution Manager) are pretty slow, IF you get someone at the line, they do their best to get problems fixed but I think they are just "overflow".

What I also see as a big problem is the strict separation of "Support" and "Development". Messages are first processed in the "Installed Base Maintenance"; that part is almost completely separated by the development and they get measured on number of messages, that are sent to the development - the less the better (of course). So they will do everything to keep the message either at their level or get it fixed/confirmed by the customer so they don´t need to send it further. So in most cases the development isn´t even AWARE of a problems, that arises again and again - even if by design - because the IBM (Installed base maintenance) will always point to an exisiting note and so "fix" the problem.

And THIS may be your actual problem with your message. The 1st Level (IBM) doesn´t want to push that message to development, I´m pretty sure someone from the PI development would be able to answer that question in a matter of minutes but it would be a bad point for them. Given the fact, that it´s end of month and that now every message counts for the accounting and number of messages in July, I can well understand, that they push it simply to consulting to get rid of it.

It becomes even worse if you have a competence center (we have) - there you also get measured in OSS calls created and counted, which ones were actual real problems and which ones were not (qualified/not qualified).

So basically the support (IBM) works AGAINST the customer and AGAINST the competence centers instead of working TOGETHER WITH them.

SAP has so many products and so many dependencies between them -it´s just impossible to have a support organization that will manage that, it´s becoming too complicated.

I have had experiences where people suggest to "reboot the system" because I got some update error in the R/3 - just because they don´t want to forward the message to the development appropriately and due to the lack of knowledge they try everything to keep the customer busy by "try-and-error" instead of fixing a root cause.

As said, it´s not generally the case, it´s a matter of component and a big matter of the actual person sitting behind the desk at the support. I also have had statements like "

Be happy that there are problems, otherwise you wouldn´t be working any more if everything was working perfect..."

- which was written by a support guy. This is not only completely inappropriate but is also showing me the motivation and the "thinking" behind the scene.

You have the option of buying "Premium Support" (which is 22 % or 24 % of you net license volume - don´t nail me on that though), where someone @ SAP will take care of your OSS calls - but that can´t be the solution, in my opinion.

Long story short - you´re not alone - and the only thing you can do is to make a real real noise at your sales department, at the complaint management and at your local support organization, call them, write emails, call them, call them, call them. It´s VERY cumbersome but we as customers pay money and therefore can expect a quality support.

--

Markus

[Former Member]

Hi Markus,

As you mentioned , MaxDB support is really outstanding , I even got the reply on weekends for non production systems. I am little upset with the support thats all but bottom line is SAP is my bread and butter so no more complaints

Thanks

Jose

[markus_doehr2]

Sure - same here - but it can´t be (in my understanding), that a company delivers software and then not tell what is compatible with what - of their OWN product portfolio.

Deal with how you think it´s appropriate but I would certainly do BIG noise in that case

--

Markus

[Former Member]

True .. I agree with you . they should put that somewhere and we should be able to find that without Consulting OR creating a ticket in XX-RC-EOD (Expertise-on-Demand)

[markus_doehr2]

This is a very interessting topic

I would say:

BW 3.5 and CRM 4.0 will work with ECC "out-of-the-box", for BW 3.1 I'm not sure.

In any case, I'd open an OSS call - SAP needs to provide that information somewhere - I'm sure it is buried in some of the > 1 Mio notes...

--

Markus