com.sap.aii.ib.core.ejbutil.rb_all.SERVER_MS_NOT_AVAILABLE Error on Integration Builder Login

As soon as you enter the credentials on ESR/Integration Repository/Integration Directory/Integration Builder, if you see the  error "com.sap.aii.ib.core.ejbutil.rb_all.SERVER_MS_NOT_AVAILABLE", it means that the message server could not connect to  the P4 port of the PI system

Call the following URL and check if P4 port is listed:
http://<msg_server_host>:<msg_server_port>/msgserver/text/logon

Try msg_server_port as the port 81NN, when NN is the instance number of ASCS or SCS or Central Instance (where ABAP message server and enqueue servers are running)

Depending on which message server lists the P4 port, maintain the message_server_port (81NN) in the following exchange profile parameters

  • com.sap.aii.connect.directory.mshttpport
  • com.sap.aii.connect.repository.mshttpport
If the error includes java.net.MalformedURLException, then the above profile parmaters are not maintained at all and must be maintained along with com.sap.aii.connect.repository.mshost and com.sap.aii.connect.directory.mshost

SAP Database Refresh - Noting trkorr field in the table E070L

Before you begin the refresh activity, note down the current value of trkorr in the table E070L. This table has only one row and the field TRKORR contains the current transport number.

After refresh, the transport request numbering will be changed creating a conflict with the already exported transports that are present in the file system. This is because the production system would have fewer released transport requests compared to QA.

To avoid this conflict, you can note down the current request sequence held in E070L table and update it after the refresh. If you did not note the current request number, you may be able to find that out from the /usr/sap/trans/log/ALOG* file.

Archive Analysis of CO tables using RARCCOA1, RARCCOA2, RARCCOAA and RARCCOAP

When you want to archive CO tables (COEP, COEJ, COSP, COSS, COST), there are several possible archive objects:
  • CO_ALLO_ST
  • CO_CCTR_PL
  • CO_COSTCTR
  • CO_ITEM
  • CO_KSTRG
  • CO_ORDER
  • CO_PROCESS
  • COPA2_*
  • PM_ORDER
  • PP_ORDER
  • PR_ORDER
  • PS_PROJECT
  • RE_RNTL_AG
  • SD_VBAK
In order to choose the best archive object suitable to archive the data in your system, SAP has delivered the following programs:
  • RARCCOA1: Creates data extract for analysis of CO tables for archiving objects: CO_ITEM, CO_PROCESS, CO_KSTRG, RE_RNTL_AG, CO_COSTCTR, PS_PROJECT, CO_ORDER, PP_ORDER, PM_ORDER, PR_ORDER, SD_VBAK, COPA2_*
  • RARCCOA2: Evaluates the data extract from the report RARCCOA1
  • RARCCOAA: For analysis of CO tables for archiving object CO_ALLO_ST.
  • RARCCOAP: For analysis of CO tables for archiving object CO_CCTR_PL.

RARCCOA1 and RARCCOA2

Program RARCCOA1 counts the entries of required CO tables, assigns them explicitly to an archiving object and creates a data extract with the required information.

 RARCCOA1 counts the entries of required CO tables

Report RARCCOA2 reads the dataset provided by RARCCOA1 and processes it as appropriate. You receive a list as a result of the analysis in which the number of the entries in these tables is compared with the archiving objects.

RARCCOA2 reads the dataset provided by RARCCOA1

The list first displays a summation of the data generated by program RARCCOA1. You can obtain more information by clicking on the totals line. In addition, you can set filters (for example, only analyze the data for one archiving object in detail), choose other sorting (for example by fiscal year) and change the summation.

The list states how many entries for the respective table and how many entries in the system (column 'ALL') are available in total. It does not inform you which entries can or should actually be archived. The system cannot determine how long you need data or want to retain it in the system.

You should pay particular attention to the following entries in the list:

  • Empty field for "Object" (5th row in the screenshot): there is not an archiving object responsible for these table entries or none is known to the program.
  • Archiving object CO_ITEM (not detected in this screenshot): All line items (COEP, COEJ, ...) can be archived using CO_ITEM. However, you are recommended to take the other cost objects into account as well.
  • Archiving object CO_COSTCTR (1st row in the screenshot): CO_COSTCTR also stands for CO_CCTR_ID, CO_CCTR_PL and CO_CCTR_EP (and CO_ALLO_ST). You have to decide in another step which object should actually be used (see reports RARCCOAP and RARCCOAA). You are recommended not to use archiving object CO_CCTR_ID. Use archiving object CO_COSTCTR to archive actual data.

