Pages

Friday, December 19, 2008

Direct call of transactions, session handling:

Batch

The following commands can be entered in correction mode ('Process in foreground' or 'Display errors only') when processing a batch input session:

/nThis terminates the current batch input transaction and characterizes it as

/bdelThis deletes the current batch input transaction.

/bendThis terminates batch input processing and sets the session to Failed

/bdaThis switches from Display errors only to Process in foreground

/bdeThis switches from Process in foreground to Display errors only

Tuesday, November 4, 2008

Online Shopping : Trust it or not?

What is Online Shop? Online Shop means you can buy or shopping any product by online. Trust it or not? Today with the high technology, many entrepreneurs advertise their product by online. Now you can buy something that you want just a click. This Online Shop is designed to help consumers more efficiently when shopping on the Web also offer the best price for consumers when shopping online.

Trust it or not? Online Shopping give you many goodness and interest. Example you can save time, money and energy with online shopping. Means you just seat at home and shopping with your computer, find and choose what the thing you want to buy, pay it with some procedures and waiting the product deliver to you. As example this website doing Online Shopping, with this medium you can buy any trusted product anytime (Click here if you want to know detail).

All this depends on you. Trust it or not? Now people don’t have enough time, so with this method Online Shop is a solutions or alternative for us to get something that we need. This is a way for we to change our life, buy the thing and favourite products as online.

Friday, October 31, 2008

What The Differences Between ABAP and HR-ABAP


The ABAP HR is an integral part of ABAP. Generally in ABAP the following are done:

1) Table development
2) Date Processin
3) Reprt developing
4) BAPIs /RFC s
5) Data base update
6) Screens development/enhancement
7) Scripts and smart forms.
8) Function Building
9) Java connectors etc.

This is basically done through the PROGRAMMING in ABAP builder by using ABAP 4th generation languge. This may be related to any module of my SAP ERP 2004 like HR, FICO.SD,MM,CRM Etc.,

Now when it is said ABAP HR. It is the development of ABAP in the area of HR to meet the clients requirements according to the functional specifications .They may be in any area of HR like in the areas of time aspects ,pay aspects, OM aspects and Self Services like E-recruitment, ESS etc.

Saturday, September 6, 2008

Describe the functions of the debugger screen.

- Single step(F5) - Use this option to step through the program statement by
statement. This allows you to branch into subroutines and function modules, and to
execute these routines step by step as well. Once a subroutine or function module
has been processed, control returns to the statement following the CALL FUNCTION
or PERFORM statement.

- Execute(F6)- Use this option to process a program line by line. All of the
statements on the current line are processed in a single step. If you are positioned
on a line that calls a subroutine and you choose Execute, the Debugger processes
the whole subroutine and then moves on to the line following the subroutine call. This
allows you to jump through the statements within the subroutine.

- Return(F7) - The Debugger returns from a routine to the point at which control
returns to the main program. Use this option to return from a subroutine, function
module, or called program to the calling program.

- Continue(F8)- Use this option to process the program up to the next dynamic or
static breakpoint or up to the cursor position. If there are no more breakpoints in the
program and no cursor has been set, the system exits debugging mode and
executes the rest of the program normally.

- Tables - Display the contents of internal tables.

source from http://sapient.wordpress.com

ABAP Important TCODES

OSS1 SAP Online Service System

SM13 Update monitor. Will show update tasks status. Very useful to determine why an update failed.

S001 ABAP Development Workbench

SE01 Old Transport & Corrections screen

SE10 New Transport & Correction screen

SE09 Workbench Organizer

SE16 Data Browser: Initial Screen.

SE30 ABAP/4 Runtime Analysis

SE36 ABAP/4: Logical Databases

SE37 ABAP/4 Function Modules

SE38 ABAP Editor

SE39 Splitscreen Editor: Program Compare

SE41 Menu Painter

SE51 Screen Painter: Initial Screen.

SE71 SAPscript layout set

SE80 ABAP/4 Development Workbench Object Browser

SM12 Lock table entries (unlock locked tables)

SM21 View the system log, very useful when you get a short dump. Provides much
more info than short dump

SM35 View Batch Input Sessions

SQ00 ABAP/4 Query: Start Queries

Friday, September 5, 2008

SAP ABAP Important Keywords

SAP ABAP Important Keywords

The following list displays some of the important Keywords in ABAP

NoKeywordDescription
1AT END OF … ENDATControl group end in LOOP
2AT Fg … ENDATProcessing specific to record type in LOOP
3AT FIRST … ENDATExecute processing block within a LOOP before processing single lines
4AT LAST … ENDATExecute processing block within a Loop after processing single lines
5AT NEW … ENDATControl group end during LOOP
6CALLCall processing (Program, function module, screen)
7CHECKSelection condition, leave loops and subroutines
8CONTINUEExit current loop pass within a DO, WHILE, LOOP or SELECT loop
9DO … ENDDOLoop processing
10EXEC SQL … ENDEXECExecute a Native SQL Statement
11EXITLeave loops or subroutines
12FORM … ENDFORMDefinition of a subroutine
13IF … ELSE … ENDIFConditional processing
14LEAVELeave program processing, go to a transaction, list (or) menu
15LOOP … ENDLOOPLoop on a table (or) extract dataset
16MODULE … ENDMODULEDefinition of a dialog module
17ON CHANGE OF … ENDONProcessing on field change
18PERFORM … USINGCall a subroutine
19SELECT … ENDSELECTRead database tables
20STOPEnd selection
21WHILE … ENDWHILELoop processing

