Let me preface this post with the comment that most of my documentation is mostly geared towards Basis admins with little PI experience.  I try to put together common issues that I see, make general directions on how to resolve that particular type of issue and share with the rest of the people with whom I work.  this document is also for a non-production system.  In a production environment you would need to be working with your function team before resending an IDoc with WE19.

One of the issues that I have encountered in our environment with custom IDocs is that we get a help desk ticket or issue from our project team saying that the IDocs are not getting to their destination.  When you check in sending system everything looks fine (e.g. in WE05 the status is 03 or green light).  This means that the IDoc is leaving ECC correctly but somewhere in PI there is an issue.

To start the troubleshooting, in the sending system grab an IDoc number of an IDoc having an issue.  Once you have that IDoc number, in your PI system go into IDX5 and search for that IDoc number, in my example below I used IDoc number 487746.

Ensure you change the date range to account for the date of the IDoc.

Next you'll see the correlating XML message of IDoc for which you searched.  Double click on that entry to bring up the XML data.

In the XML message you can se the error in the bottom right window.

"Runtime exception occurred during application mapping
com/sap/xi/tf/_MM_ZOTM_TPSDLS01_Stage_Roadnet_Del~;
com.sap.aii.mappingtool.tf7.IllegalInstanceException: Cannot create target
element
/ns0:MT_XMLSQL_Roadnet_Delivery/StatementName/dbTableName/access/G~"

Typically when you see an application mapping error this is caused by someone changing the IDoc structure.  With custom IDocs ECC and PI do not update the mappings automatically when the structure is changed.  This has caused issues for us numerous times.  It's a lot of coordination between your ABAP and PI developers as well as good communication between those teams and the Basis team.

So from here we go back into ECC and run transaction BD64.

Go to the environment menu then generate partner profiles.

Select the PI Model view, in this case QP1CLNT001

Click Execute

Run transaction WE19 and enter the IDoc number for which you previously searched.

Click Execute the click Standard outbound processing on the next screen.

Click the green check box.

Now when you check in your PI system in SXMB_MONI you should see the newly created IDoc has been processed without error.

I have been tasked with understanding how SAP PI can support different interface versions. Specifically how we will support a SAP system that is being rolled out across the globe.

I recently wrote a short blog entry Versioning in SAP PIabout versioning and had a limited response so I decided the investigate the matter in a little more detail. The following is based upon my own analysis, interaction with other developers, SAP Developer Network, SAP Service Support and external developer resources.

Change Types

Firstly let’s understand the various change types:

Changes that are Backwards Compatible

• Addition of new operations
• Addition of new data types or modified data types

Changes that are not backwards compatible.

• Removing an operation
• Renaming an operation
• Changing parameters
• Changing Structures

There are three known strategies for versioning:

Strict - Any changes result in a new version of the interface. It does not support backwards or forwards compatibility.

Flexible - Any incompatible changes result in a new version of the interface. The interface is designed to support backwards compatibility but not forwards compatibility. This means that any backwards-compatible change is considered safe in that it ends up extending or augmenting a service without affecting the interface.

Loose - Any incompatible change results in a new version of the interface. The interface is designed to support backwards compatibility and forwards compatibility. Instead of accommodating known data requirements, special features are used to make parts of the service intrinsically extensible so that they remain able to support a broad range of future, unknown data exchange requirements. This will result in vague interfaces that place the burden of validation on the underlying service logic. Not a recommended approach.

How do we indicate a new version? Most developers and developer resources suggest using the XML namespace to clearly delineate the version. A namespace value is sent with every SOAP message, HTTP Post or XML document. This allows the system to correctly determine what to do with an incoming message.

Options

With regards to PI the following options were considered

a) Create a new SWCV.

