Skip to content
Aug 23 15

World Class Utility Makes getting a WHERE-USED on a RFC Push Button Easy – Part 2

by admin
Recommend This Post! Tweet about this on TwitterShare on FacebookShare on LinkedInShare on Google+Pin on Pinterest

In this installment of our IT Partners blog, I will be inviting a good friend of mine Henry Stewart to teach us about using a tool he developed to analyze and perform a WHERE-USED on a RFC in a remote SAP System. Typically, you use the delivered WHERE-USED functionality of the Repository Information System (SE84) inside an SAP instance to discover where the subject object is called or referenced.

But what if the objects calling reference is not in the system that has the RFC? You could log on to every SAP system and do a search, or we can learn from Henry and use his tool. 

Here is a brief intro to Henry…..

Henry Stewart

Henry Stewart has been consulting in the SAP technologies for 8+ years, providing his clients with expert experience in many SAP Modules including SRM, Document Builder, Records Management, FI/CO, SD, MM, PP, RE-FX,HR. Henry has extensive knowledge for implementing SRM in the public sector area customizing and developing unique solutions to meet the needs of his clients. During his free time Henry enjoys spending time with his twin boys, learning new trends in technologies, listening to Audiobooks and watching his alma-mater LSU football. Henry also severed in Louisiana Air National Guard. You can reach him at Stewart.Henry@gmail.com

The ALV Usage to Display Found RFC Locations

Lets pick up in part 2 with a closer look into the ALV Grid and it’s usage from part 1. ALV Programming is an area of ABAP development that allows for presenting the ABAP report in the tabular format with integrated functions as sorting, output in different formats, etc…

There are many good sites for ALV development, on SCN, SAP Help and elsewhere:

http://wiki.scn.sap.com/wiki/display/ABAP/ALV

http://help.sap.com/saphelp_erp60_sp/helpdata

/en/bf/3bd1369f2d280ee10000009b38f889/content.htm

ALV stands either for ABAP List Viewer or for SAP List Viewer, and is available in ABAP and Java. In this article we are not presenting ALV development just it’s aspects as it relates to this article. So let’s pick up after we selected the RFC locations.

The result of our SAP Where Used List selection of RFC references and identification of their location in the code is collected in the internal table gt_display:

RFC Locations

 

We would like to present this result to the user in the neat format with a minimum programming.  For this reaso, using ALV is a good choice:

RFC ALV Display

We also would like provide the user the capability to drill down – if they double click on the row in the ALV Grid, this  should open the specific include in the ABAP editor and point the user to the location of the call. read more…

Recommend This Post! Tweet about this on TwitterShare on FacebookShare on LinkedInShare on Google+Pin on Pinterest
Jul 19 15

World Class Utility Makes getting a WHERE-USED on a RFC Push Button Easy – Part 1

by admin
Recommend This Post! Tweet about this on TwitterShare on FacebookShare on LinkedInShare on Google+Pin on Pinterest

In this installment of our IT Partners blog, I will be inviting a good friend of mine Henry Stewart to teach us about using a tool he developed to analyze and perform a WHERE-USED on a RFC in a remote SAP System. Typically, you use the delivered WHERE-USED functionality of the Repository Information System (SE84) inside an SAP instance to discover where the subject object is called or referenced.

But what if the objects calling reference is not in the system that has the RFC? You could log on to every SAP system and do a search, or we can learn from Henry and use his tool. 

Here is a brief intro to Henry…..

Henry Stewart

 

Henry Stewart has been consulting in the SAP technologies for 8+ years, providing his clients with expert experience in many SAP Modules including SRM, Document Builder, Records Management, FI/CO, SD, MM, PP, RE-FX,HR. Henry has extensive knowledge for implementing SRM in the public sector area customizing and developing unique solutions to meet the needs of his clients. During his free time Henry enjoys spending time with his twin boys, learning new trends in technologies, listening to Audiobooks and watching his alma-mater LSU football. Henry also severed in Louisiana Air National Guard. You can reach him at Stewart.Henry@gmail.com

 

How to find where an SAP/ABAP Function Module is called

What? This is a strange question – SAP has provided wonderful search facility for all its objects – Where Used. Just display function module(FM) in SE37 transaction, place the cursor on the FM name and click on Where Used Button Where-Used. It works perfectly if our function module is Normal Function Module – i.e. used internally in the same system in which it exists. With Remote-Enabled Function Modules (RFC) the Where Used is of no help – it will not cross the different SAP systems in the enterprise to find where the RFC is used. If you stop and think for a moment, how can it? During design time we do not know yet which system the RFC can be called from. So what can we do?

First a quick note and a thank you!

helpful hints

 

In this document we will use definitions Function Module and function interchangeably.

 

I want to thank Henry Stewart for sharing his wonderful work with us, and as you read and digest this post and the next, you will undoubtedly connect with the hard work and testing that Henry experienced while perfecting this tool. I’d also like to thank Gennady Shlyapintokh, another friend and colleague,  for helping us put these posts together as only he can with his enigmatic smile and witty style of prose. You might remember Gennady, sporting his James Bond attire, from a previous post Memory Inspector to Analyze Usage in Real Time

