Data Dictionary Type inconsistency

Recently I faced strange situation related to ABAP data dictionary. While I was logged into the system suddenly I could not run any of standard transaction. Literally all stopped, nothing worked, just everything seemed to ending up in ABAP dumps everywhere. As I could not even change to run tcode ST22 I had no really choice to see what is going on. Only this was the message:

Finally I found out one tcode which worked. It was SM21 tcode and here what I saw in there:

11:53:11 DIA  007 000 SAPSYS                 AB  0 Run-time error "DDIC_TYPE_INCONSISTENCY" occurred

11:53:16 DIA  007 000 SAPSYS                 AB  1 > Short dump "141128 115311 myserve r_SID_00 " generated error DDIC_TYPE_INCONSISTENCY occured p1=abap-gen

While I searched for “DDIC_TYPE_INCONSISTENCY” issue only advices I got was ot check consistency of data dictionary by reports like RSNTABCONSISTENCY or RSDDCHECK. However I could not ran these as nether SE38 was accessible.

Luckily I had an access to OS system of that SAP instance. As I logged into the OS I realized that some transport was being imported. After contacting Basis support I revealed that there was a patch import in progress in that transport. However for some basis issue that patch was not intended to be imported to that system although it was technically possible. Not proper patch caused that data dictionary was falling apart. Basically an objects which were active before got overwritten by the transport but as they were not correct there could not be activated due to syntax related issues.

What can I tell you… basis team admitted their mistake and we ended up restoring the system from (luckily) 1 week old backup. One more lesson learned!

Tools for migrating BW to HANA (BoH)

SAP NetWeaver Business Warehouse powered by SAP HANA or BW on HANA (BoH) is around for some time already. It was introduced in 2nd quarter of 2012 and meanwhile it got a lot of attention. Basically BW is usual choice when companies are trying to evaluate HANA. It is natural that first they just migrate to HANA as database and after some time they start to implement new project using new BW objects leveraging HANA functionalities. Or starting of re-implementing current BW data models to use HANA can happen. Anyway BW is getting a lot of attention as first system to be migrated to HANA.

It may be very tricky for people who are new to HANA even start with basic evaluation of what does it mean to migrate to HANA. To support tasks like this SAP is providing a few tools. In further text I try to list the tools and provide basics information about them.

Tools are embraced by central tool called – BW Migration Cockpit for SAP HANA. From the cockpit other tools for migrating BW systems to HANA are accessible.

Possible issues in RFC call between (non)UniCode systems

We can assume that nowadays most of SAP systems are running as UniCode enabled systems. However this wasn’t the case in past. Unicode conversions of SAP systems started around year 2005. As of NetWeaver 70 all SAP systems are shipped as UniCode. 0And still you may experience SAP system running as none UniCode complaint. Whole point of having UniCode SAP system is to enable cross language character set for international data processing. Basically this was driven by companies going multinational and pursuing of globalization.

What are the things one can face in case there are interfaces running between systems which all are not Unicode? A case can be that there is a function module (RFC one - BAPI) placed in SAP system A. The function module is called remotely from another SAP system – B. Systems A and B are not both Unicode complaint. While RFC data transfer between the two a character data based on different code pages are damaged. This is caused because partners are not both UniCode. In case conversion of particular character didn't succeed then the character is replaced e.g. by #.  This basically means that data is not readable in target system; it is damaged and therefore not usable.

How to solve such a situation? The RFC data transfer converts data depending on the transport code page only. The transport code page is independent of the code page the data are encoded in. What is the transport code can be set up in TA SM59 -> particular RFC -> UniCode tab. So basically by specifying of what the transport code is and how character conversion is supposed to take place we can avoid such issues.

PS: If you ever wonder how System Status popup is build I have information for you. Whole dynpro is coded by FM STATUS_ANZEIGEN screen no 700.

Further info:

547444 - RFC Enhancement for Unicode ./. non-Unicode Connections

LSA++ as successor of LSA

There are few options when it comes to modeling of EDW design. SAP recommends so called Layered Scalable Architecture (LSA). This one I covered in my post here. Such architecture gives a guide for implementing new models in BW. Means what kind of layers are supposed to be used for that particular model.

The (E) DW Layer consists of the first 4 layers. The Architected DataMart Layer or BI Layer consists of the last 3 layers. Here are reference Layers:

