Manuel Almagro Rivas.

Manuel Almagro Rivas.

Physicist & systems integration developer. Based in Granada (Spain). Interested in data science, languages and literature.

Automatic AS-IS reports in SAP Integration Suite.

3 minute read

Published:

When you work with SAP Integration Suite, you quickly realize that the hard part isn’t always building new interfaces. It’s understanding what’s already there. Over time, integration packages pile up, documentation gets stale, and nobody really knows the real, up-to-date state of the integration landscape.

I wanted a way to explore an existing landscape quickly, to generate a simple “as-is” report without manually opening each IFlow, which is a tedious, repetitive task. That’s how this little tool came to exist.

Screenshot

I decided to package it as a webtool. It takes a set of integration packages download as ZIPs, extracts their contents, analyses each flow, and produces a CSV report with each row listing the full details of each adapter: endpoints, protocols, parametrisations, internal dependences, etc.

This way, one gets a structured overview of what’s running in each tenant, without having to click through dozens of artifacts. The outline of how this is done, and some more technical details, can be found in this GitHub repo.

How it works

The app is written in Python, wrapped in Streamlit, and runs fine in a Docker container.
At a high level, it does this:

  1. You upload one or more integration package ZIPs.
  2. It unpacks them and finds all .iflw files.
  3. For each flow, it extracts:
    • Adapter type and direction (sender or receiver)
    • Transport protocol
    • Endpoint address (and whether it’s parameterized)
  4. It also checks for internal dependencies between flows — when one IFlow calls another.
  5. Everything ends up in a CSV file that you can download and open in Excel.

That’s it. No database, no config files, no setup. Just upload, wait a few seconds, and you get your report.

Internal calls and parameters

Integration flows often call each other using connectors known as ProcessDirect, which avoid performing an HTTP call over the internet just to end up in the same machine. The script maps these links, so the final CSV shows both “CallsIflow” and “IsCalledByIflow” columns. This proves especially valuable when adjusting the log level of several iFlows to Trace, since knowing the potential downstream effects of a single HTTP call allows the task to be completed much more efficiently.

The tool also checks whether adapter addresses are hardcoded or parameterized using the `` pattern. If a default value exists in parameters.prop, it’s used in the output and the script marks the entry as parameterized. Knowing if an integration holds parametrized values is useful because these are bound to change between environments.

Output

The generated CSV includes:

  • UID, Package, Iflow, IflowID, IflowVersion
  • AdapterType, TransportProtocol, AdapterDirection, AdapterAddress
  • IsParametrized
  • CallsIflow, IsCalledByIflow

It’s enough to build a picture of how your tenant is wired: which flows talk to which, and where each adapter points to.

Why this exists

I built this mostly because I got tired of doing repetitive “landscape discovery” tasks.
People keep asking for an updated list of endpoints, or which IFlows are calling which others, and you end up manually opening a lot of integration flows and clicking through the UI.

This script automates that. It it covers most cases, works fine in both Neo and Cloud Foundry-based subaccounts, and it’s easy to extend if you want to include other adapters or metadata.

If you want to try it, everything’s on GitHub.

You May Also Enjoy

Where is that plane going? A shortcut for plane-spotters

5 minute read

Published:

A friend of mine has a curious habit: whenever she sees a plane in the sky, she immediately checks Flightradar24 to find out where it’s headed and where it came from. It turns out (perhaps unsurprisingly for those in the industry) all sorts of things happen in the sky. There are hot-air balloons for tourists, law enforcement aircraft, pilots in training, commercial flights, military planes… and somehow, all of them are tracked on Flightradar24.

On using wrong tools

5 minute read

Published:

About two years ago I bought an AirTag. I usually go days without driving, so I end up not being sure about where my car is parked. The AirTag is a simple solution for this: I left it in my glovebox and now I can check my car’s location, almost live, in my phone.

Some useful customizations for macOS.

4 minute read

Published:

I started using a Mac back in 2018. My computer, an fairly standard HP laptop I’d bought back in 2013, was beginning to become a source of troubles. The charger wouldn’t charge, the keyboard wouldn’t hold the keys in place, and generally the computer wouldn’t compute. This was a problem, given that I was a destitute student. To my surprise, older MacBooks (the white poylycarbonate MacBooks made back in 2010) where dirt cheap, even when bought from overseas and thus with shipping and custom costs included in the price. I bought one for about 130€. It lacked the Euro (€) key and I couldn’t type words containing an ñ directly, but it felt like a small inconvenience and I quickly found workarounds. That little laptop proved hardy and powerful enough for my daily tasks, and it carried me through a computational physics course during which the rubber in the bottom peeled due to the excessive heat emanating from its dying processor. It was a pretty nice machine.

PAULA: Protein Analysis Using a Least-squares Approach

4 minute read

Published:

Last year, I took a physical chemistry class which had to do with the behaviour and analysis of biomolecules (mainly proteins and nucleic acids). It was fun to step outside of my comfort zone and being in a chemistry lab again, and I had a great deal of fun learning about bio-stuff again. The course worked by alternating theory classes (where we learned the formal aspects of the techniques we would later apply) and lab sessions. We were given a small sample of the problem molecule which we wanted to characterise over a period of two-or-so months, which in this case was hen egg-white lysozyme, a cheap and common protein. One goal was to pass polarised ultraviolet light through a sample of this protein, and measure how well the protein is able to twist the plane of the incident light rays. This technique is called far-ultraviolet circular dychroism, and it turns out that learning about the way a protein interacts with these particular wavelengths in this very particular sense yields a great deal of information about its structure!