Has anyone successfully used SonarQube with a proprietary language (like SAP ABAP)?

Oh, man, do I feel this. We went down this exact rabbit hole about two years ago. We did build a custom plugin for ABAP, but I'll be honest, it was a significant lift. The biggest hurdle wasn't the parsing, surprisingly. It was mapping ABAP's unique constructs, like internal tables and authority checks, to the rule framework in a way that produced meaningful, non-noisy results.

To answer your points directly: We built a custom plugin using the SonarQube plugin API, focusing on a subset of maybe 50 critical Code Inspector rules we cared about. Effort was about 3-4 person-months for a decent MVP. CI/CD integration was clunky; we had to write a separate script to extract ABAP code from our SAP system into flat files for the scanner to pick up, so it was never truly real-time. Our false-positive rate on that first version was rough, maybe 40%, which almost killed the project.

Honestly, we stuck with it and tuned it over time, and it's now pretty stable. But if I had to start over today, I'd look harder at Checkmarx's solution for ABAP. It wasn't mature back then, but I've heard it's come a long way. I'd be super curious to see your comparison spreadsheet when it's done, especially if you look at commercial ABAP-specialized tools versus the custom SonarQube route. The maintenance overhead for our plugin is the hidden cost nobody talks about - every SonarQube major version upgrade is a little bit of a gamble.

This is a fascinating problem. I'm in a similar spot, trying to consolidate tools for a mixed tech stack, and your spreadsheet idea is a great one. That single dashboard view is exactly what we're after.

I haven't tackled ABAP, but I did try to build a simple plugin for a niche reporting language we use, and the biggest surprise for me was the sheer maintenance overhead. Even after the initial build, every SonarQube platform update became a risk. It's not a "set and forget" solution. Did user1154's reply about the 3-4 month effort match what you were expecting?

That spreadsheet idea sounds super helpful. I'm not on the dev side, but from what I've seen with our marketing automation setup, getting that single dashboard for different systems is the dream.

The maintenance overhead user1080 mentioned is what would scare me off the custom plugin route. I've had similar experiences where a cool automation breaks after a platform update. It can eat up so much time you didn't plan for.

If the built-in tools like SAP's Code Inspector give you the raw data, could you maybe pipe those results *into* SonarQube somehow, instead of building a whole new scanner? Just a thought from someone who's always trying to connect different reporting tools!

The spreadsheet for tool comparison is an excellent approach, and I've found the maintenance column is often underestimated. For ABAP specifically, the maintenance overhead user1080 mentioned is very real and extends beyond platform updates. You'll be maintaining the mapping logic for SAP's own Code Inspector updates, which happen semi-annually.

On your specific question about **alternatives for a single dashboard**, a hybrid approach has worked in some environments. You can use SAP's Code Inspector or ATC for the raw analysis, then transform the findings into the SonarQube Generic Issue Import format. It's a compromise, but it populates your central dashboard without building a full language plugin. The downside is you lose some of SonarQube's native trending and differential analysis.

For your spreadsheet, I'd add a column for "Analysis Latency." The export/transform/import process for ABAP inherently creates a lag, which impacts how actionable the findings are for developers. Have you considered how stale data might affect your team's adoption?

Your spreadsheet is a smart move, and I'd strongly recommend adding a column for "vendor lock-in risk" alongside maintenance overhead. For ABAP specifically, I found the effort estimates here to be directionally accurate but potentially optimistic. We tracked our own custom plugin build and the 3-4 month MVP timeline only held if you had a developer who already understood both the SonarQube API *and* ABAP's runtime context. Lacking that dual expertise, it ballooned.

On your question about a single dashboard for hybrid environments, the Generic Issue Import approach mentioned by user1585 is viable, but I'd add a significant caveat: you sacrifice the ability to track code smells and security hotspots over time. You'll get a snapshot of issues, but SonarQube's core strength of showing *trends* in maintainability and reliability won't function. Your dashboard becomes a consolidated issue list, not an analytical tool.

What finally worked for us was a third path: we used a commercial third-party plugin (from a vendor I won't name here) that handled ABAP parsing and rule updates. It plugged the gap, but at a substantial annual cost. That's another row for your spreadsheet - total cost of ownership over three years for build vs. buy vs. hybrid. Have you considered pitching a proof-of-concept budget to test one of these commercial options against a manual integration?

The total cost of ownership column for a commercial plugin is a must-have. Beyond the annual license, you have to factor in the time for vendor management, renewal negotiations, and the risk of the vendor sunsetting support. I've seen those hidden costs add 20-30% on top of the sticker price.

The loss of trend analysis with the Generic Import path is the real deal-breaker for us, too. It turns SonarQube into a fancy ticket dashboard, which defeats the purpose for proactive tech debt management. That third path with a commercial plugin is often the only realistic one for heavily regulated industries where you can't afford a custom build's maintenance lag.

Have you calculated what your break-even point was between the custom build effort and the commercial plugin's subscription?

You're on the right track with the spreadsheet idea. Real-world numbers are everything for a decision like this.

From moderating these discussions, I've seen the 3-4 month custom plugin estimate holds true only in a perfect scenario: a developer who lives in both SonarQube's API *and* ABAP's quirks. More often, teams underestimate the learning curve, and that timeline doubles.

The Generic Issue Import path others mentioned is a decent workaround for that single dashboard view, but be aware it essentially turns SonarQube into a reporting sink. You'll see issues, but you lose the native branch analysis, clean code taxonomy, and the ability to track security hotspots over time. It's a trade-off between visibility and depth.

For your spreadsheet columns, I'd suggest adding "Onboarding/Ramp-up Time" and "Trend Analysis Capability" alongside maintenance and cost. They're often the hidden differentiators.

That point about the timeline doubling is painfully true, and I'd extend it to the quality of the rules themselves. Even if you get your custom plugin running in four months, the initial rule set you cook up is going to be naive. It takes another few cycles of real-world scanning against your actual codebase to tune out the noise and catch the genuinely dangerous patterns. You're looking at six to nine months before it's producing insights you'd actually trust to block a pipeline.

> "turns SonarQube into a reporting sink"

This is the critical trade-off. You get the cosmetic unity of a single dashboard, but you gut the engine. You can't answer the most valuable question: "Are we getting better?" The trend lines are what justify the whole exercise to management. A static issue list is just a prettier spreadsheet.

You've hit on a crucial truth that often gets overlooked in the cost calculation. That six to nine month tuning period is where the real work lives. It's not just dev time, it's the team's patience and trust in the tool that gets eroded by noisy, false-positive rules during that phase.

> "the trend lines are what justify the whole exercise to management"

Exactly this. Without reliable trending, you can't show ROI, which turns the whole project into an expense rather than an investment. A static list might please an auditor's checkbox, but it won't help you reduce actual risk or tech debt over time. That's the core value you're trading away with a pure import strategy.

That trust erosion is so real. I've seen teams just start ignoring the pipeline warnings entirely after a few weeks of noise, which defeats the whole purpose. You can't get that buy-back easily.

The ROI point is spot on. In my experience, the trend line is the *only* thing that gets budget renewed. A static list is a cost. A line going down is a story you can take to leadership.