Decommission Interfaces in PI

[prateek]

This blog is the result of thought process behind this thread posted recently. Although many of you might have seen some documented or undocumented process at your respective organizations, I believe there are still many clients who do not have any process in place. The blog is about the process of Decommissioning or removing the interfaces from PI landscape. This may appear easy, however, if you just start thinking about it, it can be a huge job.

A few years back, I wrote about "How clean is your Integration Directory?". It talked about keeping the Integration Directory clean. This blog is about entire PI answering the question "How".

What do we usually do?

There could be numerous reasons why you need to decommission an interface in PI. I have captured some of the reasons here however, there could be a whole bunch of other reasons. So once we decide that the interface should not be used for production flows, here are the simple steps which are normally being followed:

1. We deactivate the sender (where applicable) and receiver channels in Integration Directory and/or
2. We stop the channels in Communication Channel Monitoring and/or
3. Delete the related ESR and ID objects.

I recommend always doing both point 1 and 2 at the same time because then you have option to navigate and select all the inactive channels in Communication Channel Monitoring and rest assure that the channel is inactive.

Now the problem with point 3 is it is not always easy to implement. It depends a lot on the Release Management strategy of your organization. If your organization is very stringent about the transport processes in PI, you may end up waiting forever to get a delete related transport request to PI production environment. And it is not only about transports, it is also about the configurations you perform directly in production. If you can convince your Release Manager (or you can skip him), then go ahead with reading rest of the blog. :smile:

When you develop a scenario, you first design it (ESR) and then configure it (ID). However, when you go for decommission, remove configuration (ID) first and then the design (ESR) objects. This will avoid any inconsistencies in the landscape.

Improving the Decommissioning Process

If the release management process supports you, you have to start thinking what all objects or configurations associated with your interface should be removed. First, understand the current process completely. Then, start the improvement path.

1. Start with basics. Open the Technical Specification (also called as Technical Design) for the interface and check what the interface does. This will at least give you basic idea of what you are dealing with.
2. Create a template for decommissioned interfaces including all the details around it. The template should be based on the various types of objects or configuration associated with the interface. The list can be found in coming section.
3. Create a checklist based on the template to ensure that all the related objects are removed. It is important to note the order in which you delete the objects. I haven't personally tried all combinations of deleting sequences, however I believe it is good to be as logical as possible
4. Talk to architects about the possibility to reuse of the interface functionality in future. If they totally agree for removal, go for it.
5. Use Solution Manager to track and maintain documents. If this is not possible, even excel would do.

Finally, the list of objects!

To fill the above created template and checklist with different objects that may be hidden across your PI implementation, you have to ask the below questions and proceed with the deletion. For each point, make sure that the object to be deleted is not reused anywhere.

General

1. Have you configured any message or queue prioritization in ABAP and Java stack?
2. Do you have any alert setup specifically for that interface?
3. Were there any Archiving setting done specifically for that interface?
4. Were there any associated users in ECC or PI related to the development?
5. Was there any custom ABAP development in ECC or PI?
6. Do you have to remove any certificates installed on Java or ABAP engine?
7. For IDoc scenario, do you need to remove idoc metadata?

ID

1. Was any value mapping done for this interface
2. What type of channel is associated with the interface? You have to delete the objects specific to channels. e.g. For an ABAP proxy channel, you have to delete the related RFC destination.
3. Is the interface using RFC/JDBC/SOAP lookup? If yes, you have to delete the associated channel in ID.
4. Was this interface using custom built adapter module? (It would be better to keep the module anyway).
5. Are there any Business Components or Business systems which can be removed.
6. Once these things are cleared up, remove/edit the basic configuration objects like agreements, receiver determination using transports.

ESR

1. Are there any imported RFCs or Idocs that should be removed (e.g. deprecated versions)?
2. Were there any objects imported under External Definitions?
3. Were there any UDF in mappings which can be copied in a Function Library and kept for future?
4. Were there some imported archives (java/xslt mapping, java functions)?
5. Is there an associated Integration Scenario?
6. Do I have any mappings related to Enhanced Receiver Determinations?
7. Was it a ccBPM scenario? If yes, remove the BPM as well as all related objects in one go.

SLD

1. Are there any products of Software Components that can be removed.
2. Are there any Business or Technical systems that can be removed.

It is better to remove everything related to ESR in one single transport. I have tried to keep this list in the logical order in which I believe they should be deleted.

Conclusion:

I like to "keep it clean" and therefore like to spend some time on this topic. I know and understand that there could be several objects not listed here. The aim here is to throw some lights on the different areas in PI which may be impacted by this single interface. Enjoy cleaning! :smile:

What are your experiences with the end-of-life of interfaces?