source from http://abaplovers.blogspot.com

Saturday, August 9, 2008

Abap Report & Event in Abap Report

ABAP program that reads and analyzes the data in database tables and sometimes also makes updates.

ABAP report programs have the program type "executable program" and are often linked to a particular logical database.

When you execute an ABAP report program, you can display the resulting output list - also known as a report - on the screen or send it to a printer. You can also save the output list and display it later.


Event in ABAP report determine process flow of a program. The events are triggered depended on the way the output is generated. They begin after event keyword and end when the next event reached.

Event keyword:

INITIALIZATION.

Occurs when report initialized.
We can use it to check user authorization or prepare output for selection screen. Here you can create or determine ranges for your selection data.

AT SELECTION-SCREEN OUTPUT :
Occurs each time selection screen about to generated.
We can use it to modify selection screen, for example hide / unhide parameter.

AT SELECTION-SCREEN.
Occurs each user command in selection screen. we can use it to perform checking rules on user input.

START-OF-SELECTION
Occurs after the standard selection screen has been processed. Select data (to get your data)
data is read in this event.

END-OF-SELECTION
Occurs after start-of-selection. (Finished for selection data)

TOP-OF-PAGE
Occurs when a new page starts.
This portion is use for write report header.

END-OF-PAGE
Occurs when a page ends. Write report footer.

AT LINE-SELECTION
Occurs when the user double-click on report.

AT USER-COMMAND
Occurs when the user push toolbar button.

Monday, August 4, 2008

How to transport Standard Text : Download

Get the document here with the screenshot.. how to transport standard text.
Download Here

Saturday, August 2, 2008

RFC.... What it is RFC?

Communication between applications in different systems in the SAP environment includes connections between SAP systems as well as between SAP systems and non-SAP systems. Remote Function Call (RFC) is the standard SAP interface for communication between SAP systems. RFC calls a function to be executed in a remote system.

Synchronous RFC

The first version of RFC is synchronous RFC (sRFC). This type of RFC executes the function call based on synchronous communication, meaning that the systems involved must both be available at the time the call is made.

Transactional RFC (tRFC)

Transactional RFC(tRFC, previously known as asynchronous RFC) is an asynchronous communication method that executes the called function module just once in the RFC server. The remote system need not be available at the time when the RFC client program is executing a tRFC. The tRFC component stores the called RFC function, together with the corresponding data, in the SAP database under a unique transaction ID (TID).

If a call is sent, and the receiving system is down, the call remains in the local queue. The calling dialog program can proceed without waiting to see whether the remote call was successful. If the receiving system does not become active within a certain amount of time, the call is scheduled to run in batch.

tRFC is always used if a function is executed as a Logical Unit of Work (LUW). Within a LUW, all calls

· are executed in the order in which they are called

· are executed in the same program context in the target system

· run as a single transaction: they are either committed or rolled back as a unit.

Implementation of tRFC is recommended if you want to maintain the transactional sequence of the calls.

Disadvantages of tRFC

· tRFC processes all LUWs independently of one another. Due to the amount of activated tRFC processes, this procedure can reduce performance significantly in both the send and the target systems.

· In addition, the sequence of LUWs defined in the application cannot be kept. It is therefore impossible to guarantee that the transactions will be executed in the sequence dictated by the application. The only thing that can be guaranteed is that all LUWs are transferred sooner or later.

Queued RFC (qRFC)

To guarantee that multiple LUWs are processed in the order specified by the application, tRFC can be serialized using queues (inbound and outbound queues). This type of RFC is called queued RFC (qRFC).

qRFC is therefore an extension of tRFC. It transfers an LUW (transaction) only if it has no predecessors (based on the sequence defined in different application programs) in the participating queues.

Implementation of qRFC is recommended if you want to guarantee that several transactions are processed in a predefined order.

Source from: SAP Library : http://help.sap.com

Wednesday, July 23, 2008

IDOC Type & Message of release 4.5

DOWNLOAD HERE

All Idoc Type & Message release 4.5 for Download.

SAP- Abap Programming for Download

Get e-book for SAP BC - ABAP Programming

DOWNLOAD HERE

Saturday, July 19, 2008

How To transport Standard text

  1. Go to report RSTXTRAN. (Transfer of SAP script Texts to a Correction).
  2. Key-in/ insert object name that you’ve create in standard Text (SO10) at Text key-name
  3. Click on Execute button (F8)
  4. Click on Continue Button (Enter)
  5. Click on Trsfr texts to corr button (F5) . Click YES on pop-up screen.
  6. Create transport Request and Save.

Thursday, July 17, 2008

How to Transport Request Number?

1. Go to transaction SE10.