RARCCOAA

The analysis of CO tables (COEP and COEJ) using this report is recommended particularly when Allocations (assessment, distribution and periodic reposting) are in use and are frequently repeated or reversed. The program calculates how many entries for the chosen tables can be archived in which fiscal years and controlling areas by using archiving object CO_ALLO_ST. It then processes the data calculated and displays it in the form of a list.

RARCCOAP

You are recommended to use this report if actual data must be retained for cost centers but you no longer need planning data. The program reads all entries for the tables chosen (COEJ, COSP, COSS, CPST) and determines which of them can be archived by archiving object CO_CCTR_PL and which selection criteria you can use (fiscal year, controlling area). It then processes the data determined and displays it in the form of a list.

Fixing bdf output

The output of the bdf command is not formatted in a reader friendly fashion. For example the output of bdf sometimes writes the disk usage details in two lines

Filesystem          kbytes    used   avail %used Mounted on
/dev/sapsidvg/lvsapmnt
                   8388608 3450677 4670062   42% /sapmnt

To format the output properly, use the following awk trick:
 bdf | awk '{if (NF==1) {line=$0;getline;sub(" *"," ");print line$0} else {print}}'

The output know will look like this:
Filesystem              kbytes    used   avail %used Mounted on
/dev/sapsidvg/lvsapmnt 8388608 3450680 4670058   42% /sapmnt

SAP S/4 HANA - Realtime and Simple

SAP R/2 was the first highly stable solution released by SAP. "R" stood for real-time data processing and "2" stood for the two layers: presentation + integrated application & database. This was in late 70's, when companies were running their business applications on mainframes, and R/2 was apt with the existing technology. SAP R/2 marked the first generation of SAP's business solution.

Then came SAP R/3 in the 90's, capitalizing on client-server architecture. "3" signified the three layer architecture (database, application and presentation). The separation of application layer from database layer reduced the load off database and helped improve the overall performance of the solution. This was immensely popular (second) generation of SAP's business solutions. One can attribute the success to Y2K and SAP R/3 fitting the business needs of most organizations looking to dodge Y2K paranoia.

SAP was riding the wave of Y2K-led-success while the dot com bubble of the late-90's slipped past them. They joined the the web technology a bit late with the release of SAP Web AS or NetWeaver (refrigerator). Their third generation business solution-SAP ERP, which was based on Web AS, was released in 2003-04.

SAP has been supporting multiple database vendors. SAP applications and data models were designed keeping the abilities of those popular database vendors in mind. The core SAP application was not optimized for a single database software. This has changed with the 4th generation. The data model is simpler now and is optimized for SAP HANA.

SAP S/4 HANA - Realtime and Simple

SAP's next big thing is SAP S/4HANA.

The main featured of SAP S/4HANA are:

  • Reduced DB footprint – 1/10 because of simplified data model)
  • 3-7 higher throughput
  • Up to 1800x faster analytics
  • 4x less processing steps
  • No locking, no updates, parallelism for throughput
  • Multitenancy
  • Unlimited workload capacity
  • Capable of running all kinds of the systems (ERP, BW, CRM, SCM, PLM) in one system – will be available as phased availability
  • Fiori UI – responsive for any device
  • Capable of processing all type of data: text, social, geographic, graph processing
  • Deployments possible as (public/managed) cloud, on-premise
  • Guided configuration – reinvented implementation guide (IMG)
  • No anyDB approach any more, it only runs on HANA DB

SAP is moving towards a new paradigm as it has always done in the past. A lot of changes this time. For example: tables like MARA that have been around since R/2 days will not continue to exist on S/4HANA. SAP GUI may be phased out, it's all on Fiori. New innovations will not happen around AnyDB (non-SAP databases), it's all on HANA. There won't be separate transactional and analytical systems.

One has to keep up with where SAP is going with S/4HANA. You can find that out from the upcoming openSAP course SAP Business Suite 4 SAP HANA in a Nutshell. The free course starts on March 25th.