According to SAP documentation ‘a software component version is a shipment unit for design objects in the ES Repository’. You use a SWCV to group together objects that are shipped or installed together.’ SAP uses this approach for the majority of their standard content. You can’t copy objects between releases of a SWCV but use the Transfer Design Objects Function (ESR Menu under tools). This tool will transfer objects only if the source objects are more recent than the target objects or the target objects don’t exist. You can preview the changes and see what will be updated (source version is more recent), what can’t be transferred (the target version is more recent) or what does not need to be transferred (the versions are the same).

b) Create a new namespace with a version number.

Create a new namespace using the same name as the original namespace but adding a version number to the end. This will differentiate the versions although any service consumers will have to reference a different endpoint.

c) Ensure that the interface is backwards compatible.

Ensure all changes to the interfaces are backwards compatible. For example any new fields are optional and coding or mapping changes support both releases.

d)  Add a version number to the object names

Add a version number to the object names within the same SWVC and Namespace.

Analysis

a) Create a new SWCV.

Although this is appropriate for deploying different versions of a particular software package it doesn’t allow both versions to be used. Integration Directory objects refer to the interface by Communications Component/Interface Name and Namespace and not the SWCV.  The system will not allow you to add two interfaces from separate SWCVs to the same Communications Component Interface Name and Namespace. Therefore this approach will not work.

b) Create a new namespace with a version number.

This approach allows for changes to be implemented without impact to existing interfaces. The current interface would be copied to the new namespace, modified and in the case of an inbound interface the source system would be given the new target. In the case of outbound interfaces the target system would find that the payload would contain a new namespace. 

c) Ensure that the interface is backwards compatible.

Backwards compatibility isn’t easy to achieve. The functional requirements evolve over time, planned changes are deferred or cancelled and what seems like a simple change that may not have any impact may change significantly. This may result in having to unpick changes to implement subsequent changes. It also means that interfaces are not being developed correctly. This presents a high risk to existing interfaces and is not a recommended approach.

d)  Add a version number to the object names

Although this would work it would be confusing to maintain and is not a clean and elegant solution. I believe this presents a high risk to existing interfaces. It would be very easy to apply a change to the wrong version. This is not a recommended approach.

Proposal

Based upon my analysis I would like to propose option B, using a new namespace for all future development and supporting flexible versioning. At a high level it would work as follows:

1. Requirements reviewed, assessed
2. Compatibility
   1. Changes not backwards compatible?
      1. Prior version frozen, new release created
      2. Development to use current release
   2. Changes backwards compatable
      1. Modify existing version
3. Development
4. Deployment
5. New Version
   1. Existing consumers migrate when appropriate.
6. Updated Version
   1. Made available to all consumers on this release.

….repeat

It is very important the process is documented and agreed with the relevant teams. We need to ensure that all parties are aware of the process and buy into it. Supporting documentation, including specifications must be updated so it becomes easy to identify the release they relate to.It is more important than ever that supporting documentation is maintained and completed in a timely manner. Developers working in different geographies need to rely on the documentation they have access to.

A very specific namespace naming convention should be used to make it easy to identify the release that the corresponding objects belong to.

Namespaces should be used to differentiate development work conducted between different projects or areas.  The naming conventions that we will therefore adhere to are as follows:

urn:xxxxx.com:PI:<Software Component>:<Region if not in SWC>:<Area>:<Sub-Area>:<Version>

             E.g. urn:xxxxx.com:PI:A_B2B_RSP:B2B:CRMPunchout:YYYY

Benefits

No impact on existing interfaces

Ability to support aggressive project timescales

Customers can migrate when they want

Concerns

a) Freezing code, It is not possible to check out OR lock code via a transport. PI has the ability to restrict access to SWCV’s, Namespaces and individual objects via permissions and this is currently used to ensure objects cannot be created or edited in the Q, R and P systems. However, this may become too onerous to maintain but it would work. We have processes in place to ensure that all development requests are managed centrally, are documented and reviewed prior undertaking any work.