2. Click on button Display.


3. Set the cursor into Transport Number that will be too transported. After that click on icon lorry .(released directly or press F9)

Friday, July 11, 2008

Upload Excel Data to SAP: 7 Best Practices

By Vikram Chalana
Even with the standardized business processes and centralized data stores provided by SAP, much corporate data still resides in spreadsheets. Taking data in these spreadsheets and putting them into SAP remains one of the thorny challenges facing many corporate IT departments. Many business departments are

wasting resources in manually reentering this data into SAP while introducing errors due to manual data entry. Functional and technical analysts in the IT departments are inundated with requests from business users to automate the upload of Excel data into SAP.
• Are you an SAP business user looking to reduce manual data entry for mass uploads or mass changes to SAP data, particularly when the data already exists in Excel?
• Are you an IT functional or technical analyst looking for ways to service the end-user requests for data uploadd more effectively?
• Are you looking for ways that your company can save time and resources in SAP data management?
If you answered “Yes” to any of the above questions, then this article is for you. This article describes 7 best practices in automating the upload of Excel
data into SAP
. Adopting these best practices will alleviate many of the pains that business users and IT analysts face in uploading Excel data to SAP.
1. Avoid Programming. With the several non-programming choices available to connect Excel and SAP, custom programming in ABAP or VB should be the absolute last resort for ad-hoc uploading Excel data to SAP. Not only programming is
expensive and time consuming, a program that will be used only once or even once a year is particularly wasteful. Further, creating robust programs require a fair bit of testing and if a program has not been well-tested, it could be dangerous and cause irreparable data damage.
Use a scripting or a non-programming approach as much as possible. SAP provided tools such as BDC, CATT, LSMW, and third party tools such as Winshuttle’s TxShuttle will allow you to avoid programming to a large extent.

2. Do not Upload Directly to SAP tables. While this point is very obvious, it
cannot be overemphasized. Writing directly to SAP tables avoids all the data
validation and checks and balances that happen when creating data through the
normal SAP transactions. So, avoid using any method that writes directly to SAP
tables.
Always upload data via the pre-configured SAP transactions or BAPIs. Again,
using tools such as BDC, CATT, or LSMW, or TxShuttle will allow the upload of
data via SAP transactions instead of writing directly to SAP tables.

3. Choose a Record, Map, and Run strategy. A record, map, and run strategy
generally involves first recording an SAP transaction where data needs to be
uploaded. The recording step is followed by a mapping step where the SAP data
fields captured during the recording are mapped to the Excel fields. Finally,
the transaction is run over and over again with the different rows of data in
the Excel file. A Record, Map, and Run strategy is similar to recording and
running macros for automating routine tasks.
The advantages of choosing a record, map, and run strategy are that (a) it is
very general and can work well for many different upload tasks and many
different SAP transactions, even with custom transactions, (b) it is a very easy
and intuitive approach and saves a lot of time making a mass data update, (c) it
is something that even the business users can do themselves without requiring
much IT support.
A record, map, and run strategy should be used for uploading data from Excel
to SAP. Again, the SAP provided tools, such as BDC, CATT, and LSMW all support
such a strategy and can work for many different upload applications. The
TxShuttle tool simplifies the mapping recording and mapping tasks a lot and
makes it even easier for business users. Also, for applications that require
upload of transactional data containing header and line-items, such as journal
vouchers, invoices, purchase orders, sales orders, etc., the TxShuttle tool has
features that make it really useful.

4. Choose a Secure and SOX Compliant Method: Make sure the method you choose
is secure and preserves SAP’s role-based security. In these days of
Sarbanes-Oxley (SOX) audits, this point cannot be overemphasized. One key aspect
of section 404 is checking that rights and duties are separately assigned to
different individuals so that no individual has the power to divert business or
transactions in a fraudulent manner. One of the most common open SOX audit
issues is that users in the IT departments have very broad access to production
data in SAP. Therefore to ease compliant with SOX, any mass changes or uploads
should ideally be performed by the business users who are already authorized to
make the change.
To allow business users to perform the upload via SAP-provided
transaction-based tools, they would need extra authorizations to use these
tools. If your company is not able to provide such authorizations, the use of
Winshuttle’s TxShuttle product may be more appropriate since it lives outside
the core SAP system and generally does not require extra authorizations.

5. Keep the data in native Excel format. If the data to be uploaded stays in
the native Excel format, rather than being converted to comma-delimited or
tab-delimited text file formats, it makes the upload process much simpler. One
less step for the users to worry about.
The use of Winshuttle’s TxShuttle product allows the users to keep their data
in native Excel format.

6. Select an outside-in approach: The two approaches to bringing outside data
into SAP are: (a) an inside-out approach where the data import tools live inside
SAP are used to bring outside data into SAP, and (b) an outside-in approach
where the tools living outside SAP are used to bring outside data into SAP. An
inside-out approach typically requires all the data import scripts and programs
to live inside SAP and therefore need to be maintained as SAP versions are
upgraded, even when the scripts are one-time-use only. Thus, these one-time use
scripts clutter the SAP system when using the inside-out approach. An outside-in
approach offers a cleaner alternative that can be used with the user’s existing
security profiles.
The announcement of Microsoft and SAP’s joint product, Mendocinno,
recently validates the importance that both companies give to an outside-in
approach. Other add-on products such as TxShuttle also take an outside-in
approach to connect to SAP.