Lets begin…

First let’s define what an RFC is – Remote Function Call(RFC) – Wikipedia, the free encyclopedia

Perspective from ECC

These days rarely are we dealing with one SAP system only. Typically ECC is connected with CRM, SRM, BW and other systems via ABAP connections. These connections are available in SM59 transaction. Let’s consider ECC function BBP_PO_INBOUND. The purpose of this function is to create or change Purchase Order (PO) in ECC. This is a remote-enabled function and is called from outside of ECC. Note the radio button enabling it to be Remotely Called below.

BBP_PO_INBOUND

If we do Where Used search in ECC as in the picture below, we will find no references in the Where Used List. The function BBP_PO_INBOUND is not called from ECC.

Where Used Scope

 

 

 

 

 

 

 

 

 

Where Used Results

 

ECC and SRM

ECC and SRM

In this example we have two systems ECC and SRM connected via ABAP connection. BBP_PO_INBOUND is called from SRM and in many cases it is difficult to find the places in the SRM code where it is called. So what can we do? One of the methods is a time consuming ABAP scan, but this scan takes long time to run and not always convenient during development and especially troubleshooting. A better alternative would be to use the LOCAL where-used functionality in each discrete system. Let’s explore this concept… read more…

Recommend This Post! Tweet about this on TwitterShare on FacebookShare on LinkedInShare on Google+Pin on Pinterest
Jun 13 15

ABAP Dynamic Programming – Part 5

by admin
Recommend This Post! Tweet about this on TwitterShare on FacebookShare on LinkedInShare on Google+Pin on Pinterest

Tony CecchiniAnthony Cecchini is the President of Information Technology Partners (ITP), an SAP consulting company headquartered in Pennsylvania. ITP offers comprehensive planning, resource allocation, implementation, upgrade, and training assistance to companies. Anthony has over 17 years of experience in SAP R/3 business process analysis and SAP systems integration. His areas of expertise include SAP NetWeaver integration; ALE development; RFC, BAPI, IDoc, Dialog, and Web Dynpro development; and customized Workflow development. You can reach him at ajcecchini@itpsap.com

 

ABAP Dynamic Programming Techniques

This will be the final post in this series on ABAP Dynamic Programming, but it’s a doozy!

Let’s set the stage, suppose most, if not all, of the information you need to write a particular subroutine or program is available only at runtime. For instance, you want to develop a utility for migrating legacy data. In situations like this, where the data structures are unknown and must be created at runtime, program generation and execution may be your only option.

Program Generation

Program code generation is considered to be the highest level of dynamic programming because the source code is created at runtime and all ABAP features can be used independently of input parameters. But, please be aware that this is an expensive and difficult option. The code to generate programs dynamically is very complex and hard to maintain. If you adopt this approach, you still have choices to make. ABAP supports two types of runtime program generation — transient and persistent.

Transient Program Code Generation

In ABAP, you can generate programs at runtime and execute them. To generate a program, the source code must be created at runtime. The source code is then passed to special ABAP commands that generate and execute the program.

You have two options for generating a program during runtime. The difference between them is the lifetime of the generated program. Transient code generation means that the generated program exists only as long as the internal mode exists. When the internal mode is finished, all transient generated programs are deleted. Persistent code generation means that the generated program is stored permanently in a database (until you delete it).

Generating code at runtime is typically used for handling dynamic data. It is possible to generate very efficient programs for special data at runtime. However, be aware of the following disadvantages:

(1) Generating a program at runtime is very time consuming and memory-intensive.

(2) Generated programs are hard to debug.

(3) There are no static checks or scans (such as scanning for the use of critical ABAP commands in a system) for programs that are generated at runtime.

(4) Generated programs are not fully supported by the ABAP Workbench (e.g., there is no Where-Used list available).

(5) Special services, such as the connection to the Transport Organizer, have to be implemented manually.

The above caveats aside, the general rule should be obvious: do not generate programs unless you have no other option. One exception is working with Open SQL, as not all of its constructs support dynamic features. Please check SAP help for a complete list. OK, a transient-generated program is called a subroutine pool. Subroutine pools cannot be called directly, and you can only call forms in a subroutine pool. In addition, there is a maximum limit of subroutine pools per internal mode.

Lets see how to generate a subroutine pool and execute a form in it! Take a look at the code below… read more…

Recommend This Post! Tweet about this on TwitterShare on FacebookShare on LinkedInShare on Google+Pin on Pinterest
May 20 15

ABAP Dynamic Programming – Part 4

by admin
Recommend This Post! Tweet about this on TwitterShare on FacebookShare on LinkedInShare on Google+Pin on Pinterest

 