b) Migration to new releases. As the other countries play catch-up we will need to support migration to the later releases and then, when appropriate, decommission the earlier releases. How is the catch-up managed? It is annual, bi annual or quarterly?

c) Bug fixing. We must ensure that any bug fixes requested are documented and reviewed to see if they are appropriate. We must ensure that these are bug fixes and not an attempt to slip changes in unannounced.

d) Change Requests. We will need to plan any changes and determine how they will be incorporated into existing developments.

e) Communication. The changes, specifically the new endpoints should be clearly communicated to the project responsible.

Testing

To validate the proposal I performed a test in development. I took a simple HTTP to RFC synchronous interface as an example. Given a material code and language the interface will return the material code and material description from R/3. I tested this before attempting to create a new version.

1 Within the Enterprise Services Repository.

1. Created a new namespace
2. Copied ALL objects to the new namespace
3. Checked the copied objects to ensure that they were copied correctly.
4. Modify the message mapping to return a different message in the response
5. Activated the objects

 

2 Within the Integration Directory (configuration)

1. Create a new scenario. Same name, adding release as per the namespace.
2. Update communications component to use new interface
3. Create new configuration to use new objects
4. Activate objects

The request will now have a new namespace but everything else is the same. Each interface was tested and both worked as expected.

The test highlighted the following points

1. Certain objects, such as data types retain the original namespace once copied. A test should be performed with all object types so that post copy actions are documented.
2. Documentation should indicate what objects in the Integration Directory MAY NOT need to be duplicated.  This may include Communications Components, Parties, and Communications Channels etc.  There is no reason to duplicate configuration objects that will not be impacted by the change. Although it makes sense to duplicate all the ESR objects certain ID objects will remain the same.

References: 

http://www.ibm.com/developerworks/webservices/library/ws-version/

http://soa.dzone.com/news/web-service-contract

http://www.oracle.com/technetwork/articles/web-services-versioning-094384.html

Lately I came across the following blog about code sharing and spotted a reference to the OPI2 project. I found the subject of the blog appealing since the motives are quite similar to what let to creation of OPI2. There are often requirements which you cannot solve with the standard means and you have to start to design and develop an extension or own solution to tackle the challenges at work. A lot of material can be found in the SCN or on other websites such as Stack Overflow. However, they usually give good tips to start but are sometimes not mature enough to be used without much tinkering.

With the Open PI Initiative we want to deliver some ready-to-use solutions for special integration needs that are not in the PI standard distribution. I don’t know if all of you are aware of our section in the PI space, but with this blog I wanted to show some of our recent activities.

State of Play

As with most open source projects most of the work is done by the projects core team. A lot of this work is maintenance work such as guaranteeing that the solutions are working with the available SAP NetWeaver PI releases. We are usually testing and enhancing for lots of releases in parallel. Also for the 7.31 AEX Java-only installations we had to enhance the offerings so that they now run perfectly fine on “classic” configuration scenarios on double-stack installations as well as in an Integrated Configuration on a single-stack installation.

We are also building new features into our offerings. The AS2 adapter for example got extended with new features such as Dynamic Configuration of the connection parameters or certificate-based authentication for the Receiver Communication Channel. We are also providing customer-specific versions that are not released in the standard distribution because they are tailored for a very specific purpose.

Nevertheless, we are getting lots of questions regarding the usage of the offerings. Let me answer that question with the following statement: Yes, this software runs in production environments of lots of companies. Furthermore, the contribution part from the community regarding bug finding and solution suggestions works very well. It’s also interesting and surprising which companies use the OPI2 solutions. Since the start of the OPI2 project there have been over 4500 downloads. But usually we get the information about productive users only by chance. Normally, the user contacts us only if there is an issue with the solutions and luckily this is not often the case. Also from our experience we could identify the trend that Scandinavian countries seem to be avid open source users and contributors (or they just like to interact with the project team).

Summary

