Skip to Content

Lately, I had received a requirement to add an hyperlink in the object documentation of transaction and reports. By clicking on this link, system should be able to redirect and open document stored on solution manager system or on share-point.

In this blog, I would like to share the possible solutions that could be used to achieve the desired result.

Requirement :

User will click on “Click here to open SAP.com” and system will open https://www.sap.com in new session of the browser.

In the same way, the requirement is to provide an hyperlink to open documents stored on customers network, on share-point or on solution manager system ( link can be generated for document stored on solution manager system ).

Possible Solutions:

Option 1: To use the URLA option provided by SAP.

Shortcomings:

With this solution we face a constrain for the length i.e numbers of characters that can be passed in the hyperlink. As the tag for DS cannot be extended to new line, we are left with only 72 characters in which we have to provide TAG and URL.This option is ruled out as URL for documents stored on internal network can be very lengthy.

Option 2: Transaction link.

Provide the transaction and link the transaction to the report which will have the following code

Shortcoming:

The limitation with this approach is to create a new tcode for every hyper-link that
we want to provide in the documentation.

Option 3: Create Custom Document class and FM’s for the document class.

Step 1) Create a table entry in table TDCLD. This table contains document class

Table: TDCLD is the master table for Document class with maintenance allowed. However there is no table maintenance generator for the same. Also there is no tcode/report available to maintain data for this table. Hence you will have to maintain this table via SE16 or SE16N. Best would be to copy URLA table entry and give your own denomination for the respected value. In our example document class is ZRJK.

Step 2) Coping standard FM’s.

Copy FM’s URLA_OBJECT_SHOW and URLA_OBJECT_TITLE with first 4 characters should be the document class. In our example, ZRJK_OBJECT_SHOW and ZRJK_OBJECT_TITLE.

Step 3) Pass values from documentation to the FM.
DOKNAME will contain the value passed to the FM.

String after “ZRJK.” contains document name which will be passed to FM. In our example we are passing LOIO number for documents stored on solution manager system.

Step 4) Build the URL in FM and call the link in browser.

Keep the FM for TITLE with empty body. In our example ZRJK_OBJECT_TITLE is copied from URLA_OBJECT_TITLE but with empty body. Since with the last option we get control in FM where dokname contains the document name passed through documentation, we can build many solutions depending on the requirement.

Also please refer to the following articles for more input on the same:

https://blogs.sap.com/2014/05/29/tip-n-6-how-to-add-hyperlink-inside-message-long-text/
https://archive.sap.com/discussions/message/16044394#16044394
http://zevolving.com/2015/07/abap-overcome-limitation-of-long-text-links-handling-using-custom-class/

The above URL’s provide another approach to add an hyperlink in object documentation which is an object oriented approach. To use this approach we have to create our own custom class which inherits class: CL_EPSS_SAPEVENT and then implement method: RESOLVE_LINK. Also we will have to maintain class details in table: EPSSA2.

Both the approaches ( object oriented approach and approach that uses FM ) can be used and are best possible option to provide solution for given requirement.

However with the OOPS approach, solution replaces custom class with standard class and then calls standard class from within the custom class for the standard document class. And with the FM approach, FM works in standalone mode without replacing the standard class.

Let me know your views on the blog and all the comments to improve the blog are welcome.

Cheers!

To report this post you need to login first.

2 Comments

You must be Logged on to comment or reply to a post.

  1. Michelle Crapo

    Very nice!  Different ways to do it. Cool.

    Documentation – it would be interesting to hear from you how often someone uses the documentation.  I bet we could set up a counter and a table for that…

    As I sit here writing this – the link could point to a page that you allow the end users to update. That way they could change the documentation so they understood it.  I like that.  An easily modifiable page like a WIKI.

    My experience has been that they rarely look at provided documentation. BUT if they could get to it from the transaction – perhaps we could train them to go there first. I would be willing to update it with FAQ.

    I like it!

    Michelle

    (1) 
    1. Rameez Khan Post author

      Thanks Michelle for the valuable suggestion !!. It is a very good idea to get feedback from end users by pointing to modifiable page and by maintaining the document in the way user understands it. FAQ’s are the ideal case. Also to keep track of how often the documentation is read.

      (1) 

Leave a Reply