Why use SAP logging instead of log4j?

[Former Member]

Hello,

We're porting our J2EE apps from IBM's WebSphere. Most of our apps are using log4j for logging.

I'm trying to figure out what advantages, if any, there are to converting to SAP's logging? It seems like an awful lot of work and I don't want to do it unless there are good reason(s) to.

Any feedback would be appreciated.

Thanks!

[Former Member · Accepted solution]

Hi,

By using sap's logging api , I am aware of some impoortant advantages.Hight controllability such as

1. can assign/change severity at any later stage ,externally,without changing the code.

2 . can assign/reassign the log location externally.

Please view the below link. See the details on clicking the "sap logging api" on this page and also see the advantages

http://help.sap.com/saphelp_nw2004s/helpdata/en/de/eda841c1dadb34e10000000a1550b0/frameset.htm

Also view the "Enabling logging api" provided as link in the bottom of the second page.

Hope this should help.

Regards,

Harish

(Please award points for helpful answers)

[Former Member · Accepted solution]

Harish,

I should have mentioned in my original post that I've done some research on this. I've read the article you're pointing me to.

Still, I just don't see any advantage to switching to SAP's logging. The two advantages you describe are there in log4j also.

Thanks!

[former_member302950 · Accepted solution]

Hi, David,

one of the main reasons why the SAP Logging API was introduced is that both Logging and Tracing (despite the name of the API) are supported specifically. Most logging APIs, among them log4j, are actually more tracing APIs, for example they often do not support translation of messages, which is a must for real logs in standard software. The JDK logging API does but wasn't existing when the SAP Logging API was developed. Now, SAP provides a wrapper implementing the JDK logging API. But of course, your problem is that your code uses log4j not the JDK version.

Another advantage of the SAP Logging API is that it writes into standard files defined by SAP, so if you want your messages to be found at common places, it is the way to go.

Other features, that come in handy during everyday development work include the switching on and off of message writing by (hierarchical) keywords which provide an additional level of fine grain controlability.

Hope this helps, and feel free to ask further questions.

Best regards

Heiko

[Former Member · Accepted solution]

Heiko,

Thanks for your reply.

I'm not quite sure what you mean by "support translation of messages"

Can you elaborate?

Thanks!

[former_member302950 · Accepted solution]

Hi, David,

sure: instead of writing the text of the message itself into the log file, you instead, or in addition, store a resource key and bundle. Only when the message is displayed in a log viewer the key is used to find the translated text in the bundle and view that, according to the login language of the user and including argument substitution (for example a file name or whatever). Whereas traces are primarly addressing developers for means of bug fixing and are usually written in English, logs show more or less critical system or application events and most customers want them to be shown in their native language, or that of their administrators.

In order to store resource keys and bundles in the log file, you of course have to provide the corresponding calls in the API, and that's exactly what the SAP Logging API does.

Cheers

Heiko

[Former Member · Accepted solution]

Thanks for the info Heiko!

[Former Member]

Marking my old 'unanswered' posts as answered.

This was a big issue during our conversion from WebSphere to Netweaver. The Basis team insisted that we should use SAP's logging but we couldn't see enough advantages to justify the work involved to change our existing apps.

We also investigated the bridging of log4j to SAP's logging but, again, we couldn't find enough advantages to justify it.

We use common code that automatically creates all the logs in a specific location so one of the big advantages of SAP was something we already had.

Another thing that was touted as an advantage of SAP's logging was the translating. Since we are a US firm and will probably never be a global firm we don't need that.

Lastly, one of the big disadvantages we saw of SAP's logging was that everything went to one file.

What we liked about log4j was that our common code would automatically create a separate log file for each application. That way, the developer who supports app A doesn't have to wade through tons and tons of logging by other apps just to find his app's log information.

[Former Member]

Hi David,

yes, generally converting any 3rd party logging framework to SAP's one would mean lots of effort, and I doubt there's any advantage that could really pay for this effort. Therefore, it seems to me most logical to try to bridge the 3rd party framework to SAP's one. That's the topic that is addresses in this article: <a href="https://www.sdn.sap.comhttp://www.sdn.sap.comhttp://www.sdn.sap.com/irj/servlet/prt/portal/prtroot/docs/library/uuid/36085e78-0801-0010-678d-8b4e89ddff3c">Integrating 3rd Party Logging Frameworks into SAP NetWeaver</a>. Might want to have a look at it.

[Former Member]

Hey Ivaylo,

I should have mentioned in my original post that I'd already read that article.

From what I'm seeing in that article all I"m doing is "bridging" the log4j features into SAP's logging.

Granted, making the change in the log4j.properties file simplifies the changes required but I still don't see the benefit.

Everything I've read makes me believe that SAP has just "reinvented the wheel" with their own logging.

As someone who came to SAP-world lately and didn't graduate from the ABAP side I constantly keep finding situations where SAP seems to have done this type of thing.

Instead of using industry-standard methods/processes, they've developed their own. In some cases I can understand why but in this case I'm struggling to identify the advantages to switching my apps to SAP's logging.

Thanks!