In the end, one of the main advantages despite the community-based evolution of open source is the learning aspects for all parties involved. This leads to mature and well-tested software. We are encouraging everyone to submit code extension or feature requests, but want to especially highlight that we always welcome new contributors. And last but not least …keep hacking!

How to send a test message from RWB in PI 7.3 EHP1

Introduction

This document is focused to give a better understanding on testing the interface by sending the message from Run-Time workbench (RWB).As we all know that, we can test the interface by sending test message from RWB. From PI 7.3 the RWB has changed rapidly and it is having many advanced features.Even though this is known to every one, it may helpful for those who recently upgrade to PI 7.3.

In SAP PI 7.3 we have a central tool for overview monitoring the Integration Scenarios in our landscape which is SAP Solution Manger. With these features we can review the information about the processes or Messages.Run-time Workbench (RWB) can be used as a quick test tool for sending the payload directly to integration engine or Adapter engine.

Prerequisites: User should have this role " SAP_XI_RWB_SERV_USER_MAIN "

Step 1: Go to PI Home page and click on configuration and monitoring Home which is available under configuration and monitoring.

Step 2:  you will get the below screen. Here you will find the three tabs.

  Monitoring 2) Configuration and Administration  3) Testing.

Step 3: Go to testing tab and click on send test message option under testing.

Step 4: you will get the below screen, here we have two options under integration server

  Integration engine and Adapter engine.

Step 5: Click on integration engine you will find the below screen

Fill the details like sender component/interface and interface Namespace/ user name and password and quality of service like below.

Step 6: Paste the payload from Message Mapping.

Click on send message.

You will get the pop-up message “Message Sent” like in the above screen.

Step 7: Your message will send to integration engine. You can check the message either in Message monitoring and SXMB_MONI.

You can see the Payload which we sent from RWB in pipeline steps.

Go to inbound/outbound message payload.

It is the same payload which we copied from Message mapping in step 6.

In this way you can send the message from RWB to test the interface.

Regards

Bhargava krishna

The motivation of the blog is a conversation I had with couple of friends. They had implemented a new SAP functionality but were hassled by the amount of effort spent in integration. They eventually completed the task but after lots of crazy hours on late nights and sometimes weekends. As both the integration as well as the functional person is a friend and didn't know about using enterprise services, I realised that perhaps not everyone is using enterprise services. Further, I was designing and implementing a solution to integrate SAP ECC with an external application for managing distributors and thought to write this post.  Our integration required sending master data from SAP and transactional data updates in SAP ECC in OTC / P2P process area triggered from the external application.

Starting with the basics, look at the definition from SAP from BBA guide.

Enterprise Services: Web services using a common enterprise data model based on process components, business objects, and global data types, and following consistent communication patterns. SAP exposes software functionality as enterprise services.

There's good documentation at http://esworkplace.sap.com/ .

In integration world, I see them as equivalent of classes in application development. If you're able to use pre-existing content, most of the work is already done for you.

Why to go for enterprise services instead of trying to build them from scratch - what are the practical benefits?

-  Leverages pre-built solutions reducing in substantial development effort reductions.  We were able to reduce development effort to around 60% of initial estimates and even this is high because of the first time efforts in understanding their architecture and doing some prototyping.

- Easy to extend: Any project will require customization not delivered by standard solution and normally making changes later on is very time-consuming. Most of the functionality is already covered and even if additional changes are required - SAP has given a nice framework to customize them first in PI and then carry out adjustments on SAP system in ABAP stack.

- Comes with a lot of bells and whistles: Have error handling, data validation pre-built.

The following points need to be considered though:

- We utilised various software component versions and there were two mechanisms to get them installed in our landscape.

a) Some require installation of an add-on in ECC requiring BASIS effort (e.g. ECC-SE add-on to be installed by BASIS).