·        Data Acquisition Layer (DWH)

·        Harmonization & Quality Layer (DWH)

·        Corporate Memory Layer (DWH)

·        Propagation Layer (DWH)

·        Business Transformation Layer (BI)

·        Reporting Layer (BI)

·        Virtual Layer (BI)

With HANA coming into the scope of BW which is known as BW on HANA (BoH) the LSA got renewed. Basically also HANA optimized objects are incorporated into the architecture. Because of nature of HANA data persistency is less needed across different layers of LSA. This leads to reduction of the layers. Basically this new reference architecture built for BW on HANA is called Layered Scalable Architecture (LSA++)

These are following new InfoProvider objects incorporated into LSA++:

Open ODS View – is object designed to consume external sources with a given semantic. There are no InfoObjects needed to define analytic semantics. Instead it allows field-based modeling. This is in line with agile data modeling suitable e.g. for rapid prototyping. An analytic functionality can be employed on top of (external) data structures due to different interfaces like SAP HANA smart data access. External data (not residing in BW) can be combined with SAP BW data (master and transaction data). It is virtual object – data is not persistent. The Open ODS View object is equivalent of PSA layer in LSA.

Advanced DataStore object (ADSO) – is standard persistent InfoProvider, supports analytic queries, in future also planning apps, capable of calculating data changes within data flow, consolidates different types of IProv: classic DSO, w/o DSO, InfoCube. The consolidation of different objects can be done on the fly by switching its behavior without deleting the data. Modeling of ADSO is done only in Eclipse environment. The data is persistent in the ADSO.

(new) Composite Provider (ComProv) – this is meant for new composite provider available in BW 74 on Hana not the one available in BW 7.3. The new one is successor of MultiProv and Infosets. It is modeling object for both: joins and unions, can consolidate existing InfoProv (VirtualProv base on SAP HANA models, InfoSets, MultiProv, etc). Modeling of the new ComProv is done in Eclipse environment. It fits to Virtual(ization) layer of LSA++.

More information:

LSA++ - SCN doc

LSA++ for SAP NetWeaver BW on SAP HANA – SCN article by Juergen Haupt, EIM203 session

Components of SAP Gateway

I introduced SAP Gateway solution in my blog post here where I discussed installation of trial Gateway system. The SAP Gateway system is a framework deployable into ABAP Stack of NetWeaver where development of OData services is possible. Former mane of the SAP Gateway is SAP NetWeaver Gateway. It was renamed as per simplification initiative SAP is currently running.

I recently had a chance to work on the Gateway which was based on ABAP AS 74. I notice here that components related to the Gateway installed there were a bit different from other NetWeaver systems in particular those with versions below 74.

The difference was that were no components like GW_CORE, IW_FND and IW_BEP. Instead there was just one component called: SAP_GWFND. The newest current release of the Gateway is: SAP Gateway 2.0 Support Package Stack 09 740  0009          SAPK -74009INSAPGWFND. This basically means that SAP_GWFND in NW 74 contains all components which were delivered separately in lower NW releases.

Below I introduce what all the different components means:

SAP_GWFND - SAP NetWeaver Gateway Foundation

GW_CORE – Core Components

IW_FND - Foundation

IW_BEP - Business Enablement Component

More information:

1560585 - SAP Gateway 2.0 Release Note

ABAP: Dynamically generated WHERE conduction in SELECT

Sometimes ABAP programmers needs to do dynamical generation of WHERE conditions in SELECT statement. To do this the WHERE condition can be built by either CONCATENATE statement or by && string expression. Example in SAP documentation is provided here. Basically string variable is filled up with column name in which the lookup is performed and by lookup value:

cond_syntax = column &&  ` = value`. 

More over there are couple of function modules which can do this automatically. There are following FMs for that:

RH_DYNAMIC_WHERE_BUILD

CONVERT_SELECT_INTO_WHERE

Last note to this topic is related to lookups of string values. Usually while we want to search in SAP (e.g. in matchcodes) we use asterisk (*) as wildcard which matches one or more characters. However in SQL language instead of the asterisk a percent sign (%) is used for the same. Therefore while the WHERE condition needs to be build up to look up matches one or more characters before and after EMAIL literal in column USRID it has to look like following:

USRID like '%EMAIL%'