7. Empower business users: On a final note, one of the best practices in
uploading Excel data to SAP is to empower business users to do the upload
themselves. The choice of the right tool for the business users which will
enable them to easily upload data without requiring any programming will go a
long way to freeing up IT resources for more mission-critical applications.
Letting business users take control of their own data also makes SOX compliance
easier.
An easy to use product such as Winshuttle’s TxShuttle which will let business
users upload their own data from Excel to SAP allows the empowering of these
business users.

In summary, the best practices in uploading Excel data to SAP proposed here
involve choosing non-programmatic, easy-to-use approaches, and this will enable
your company to save large amounts of time and resources in day-to-day SAP data
management.

To learn more about SAP tools, BDC, CATT and LSMW, visit
http://www.sap.com.
To learn more about Winshuttle tool, TxShuttle, visit
http://www.winshuttle.com.
At this site, you can download a FREE WHITE PAPER
describing this problem and how the TxShuttle tool works at
uploading Excel data to SAP.

You can also download a FREE 15-day evaluation version of the TxShuttle software for connecting SAP and
Excel.

Vikram Chalana is the SAP product specialist at Winshuttle, Inc. He has helped many clients automate their SAP business processes, in particular processes dealing with the connecting spreadsheets and SAP. He has been in the IT industry as a data minining, business intelligence, business process automation expert for over 10 years.

To learn more about Winshuttle, please visit http://www.winshuttle.com



Performance Trace in SQL For ABAP

To obtain an overview of the behavior of the R/3 System, you can record various processes during the execution of an individual object. To analyze performance problems with database accesses, activate the SQL trace and the buffer trace from transaction ST05.

The SQL trace records SQL statements. There may be considerable differences between the SQL statement formed on the ABAP level and the SQL statement that is received by the database.

A buffer trace lets you trace SQL statements that access buffered tables. SQL statements that access buffered tables can cause buffer reloads, which are indicated in a buffer trace. An SQL statement accessing a buffered table can result in a completely different SQL statement if it cannot be satisfied by the R/3 table buffer.

Additional tools include: the enqueue trace, which records enqueue requests or releases, indicating the enqueue key and the object involved; as well as the RFC trace, which records the RFC calls received or sent.

Initial screen :

To access the SQL Performance Trace, use transaction ST05 or from the R/3 initial screen, choose System ® Utilities ® SQL Trace.

Before activating an SQL Performance Trace for a report or a transaction, you should execute the report one time to prevent the buffer load process for the R/3 table buffer, the R/3 program buffer, and so on, from being included in the subsequent trace.

The trace can be activated in the production system without any risk of creating errors or inconsistencies.

The trace can be activated by any user and for any object. When activating the trace, ensure that you are not using multiple user sessions or running other processes such as background jobs or update processes under the same user ID on this application server. These activities would make the SQL Performance Trace difficult to interpret.

For each application server, there is only one active trace file. Therefore, on a given application server, only one user can activate a trace. The default size of the trace file is 800 KB. SAP recommends increasing the size of the trace file to 16 MB by setting the parameter rstr/max_diskspace to 16 384 000.

Overview of sql trace:


The R/3 database interface receives an SQL statement from the ABAP program and converts it to an SQL statement that can be processed by the database.

For each database operation, the SQL trace measures the time taken from the sending of the request to the database server to the receipt of the results for the request on the application server via the R/3 database interface (including the time spent in the network between the application server and the database server).

The data written to the trace file includes the database response time, a time stamp, the number of transferred data records, the database return code, the text of the SQL statement, and additional administrative information for each database operation.


SAP ABAP Performance Tuning Tips & Tricks

Need for performance tuningABAP is the universal language in the World of SAP programming and the focus is also on getting a team of efficient programmers as early as possible in each and every part of the project, both for handing over the technical specifications to them and also for asking them to toss out the ABAP programs within the “given deadlines” as well.

The key focus of assembling an efficient program takes a back seat since this force has a greater pressure of schedules along with deliveries to accomplish successful outcomes. Also an proficient ABAP program is one which brings the wanted output to the user in a finite time according to the complexity involved in the program, rather than hearing the comment “I put the program to run, have my lunch and come back to check the results”.

A performance optimized ABAP program saves the time of the end user, thus increasing the productivity of the user, and in turn keeps the user as well as the management happy leaving aside the hyperbole. SAP ABAP performing tuning tips and tricks are used for making the ABAP programs efficient in doing their work. This tuning tips and tricks also assume that the reader is well versed in each and every concepts and syntax of ABAP programming.

SAP Implementation Benefits SAP solutions embrace an extensive range of business domains, such as Financial Accounting Controlling, Asset Management, Project System, Human Resources, Quality Management, Production Planning and Sales and Distribution. We also help for small and mid-size firms that achieve profits and have significant advantages through SAP investment via our expertise in presenting SAP solutions.