b) Others require activation of irreversible business functions (e.g. ESOA_OPS01 for services in SAP APPL). It's important to understand that some of the business functions can't be reversed and hence some amount of regression testing of affected areas need to be performed. SAP provides a test catalogue about the impacted functionality which can help in determining the impact. We tried them first in sandbox. Initially the activation didn't go smoothly resulting in ABAP dumps which go away on activation. However, it's painful as you have to wait for a transaction to dump before activating it. After an OSS message, finally we regenerated all programs of EA-APPL, ECC-SE and SAP_APPL software components.

At a very broad level, there are 5 different activities that need to be done.

i ) Identify which services meet requirements completely ( or to the largest possible extent ). There can be more than one service for a given business function ( e.g SalesOrderERPCreateRequestConfirmation_In_V1 and SalesOrderERPCreateRequestConfirmation_In_V2 for sales order creation ). I noticed two things: The former wasn't able to meet all our requirements and has been deprecated as well.  Like any other artefact in software engineering it's best to avoid deprecated services.

ii) PI configuration: This was straight forward in our case as it was simple SOAP to proxy and reverse.

            iii) Back end ABAP adjustments: These were made to fill in organizational data as the third party system doesn't have concept of some of the                 organisational structure, data etc.

iv) BASIS activities: Installation of add-ons (e.g. ECC-SE add on via SAINT), regeneration of affected ABAP programs via SGEN.

v) Co-ordination of regression testing: This may involve change management, regression testing and functional owner of the application / process area.

Some of the points we learnt from experience:

- Be ready to spend time in advance of the actual development in prototyping and investigation. However, it pays back in later stages of projects.

- We had to build application logging on ECC side so that in case of errors a functional person knows what to look for.

- There was one instance where we had to overwrite SAP solution. Fortunately, it can always be over-written as a post-exit method in the implementing ABAP class.

- Update some of the system parameters ( e.g. icm/keep_alive_timeout parameter in downstream PI systems). While transporting ESR contents, we realised that the transport import was failing after 5 minutes. These ESR transports with stnadard SAP content can get really big and it's best to send them in separate transports (for each SWCV) . Our first attempt in trying to import them took 22 minutes in total!

In part2, I'll describe the steps in more detail to make the implementation process clearer but from our experience, SOA is definitely not dead!

Link to part 2 : http://scn.sap.com/community/pi-and-soa-middleware/blog/2013/06/04/reducing-integration-effort-by-leveraging-sap-enterprise-services-part2

Recently one of our customers asked me about PI capability of handling PDFs. This discussion really got interesting when we started scoping requirement. Just handling PDFs turned out like PI will receive multiple images as base64 encoded string in payload. PI will merge these image file, convert it into PDF and then long list of DOs and Don’ts ultimately send base64 encoded pdf file to 3^rd party application.

My experience with PDF till that point of time was restricted to moving pdf files from one folder to another using AAE so I thought of creating POC first to see what can be achieved through PI.

I started to look out for Ideas at SDN forum and found some of my ex-colleagues (not one ) have implemented some sort of complex PDF handling in PI. Key take away for me here was iText.

iText is a very powerful open source library. Using it’s APIs we can work with PDFs/images in more way than I can count. This library exactly fitted requirement for my poc.

At SDN forum most of the suggestions are to create adapter module or JAVA mapping. Java programming is not best of my traits and I find it easy to work with UDF. Anyway I don’t have to create actual PDF file at source but to send it as base64 encoded string so UDF is best suited for this.

Scope: - PI will receive base64 encoded image as a string in payload. PI will merge these images and create a base64 encoded PDF. PI will put the base64 encoded PDF into a field in target payload which in turn will create xml file at target FTP.

Algorithm: - here I am explaining the basic algorithm.

1. Read base64 encoded string from payload
2. For each encode image:
   1. Decode the image
   2. Convert the image to PDF
   3. Add pdf to existing one.
3. Convert PDF to base64 encoding
4. Return string to payload.

Implementation:-

For this implementation itext jar “itextpdf-5.4.1.jar” has been used.

Import instructions:-