Tony CecchiniAnthony Cecchini is the President of Information Technology Partners (ITP), an SAP consulting company headquartered in Pennsylvania. ITP offers comprehensive planning, resource allocation, implementation, upgrade, and training assistance to companies. Anthony has over 20 years of experience in SAP R/3 business process analysis and SAP systems integration. His areas of expertise include SAP NetWeaver integration; ALE development; RFC, BAPI, IDoc, Dialog, and Web Dynpro development; and customized Workflow development. You can reach him at ajcecchini@itpsap.com.

 

ABAP Dynamic Programming Techniques

OK, lets pick up from last month where I promised we would look at how to use the Runtime Type Identification (RTTI) technique to get information at runtime about data that is passed with generic types. So lets get started…

Runtime Type Identification (RTTI)

Runtime Type Identification (RTTI) is a powerful technique for obtaining all information about a data type at runtime. When you use dynamic programming techniques, sometimes you need to dynamically determine the data type or properties in order to decide how to handle the data. This situation typically occurs when you use generic types, where you need to obtain at runtime the missing data characteristics not described by the generic type. For example, if you use the generic type ANY in a subroutine, you will need to get information at runtime about the type of the data being passed.

RTTI is implemented in ABAP Objects using description objects. Description objects for types are created from description classes, and every type in the ABAP hierarchy has a corresponding description object. Next, every description class has special attributes and appropriate navigation methods. For instance, the class CL_ABAP_TABLEDESCR has an attribute TABLE_KIND and a navigation method GET_TABLE_LINE_TYPE.

In the RTTI class hierarchy. As you can see below, the class CL_ABAP_TYPEDESCR is the root class, which contains all methods to derive a description object from a data type or the name of the type.

RTTI Class Hierarchy read more…

Recommend This Post! Tweet about this on TwitterShare on FacebookShare on LinkedInShare on Google+Pin on Pinterest
Apr 19 15

ABAP Dynamic Programming – Part 3

by admin
Recommend This Post! Tweet about this on TwitterShare on FacebookShare on LinkedInShare on Google+Pin on Pinterest

Tony CecchiniAnthony Cecchini is the President of Information Technology Partners (ITP), an SAP consulting company headquartered in Pennsylvania. ITP offers comprehensive planning, resource allocation, implementation, upgrade, and training assistance to companies. Anthony has over 20 years of experience in SAP R/3 business process analysis and SAP systems integration. His areas of expertise include SAP NetWeaver integration; ALE development; RFC, BAPI, IDoc, Dialog, and Web Dynpro development; and customized Workflow development. You can reach him at ajcecchini@itpsap.com.

 

ABAP Dynamic Programming Techniques

OK, lets pick up from last month where I promised we would look at how to create a Dynamic Where clause for our OPEN SQL. Before we start diving into this, I want to give you a little context about “Tokens”. No No, not the kind you use for the subway! What are Tokens in ABAP? Lets go right to the help for an ABAP Tutorial!

ABAP Statements

ABAP statements consist of the following tokens and end with a period (.).

- ABAP words
- Operands
- Operators

Certain ABAP words, operands and operators form

- expressions,

which can be specified at certain operand positions.

The tokens of a statement must be separated by at least one blank or a line break. Otherwise, blanks and line breaks between tokens are not significant. An ABAP statement is not restricted to a line in the source text.

No distinction is made between upper and lowercase letters. Apart from ABAP words, operands and operators, you can also use the following special characters:

- If a number of expressions of the same type with operators are linked to an expression, the priority of the individual operations can be defined usig round brackets (()).
– For the purpose of calling functions and methods, round brackets (()) can sometimes be used.
– Lists of operands are expressed by round brackets (()) and commas (,) in certain positions.
– When forming a chained statement, a colon (:) and commas (,) can be used.

A number of free-standing special characters, such as round brackets for setting the priority, need to be separated from other tokens by an empty character. Other special characters – as well as the period at the end – do not have to be separated by an empty character.

Example

ABAP statement with the keyword DELETE, the addition WHERE, the operators =, <, >, AND, OR, the operands itab, col1, op1, col2, op2, col3, op3and round brackets.

DELETE itab 
  WHERE ( col1 = op1 AND ( col2 > op2 OR col3 < op3 ) ).

Now that we understand what a Token is, we can see the WHERE Clause has tokens in it, but so do other ABAP statements. So instead of focusing on just a Dynamic Where Clause, let broaden the discussion to DYNAMIC TOKENS in ABAP.

Dynamic Token Specification

Most ABAP statements allow you to specify some part of the statement dynamically. Essentially, this means you can supply various components of ABAP statements at runtime with a common syntax (see help above). The best way to understand this concept is via an example: Suppose you have an internal table, which must have a specified sort order. The name of the component to be used for sorting the internal table could be specified at runtime and stored in either a character field or string. Dynamic token specification is the technique you would use to meet this requirement. Take a look at the code below.

* dynamic sort
name = 'SSN'.
SORT itab BY (name).

* static sort
SORT itab BY SSN.

read more…

Recommend This Post! Tweet about this on TwitterShare on FacebookShare on LinkedInShare on Google+Pin on Pinterest