Some SAP implementation benefits include:

  • Gradual declination in the total cost of ownership
  • Accomplishment of faster return on investment
  • Imparting flexibility in business processes
  • Inspection of entire business processes
  • Integration, collaboration, planning, execution, and coordination of the complete supply chain network
  • Achievement of consistent as well as apparent business insights
  • Develop employee productivity
  • Creation of a quality work environment
  • Achievement of operational excellence and growth
  • Exploitation of additional solutions with ease

Both SAP Implementation and SAP training are worth investing since it takes into account regarding the benefits it offers. Our partnership with leading application vendors permits us to convey competitive SAP advantages to our enterprising customers. Enterprises get in touch for the processing of SAP Consulting and SAP Upgrade solutions. We also offer its consulting, implementation and training services for the upcoming Microsoft Dynamic Business Solutions.

Ron Victor is a SEO copywriter for http://www.simplysap.com
He written many articles in various topics.For more information visit http://www.simplysap.com
Contact him at ron.seocopywriter@gmail.com

Saturday, June 21, 2008

Configuring ALE:

Source from : http://www.thespot4sap.com/Articles/SAP_ALE_Configuring.asp

3.1 Understand and verify the need of business processes

The need of implementing ALE must be clear to you. For that you need to have all the details of the business requirements. These requirements will facilitate the implementation process and also ensuring its success.

3.2 Configure SAP user administration module (BASIS)

This step involves BASIS configuration of SAP system. The concept of the Logical System described above is applicable here. BASIS administration involves creation of logical systems (LS) for every prospective ALE-enabled client, followed by linking prospective clients to the Logical System using the respective servers.

Once the Logical Systems have been created, you create background users on the prospective clients – to be used by ALE. After this, choose Tools > Administration > Administration > Network > RFC destinations or enter transaction code SM59 to create RFC (Remote Function Call) destination for each client.

As a final step, create partner profiles for the sending system. A partner profile is an identifier for the sending system that is used for communicating messages. You will be using LS as it is used for ALE communications. Every partner profile used for ALE must be based on existing LS (created above).

3.3 ALE Functional Configuring in SAP

This configuration step allows the installation of core ALE features on which data transfer activity will be based. You need to create a Customer Distribution Model (CDM) first. The Customer Distribution Model acts as a repository of data that decides the flow of message types to Logical Systems (LS). There can be one to many messages flow to a Logical System and it can also happen vice-versa. You also need to enforce a selection criterion on the message (type) flowing to a Logical System. This is achieved by adding appropriate message types and filters to the CDM.

Now that the path of the message flows have been set, we can generate outbound partner profiles (similarly as we done for inbound profiles in step 2). Finally, you can distribute the CDM to the receiving systems followed by generating inbound partner profiles on each of the clients.

3.4 Testing and Implementing the ALE Configuration

After completing the setup of the ALE environment it needs to be thoroughly checked and tested with real time business processes and situations. The performance should be measured with varying degree of business transaction volumes. It is advisable to include negative and ‘unusual’ test scenarios as well.

Once testing is completed it can be implemented once it is signed off with the respective business owners.

Configuring your ALE solution