import com.itextpdf.text.Document;

import com.itextpdf.text.pdf.codec.Base64;

import com.itextpdf.text.*;

import com.itextpdf.text.Image;

import com.itextpdf.text.pdf.PdfWriter;

This is advanced UDF for type queue having one input of type string.  I have segregated the UDF code in multiple part for better understanding. I have also included the full version of UDF in last part of blog.

Part 1:Declarations:-

String merge = null; // store base64 encoded merged PDF document
Document pdfDoc = new Document();  //  Constructs a new Document with A4 page size
ByteArrayOutputStream output = new ByteArrayOutputStream(); // store pdf in byte array
PdfWriter writer = null;  // Constructs a PdfWriter
Image img = null;   // Constructs a PdfWriter

Part 2:Processing each encoded node:-

for(int i =0; i<encodedImgStr.length; i++)
{
.
// Code for merging images and creating PDF as described in part 3 and 4
.
}

Part 3:Decode the encoded image and read it into bytes:

String imgStr = encodedImgStr[i];
byte[] imgBytes = Base64.decode(imgStr);

Part 4:Convert images to PDF and merge:-

try{
             // get an instance of an image
                img = Image.getInstance(imgBytes); 
            // get the plain height of the image
               float imgHeight = img.getPlainHeight() + 100;  
              // get the plain height of the image
                 float imgWidth = img.getPlainWidth() + 100;  
              // create the page for the document
               Rectangle pageSize = new Rectangle(imgWidth, imgHeight); 
               // set the page size of the pdf
                 pdfDoc.setPageSize(pageSize);
   /* below code is executed only once. When first image is processed*/
                if(i ==0)
                {
   /*below method gets an instance of PdfWriter “writer”. pdfDoc  is the document that has to be written and output is the OutputStream the writer has to write which in this case is ByteArrayOutputStream. */
                      writer = PdfWriter.getInstance(pdfDoc, output);
                    writer.open();
 pdfDoc.open();
                }

// Below method convert image to PDF. At each loop image is converted to pdf and new page is appended.
pdfDoc.add(img);

       }
 catch (Exception e) {
 }

Part 5:Close Document and Writer:-

// once document is written to output stream close the document and writer
pdfDoc.close();
 writer.close();

Part 6:Convert output stream to byte:

// Create a new byte array pdfBytes and copy valid content of output stream output to pdfBytes.
byte [] pdfBytes = output.toByteArray ();

Part 7:Encode bytes to base64 encoding:-

// encode PDF bytes to base64.
merge = Base64.encodeBytes(pdfBytes);
// Add merged base64 encoded pdf to resultlist.
 result.addValue(merge);

Below is the input message. Field “fileData” contains encoded images. For this POC I am not actually using “FileType”. I am using SOAP UI to test my interface.

I have used the same structure for output as well. Below is the output message.

I have written small code in NWDS using iText library to decode base64 string and create a PDF file.

Sample Code:-

import com.itextpdf.text.pdf.codec.*;

public class decodePDF {

            public static void main(String[] args) {

            // TODO Auto-generated method stub

               String file1 = "C:/Documents and Settings/Desktop/iText/PIencoded.txt";

               String file2 = "C:/Documents and Settings/Desktop/iText/PIadapter encoded2.pdf";

                Base64.decodeFileToFile(file1,file2);

      }

}

Full version of UDF mergeDoc UDF.

String merge = null;

Document pdfDoc = new Document();

ByteArrayOutputStream output = new ByteArrayOutputStream();

PdfWriter writer = null;

Image img = null;


        for(int i =0; i<encodedImgStr.length; i++)

     {
        String imgStr = encodedImgStr[i];

        byte[] imgBytes = Base64.decode(imgStr);

         try{

            img = Image.getInstance(imgBytes);

            float imgHeight = img.getPlainHeight() + 100;  
                  float imgWidth = img.getPlainWidth() + 100;  

                Rectangle pageSize = new Rectangle(imgWidth, imgHeight); 
                pdfDoc.setPageSize(pageSize);

            if(i ==0)

            {

               writer = PdfWriter.getInstance(pdfDoc, output);

               writer.open();

                           pdfDoc.open();

                        }


                        pdfDoc.add(img);

                     }

                  catch (Exception e) {
                }


          }


 pdfDoc.close();


writer.close(); 


byte [] pdfBytes = output.toByteArray ();

merge = Base64.encodeBytes(pdfBytes);

result.addValue(merge);

We can use iText library to achieve functionality like encryption, removing malicious codes, modify metadata etc. I am still exploring it and hope to find many interesting features we can use.

An empty custom key storage view named AN is created as displayed below.

5 To create the keypair, click on the Create button as highlighted below.

6 Add a new key storage entry to the view as follows:

1 In the Entry Name field, enter AribaKeypair. Retain the default values for the remaining fields.

2 Under Subject Properties, enter values as displayed below. Make sure that the common Name field (CN) value highlighted in red circle refers to a fully qualified DNS domain name of a web server.

3 Click Next in step 3.

4. review the information under Subject Properties and click on Finish button.

7 Select the AribaKeypair in the Key Storage View Details and click on Generate CSR Request button.

1 To download the AribaKeypair.pem CSR file, click on Download link as highlighted below.

2 Open the AribaKeypair.pem in a text editor. It appears as follows.

Then the generated CSR must be signed by one of the trusted CAs supported by Ariba Network

List of Trusted Certificate Authorities given below:

When you purchase a sign digital certificate, it must refer to an organization that is

trusted by Ariba Network. The trusted certificate authorities are :

ABAecom

AddTrust

American Express

ANX Network

BelSign

Belgacom

Digital Signature Trust Co.

Equifax

GlobalSign

GoDaddy

Thawte

TrustCenter

VeriSign

Then CSR response, which is the public certificate received from the trusted CA, must be imported into the custom SAP NetWeaver PI Key storage view. Import the CSR response in to the Key storage as follows:

1 Click on Import CSR Response button.

After that same public certificate must also be applied in the AN Buyer account. Configuration details of Ariba Network adapter is attached below.

Recently, I was involved in a project with the goal of splitting app server and dB to split them on different hosts. If app and dB server are on the same host, there's no confusion as there's only a single host. However, if in case of dB and app server split, dB host should be taken for technical systems.

We got following errors after app/dB split.

- Error with cache notification.

- Adapter engine not found.

- Business system not found on execution of LCR_GET_OWN_BUSINESS_SYSTEM.

We had to do the following steps in the below order to get it working:

1. Recreate SAP technical systems

a) Delete existing technical systems for SAP systems.

b) Regenerate these technical systems (RZ70).

2.Regenerate PI business system and technical systems of type "Process Integration"

a)Delete all technical systems of type 'Process Integration'.

b) Delete PI business system

c) Execute PI self registration:

In  SAP Net Weaver Administrator:

Configuration Management --> Scenarios --> Configuration Wizard : All Configuration Tasks --> PI SLD Self Registration

This step:

                i) Regenerates technical systems of type 'Process Integration'

                ii) Recreates PI business system. If PI business system is not deleted in 2 b), this step will fail. If you want to use a different name, it should be done                     after all steps are complete.

3.Restart integration builder / integration repository / RWB and AE.

Net weaver Administrator:

SAP Netweaver Administrator --> Operation

Management --> Systems --> Start&Stop --> Java EE Applications

1. com.sap.aii.af.app (Adapter Engine)
2. com.sap.xi.directory (Integration Builder/Configuration)
3. com.sap.xi.repository (Integration Builder/Design)
4. com.sap.xi.rwb (Runtime Workbench)

4.Adjust all SAP business systems to use the new technical system. The technical systems should appear as below.

Hopefully it can save someone some time in trying to work these out.