Source from : http://www.erpgenie.com/ale/configuration.htm

  1. Confirm business requirements - Before commencing configuration ensure that you have the detail of the business requirements for the whole scope of the implementation.
  1. Configure the ALE basis portion to enable ALE in the development environment. This involves the following steps:
    • Create Logical System (LS) for each applicable ALE-enabled client;
    • Link client to Logical System on the respective servers;
    • Create background user, to be used by ALE, on each client;
    • Create RFC destination for each destination client; and
    • Generate partner profiles for sending system. (Can only do this if at least 1 message type exists against the sending system's LS). This automatically generates the port if the LS and RFC name are the same.
  2. Following the basis configuration is the functional configuration:
    • Create a Customer Distribution Model (CDM);
    • Add appropriate message types and filters to the CDM;
    • Generate outbound partner profiles;
    • Distribute the CDM to the receiving systems; and
    • Generate inbound partner profiles on each of the clients.

Saturday, June 14, 2008

Why ALE?

ALE is a business solution to a very real need emerging in the SAP market. This is the need for businesses to move towards tighter integration between systems, yet, at the same time, provide independence to the various business units within the company.

In the past the move was towards centralized systems...

Standardization of business processes accompanied by ever tighter integration within the central system no longer represents a practicable approach to this problem. The following are some of the most commonly encountered difficulties:

  • technical bottlenecks,
  • upgrade problems,
  • the effect of time zones on international corporations,
  • excessively long response times in large centralized systems.

How do you achieve this "loosely coupled applications" without compromising data integrity, without committing yourself to a specific technology, without adding to the technical issues mentioned above, ???

What if you want to link in to external systems as seamlessly as possible?

The SAP Solution - ALE

SAP has provided ALE (Application Link Enabling) as the solution to these issues. It allows you to:

  • distribute your applications across several SAP systems, such that centralized functions, as well as decentralized functions can operate in the same company arena
  • maintain and distribute master data elements from a central system, thus maintaining unique number ranges across several systems
  • maintain and distribute control data objects from a central system, thus synchronizing important configuration data. This is important when trying to decentralise functions, yet keep them integrated
  • couple R/2 and R/3 systems, in some instances
  • couple SAP and external systems, via IDocs (Intermediate documents) and an external translation mechanism.
Source : http://www.erpgenie.com

Saturday, June 7, 2008

ALE. What is ALE?

ALE is Application Linking and Enabling. ALE is a mechanism for the exchange of business data between loosely-coupled r/3 applications built by customers of SAP, the enterprise resource management program. ALE provides SAP customers with a program distribution model and technology that enables them to interconnect programs across various platforms and systems.

There are three layers in the ALE system:

1. Application services.

2. Distribution services.

3.Communication services.

IDoc (intermediate document), which is a container for the application data to be transmitted. After a user performs an SAP transaction, one or more IDocs are generated in the sending database and passed to the ALE communication layer. The communication layer performs a Remote Function Call (RFC), using the port definition and RFC destination specified by the customer model.

IDoc Transactions

* WE09 / WE02 IDoc lists according to content. View IDocs via specific IDoc number or business application detail contained within the contents of a segment.
* WE05 View IDocs
* WE19 EDI test tool. Use to test inbound Function module changes.
* WE20 Partner profile configuration. Add partner detail together with inbound and outbound relationships. We also incorporate message control on the outbound IDocs. Utilize the organizational units to trap functional errors for further processing
* WE30 Create IDoc extension type
* WE31 Segment create
* WE57 Assign function module to logical message and IDoc type
* WE60 IDoc type documentation tool
* WE82 Link Release detail to Extension IDoc Type
* BD55 Conversion rule user exit. Link conversion rule user exit to the different system \ partner combinations
* BD87 Reprocess IDocs in error or waiting for action. (Both inbound and outbound in 4.6. Use BD88 in prior versions)
* BALA ALE Application Distribution
* BALM ALE Master Data Distribution

Tuesday, May 27, 2008

ABAP/4 functions:

  • Popup_to_confirm_loss_of_data
    Create a dialog box in which you make a question whether the user wishes to perform a processing step with loss of data.
  • Popup_to_confirm_step
    Create a dialog box in which you make a question whether the user wishes to perform the step.
  • Popup_to_confirm_with_message
    Create a dialog box in which you inform the user about a specific decision point during an action.
  • Popup_to_confirm_with_value
    Create a dialog box in which you make a question whether the user wishes to perform a processing step with a particular object.
  • Popup_to_decide
    Create a dialog box in which you require the user between the two processing alternatives, or to cancel the action.
  • Popup_to_decide_with_message
    Create a dialog box in which you inform the user about a specific decision point via a diagnosis text.
  • Popup_to_display_text
    Create a dialog box in which you display a two-line message.
  • Rfc_system_info
    Fetch information from the current instance filling the structure FRCSI.
  • Rs_send_mail_for_spoollist
    Send messages from ABAP/4 programs to SAPoffice. The structure SOLI may contain the message.

Report command field formats

%pri : Print the current report

%pc : Download the current report

%sc : Call the find function

p+ : Go to the next page

p- : Go to the previous page

p++ : Go to the last page

p-- : Go to the first page

Friday, May 23, 2008

How to find out the Form and Report Name from Standard?

By using transaction code nace, you can find out all the form and report name for the standard output using for standard module.

---> goto se93>nace>enter

Convert the sapscript from spoollist to pdf

Convert the sapscript from spoollist to pdf.

When opening layout with "OPEN_FORM" function module specify:
DEVICE = 'PRINTER'
and OPTIONS = your_itcpo_variable
with your_itcpo_variable-TDGETOTF = 'X'.

When you close your layout with "close_form" function module suply an array to get OTFDATA.

This will generate your "print order" to an internal array not to spool. This will be in OTF format.

Then call "CONVERT_OTF_2_PDF" function module to get your OTF traslated to PDF. The array obtained can be saved to disk to get a pdf archive.

This works fine at least in 4.5B

You can use the standard program RSTXPDF4.

Hope this should work.

When u use the standard program [b]rstxldmc[/b] , there might be some probs with uploading of the bmp file.
So, a better approach is :
1. Go to T.C : se78(Graphics management).
2. select > Graphics > BMP.
3. Then click on Import on the standrad toolbar.
4. Press f4 and give the path where your BMP file is on the local system.
5. Give some name for your logo,,, Eg : 'MYLOGO' .
6. select the radiobutton for TYPE as Color Bitmap Image.
Continue. Finished.
Click on the print prewiev to view your Uploaded logo into the SAP System.

Saturday, May 10, 2008

SAPScript Transaction codes

SE71 - Form painter

SE72 - Style maintenance

SE78 - SapScript Graphics Management

SO10 - Create standard text module

Sapscript

Sometimes user have a requirement to create form. Using normal Abap Code this is not possible. Instead SAP provides an object called SAPSCRIPT to generate such kind of documents which can contain logos, tables and other objects and which can look like pre-printed documents.


A layout set is a template designed in SAP to place the stream of data coming from a SAP program on different parts of a physical page. The designer needs to lay out the various elements that need to be printed on the page and store it as an object in the SAP system. An ABAP program will subsequently call this object to generate an instance of the template – thus generating an output document from the program.

  • Standard Attributes in Sapscript
  1. Description - Brief description or title of the layout set
  2. Default paragraph - The base paragraph that is globally applicable to the document. This can be overridden at lower level of the layout set by using other paragraphs
  3. Tab Stop - The base tab-stop that is globally applicable to the document. These can be overridden at lower level of the layout set by using other tab stops
  4. First Page - The start page of the layout set
  5. Page Format
  6. Orientation - The direction of printing the data on a page – P for portrait (vertical) and L for landscape (horizontal)
  7. Lines per inch
  8. Characters/inch

Thursday, May 8, 2008

General command field formats

You can use this command in SAP screen field:
/n Skip to the next record if you are processing one batch input session
/bend Cancel a batch input foreground process
/nend Close all R/3 sessions and logoff
/nxxxx Call the transaction xxxx in the same session
/o Generate a session list
/oxxxx Call the transaction xxxx in an additional session
/i Delete the current session
/h Turn the debug mode on
/$tab Reset all buffers (for System Administrators)
/$sync Synchronize instances buffers (for System Administrators)

Transactions

search_sap_menu - Finds the menu path to a transaction
  • WE09 / WE02 IDoc lists according to content. View IDocs via specific IDoc number or business application detail contained within the contents of a segment.

  • WE05 View IDocs

  • WE19 EDI test tool. Use to test inbound Function module changes.

  • WE20 Partner profile configuration. Add partner detail together with inbound and outbound relationships. We also incorporate message control on the outbound IDocs. Utilize the organizational units to trap functional errors for further processing

  • WE30 Create IDoc extension type

  • WE31 Segment create

  • WE57 Assign function module to logical message and IDoc type

  • WE60 IDoc type documentation tool

  • WE82 Link Release detail to Extension IDoc Type

  • BD55 Conversion rule user exit. Link conversion rule user exit to the different system \ partner combinations

  • BD87 Reprocess IDocs in error or waiting for action. (Both inbound and outbound in 4.6. Use BD88 in prior versions)

  • BALA ALE Application Distribution

  • BALM ALE Master Data Distribution


  • VA02 Sales order change

  • VA05 List of sales orders

  • VA22 Quotation change

  • VA32 Scheduling agreement change

  • VA42 Contract change

  • VF02 Change billing document

  • VF11 Cancel Billing document

  • VF04 Billing due list

  • FBL5N Display Customer invoices by line

  • FBL1N Display Vendor invoices by line

  • VL02N Change delivery document

  • VL04 Delivery due list

  • VKM5 List of deliveries

  • VL06G List of outbound deliveries for goods issue

  • VL06P List of outbound deliveries for picking

  • VL09 Cancel goods issue

  • VT02N Change shipment

  • VT70 Output for shipments

  • VKM3, VKM4 List of sales documents

  • VKM1 List of blocked SD documents

  • VD52 Material Determination

Tuesday, May 6, 2008

BASICS OF INTERACTIVE REPORTS:

BASICS OF INTERACTIVE REPORTS:

When the user starts an executable (type 1) program, the program context and memory space for data objects (variables and structures) are made available on the application server. The subsequent program flow is controlled by the ABAP runtime system.

If the program contains a selection screen, the ABAP runtime system sends it to the presentation server at the start of the program.

Once the user has finished entering data on the selection screen, he or she chooses 'Execute' to tell the system to start processing the rest of the program. The data entered on the selection screen is automatically placed in the corresponding data objects. The ABAP runtime system takes over control of the program.

In this simple example, there is only one ABAP processing block to be processed by the runtime system.

This processing block contains a read access to the database. The program sends information to the database about the records that should be read.

The database returns the required database records and the runtime system ensures that the data is placed in the relevant data objects.

The list output is also programmed in the processing block. After the processing block finishes, the runtime system sends the list as a screen to the presentation server.

Selection screens allow users to enter ranges of values. They are normally used to define the set of data that needs to be read from the database.

As well as the normal graphical elements (group boxes, checkboxes, radio buttons, and so on) that you use in screens, selection screens also have input/output fields (PARAMETERS) and special groups of input/output fields (SELECT-OPTIONS).

You place a single input/output field on the selection screen using the PARAMETERS statement.

You can use the SELECT-OPTIONS statement to place a group of fields on the screen that allows users to enter complex selections. The selection may be a single value, or any form of interval (discrete or continuous). You can also use patterns. (See following slides).

You can create variants for selection screens.

If you declare an input field with reference to an ABAP Dictionary field, any search helps defined for the Dictionary field will be available on the selection screen.

Selection texts can be translated into other languages. They are then displayed in the user's logon language.

Selection ranges are stored in programs using an internal table.

The ABAP statement SELECT-OPTIONS FOR declares an internal table called , containing four fields - SIGN, OPTION, LOW, and HIGH. The fields LOW and HIGH have the same type as the field .

The SIGN field can take the value 'I' (for inclusive) or 'E' (for exclusive).

The OPTION field can contain relational operators, pattern operators, and operators that allow you to enter intervals.

For more information about selection ranges, choose Goto -> Selection screen help from any selection screen.

To define a selection screen, include the required PARAMETERS and SELECT-OPTIONS statements in your data declarations. If you define more selection screens than just the standard selection screen, you must enclose the additional definitions in the statements SELECTIONSCREEN BEGIN OF SCREEN and SELECTION-SCREEN END OF SCREEN where is the number of the selection screen.

For information about other graphical elements that you can place on a sele ction screen, such as group boxes, checkboxes, radio buttons, references to input fields on other selection screens and so on, see the keyword documentation for the SELECTION-SCREEN statement

The standard selection screen is displayed by the ABAP runtime system when the program starts.

User-defined selection screens are displayed when you use the statement CALL SELECTIONSCREEN . This statement sets the return code sy-subrc to zero if the user chooses 'Execute', and to 4 if the user chooses 'Cancel'.

You can also call a selection screen as a modal dialog box. To do this, use the syntax CALL SELECTION-SCREEN STARTING AT ENDING AT where and are the coordinates of the top left-hand corner of the screen. and are the coordinates of the bottom right-hand corner.

Selection screen processing is event-driven. Events are ABAP processing blocks that are called by the runtime system in a particular order and processed sequentially. In the program, each event is introduced by an event keyword. The processing block ends when the next event block starts, or the definition of a subroutine or dialog module occurs.

AT SELECTION-SCREEN OUTPUT is processed before the selection screen is displayed. You can use this event to modify the selection screen dynamically.

AT SELECTION-SCREEN ON HELP-REQUEST FOR and
AT SELECTION-SCREEN ON VALUE-REQUEST FOR allow you to define your own F1 and F4 help.

AT SELECTION-SCREEN is processed when the user presses ENTER or chooses another function on the selection screen. You can use this event to check the values the user entered on the screen. The addition ON... allows you to control which fields or groups of fields should accept input again in the event of an error.

An ABAP program consists of a sequence of processing blocks (events) that are processed by the runtime system in a particular order.

LOAD-OF-PROGRAM is triggered directly after the system has loaded a program with type 1, M, F, or S into an internal session. The processing block is executed once only for each program in each internal session.

INITIALIZATION is processed in executable (type 1) programs, directly before the selection screen is displayed. You can use the corresponding processing block to preassign values to the parameters and selection options on the selection screen.

START-OF-SELECTION is processed after the selection screen has been processed. If you are working with a logical database, the corresponding GET events are triggered after START-OFSELECTION.

END-OF-SELECTION is processed after all of the data has been read, and before the list is displayed.

TOP-OF-PAGE is an event in list-processing. The processing block is always executed when you start a new page in the list.

Once the basic list has been displayed, you can react to possible user actions. Detail lists allow you to distribute the information you want to display across several lists.

This makes the lists easier for the user to understand, and improves performance, since you can delay reading extra information from the database until the user actually requests it.

You can also use additional selection screens to allow the user to enter further restrictions.

For each basic list you can use up to 20 detail lists. Each list is stored in its own list buffer. When the user chooses 'Back' (green arrow) or 'Cancel' (red cross), he or she returns to the previous list.
This action initializes the list buffer of the list level the user just le ft.

When the user chooses 'Exit' (yellow arrow), the system terminates the list processing and returns to the standard selection screen.

The events START-OF-SELECTION, GET, END-OF-SELECTION, TOP-OF-PAGE and END-OFPAGE can be used only to create basic lists.

To create detail lists, use the events AT LINE-SELECTION or AT USER-COMMAND.

Use TOP-OF-PAGE DURING LINE-SELECTION for page headers on detail lists.

Each detail list event exists only once in the program and is shared by all detail lists. You must therefore ensure yourself, within the processing block, that the correct list is created. To do this, use a CASE structure that uses the system field sy-lsind. This system field contains the list index of the list that you are currently generating.

Use the statement HIDE global_field to store the contents of the global data field
global_field for the current line.

If the user selects the line, the data field is automatically filled with the value that you retained for the line.

You do not have to display the field on the list in order to retain its value using HIDE.

The field can be a structure. However, deep structures (structures containing internal tables as components) are not supported.

When the user selects a line on an interactive list, all of the global data fields whose values you stored using the HIDE statement while you were creating the basic list are filled with those values.

The line selection is based on the cursor position when the AT LINE-SELECTION and AT USERCOMMAND events occur. (system field sy-lilli).

If you choose a line using the READ LINE... statement, the values are placed back in the original fields according to the line numbers.

To check whether the user selected a valid line, you can use the fact that the hide area only contains data for valid lines. When you have finished creating the list, initialize a suitable test field. This allows you to check before you create the detail list whether a value from the hide area has been placed in the test field.

Once you have created the detail list, re-initialize the test field to ensure that the user cannot choose an invalid line once he or she returns from the detail list and attempts to select another line for a new detail list.

source from : http://abapprogramming.blogspot.com