6.20.2009

ABAP Tips - Help Guide

On request from our regular visitors. From this edition (Today), I am going to provide you a complete list of ABAP TIPS and GUIDE in a ZIP Format and easy to download and read at your convenience.

This is made for your convenience.

ABAP Tips - Click to Download

Hope you all appreciate. - If YES, Leave your comments. Which will encourage me further.
read more...

Selecting Sessions and Reading the Session Display

Use

The heart of the tool for managing batch input sessions is the session list. The management tool offers lists by status, and you can select lists according to other criteria as well.

Prerequisites

Start the batch input management tool: Select System ® Service ® Batch input ® Sessions. Alternate: Enter transaction SM35. Both paths take you to the session overview of the batch input system. transaction SM35.

Procedure

On the main menu, you can select sessions using any or all of the following criteria:

* session name

* date on which the session was generated (entered into the session queue)
* user who generated a session

* session status

In the session overview, you can start, analyze, or delete sessions in the queue. You can also display statistics on the transactions in a session and view the session log. All sessions generate a log when they are run. From the session log display, you can take further actions, such as displaying more information on the messages in a log.

Reading The Session Queue

The information in the session queue includes the following:

* Creator:The user who generated the session.

* Date and Time:
The date and time when a session was generated (entered in the session queue).

* Lock date:If a session is locked, this column shows the date upon which the system will release the session. A locked session cannot be started.
* Authorizations user: The user under whose authorizations the transactions in a session are to be run. When the session is run, it can execute only those transactions and functions for which this user has authorizations.
* Status: The status of a session (new, processed, contains errors, as shown in the tabs in the overview).

* Tran. and Screen: The number of transactions and screens, respectively in a session.

You can display statistics on the transactions in any session by marking the session and using the Statistics function.

Session Sorting and Status

Sessions in the session queue are sorted by date and time of generation and are grouped in different lists according to their status.

Possible statuses are as follows:

* new and not yet processed

The Tran. and Screen fields in the display show how many transactions and screens, respectively, the session contains.

* held in the session queue because of errors in transactions (Errors in sessions)

Transactions that contained errors are aborted; all correct transactions are processed. The Tran. and Screen fields in the session display show how many incorrect transactions were found in the session.

You can restart a session and correct the erroneous transactions with one of the interactive execution modes offered by the batch input system. For more information, please see Correcting a Session.

* processed

For further information on a session that has been successfully run, you can display the log generated by the session. All completed sessions generate a log. You cannot run a completed session a second time.

Only sessions that were generated with the KEEP option are held in the queue after processing. Other sessions are deleted after they are successfully completed.

* in generation

You will usually see this status only if you happen to display the queue while a session is being generated (entered into the session queue).

You can also encounter this status if a system failure has interrupted the generation of a session. If you suspect that a session has been interrupted, please see Releasing and Restarting an Interrupted Session for more information.

* in process

You will usually see this status only if you happen to display the queue while a session is being run.

You can also encounter this status if a system failure has interrupted the execution of a session. If you suspect that a session has been interrupted, please see Releasing and Restarting an Interrupted Session for more information.
read more...

Batch Input Sessions : Processing Sessions Automatically

Use

In most cases, batch input sessions can be processed automatically. It is not necessary for a session to wait until a system administrator explicitly starts the processing of the session.

This section explains how to have sessions started automatically soon after the session has been generated in an R/3 System.


Prerequisites


The ABAP program RSBDCSUB must be scheduled as a periodic job in the R/3 background processing system. RSBDCSUB checks for and starts any batch input sessions that have not yet been run. It schedules such sessions for immediate execution in the background processing system.

Procedure

Schedule RSBDCSUB to run periodically in one or more background jobs.

If you have regularly scheduled batch input runs, you can schedule separate jobs for each of the scheduled data transfers. The start time for the RSBDCSUB job can be set according to the batch input schedule. And you can use a variant to restrict RSBDCSUB only to the batch input sessions that you expect.

With RSBDCSUB, you can use all of the selection criteria offered on the batch input main menu to select sessions to run:

* session name

* date and time of generation

* status: ready to run or held in the queue because of errors

Result


Batch input sessions are started automatically rather than by hand. The RSBDCSUB program can be set up to start all sessions that arrive in an R/3 System, or it can be fine-tuned to start only batch input sessions that you expect.
read more...

6.07.2009

SAP WAS (Web Application Server) - Overview

Introduction

Enterprise Resource Management Technology is evolving at a rapid pace with professional business applications increasingly demanding a highly scalable, reliable infrastructure that can support open Internet standards, off the shelf. A Web Application Server serves all these purposes and delivers proven scalability and performance. It also supports Web technologies and open standards, such as HTTP, eXtensible Markup Language (XML), and Java (J2EE). SAP Web Application Server (SAP WAS) is a platform for efficient development and allows you to implement Web applications. SAP Web Application Server is a crucial component of mySAP® Technology platform. It also paves the way for implementing "Web services". WAS supports all releases of mySAP.com components (including ABAP language), any Java 2 Enterprise Edition and .NET platform. This article concentrates on using SAP WAS with Java components.

Overview of Business Server Pages (BSP)

SAP Web Application Server enables new Internet paradigms to be combined with the transactional operations of ERP. SAP supports the development and operation of both Java 2 Enterprise Edition (J2EE) and ABAP-based Web applications and services.

The custom development of such applications start with the creation of an environment, which provides a set of carefully matched tools to support various applications, known as Web Applications Builder. It is an object-oriented, repository-based development environment using ABAP and/or JavaScript.

It supports the complete development and lifecycle of enterprise applications, and allows a user to develop new kind of enterprise web applications known as BSP applications. The core parts of these applications are the Business Server Pages (acronym BSP) and MIME (Multipurpose Internet Mail Extensions) objects. The concept behind BSP is similar to that of ASP (Active Server Pages) or JSP (Java Server Pages) documents that can contain code and HTML, all of which is compiled by the server upon request. You have the choice whether to use ABAP or JavaScript in your BSP documents.

SAP’s Web application Server assimilates conventional Web technologies with new ones like Web Dynpro for the presentation logic of professional business web applications. In order to implement BSP Applications, it is important to gain an understanding of the SAP Web Application Server.


In this 7 article tutorial we will cover subjects such as:


* Architecture
* Features
* Versions
* Introduction to BSP's (Business Server Pages)
* Creating your own BSP's
read more...

SAP FTP - How to

CALL FUNCTION 'FTP_CONNECT' DESTINATION
RFC_DESTINATION
EXPORTING USER = USER PWD = PASSWORD ACCT =
ACCOUNT HOST = HOST
TRACE = FTP_TRACE GUSER = GATEWAY_USER

GPWD = GATEWAY_PASSWORD GHOST =
GATEWAY_HOST
IMPORTING HANDLE = HANDLE ERROR = CERROR

EXCEPTIONS SYSTEM_FAILURE = 1
COMMUNICATION_FAILURE = 2.
read more...

SAP Mobile Engine Architecture - seven components

Component 1 - Interface

SAP Mobile Engine accepts mobile device user instructions through a standard built-in web browser (Internet Explorer, Netscape Navigator, Opera etc.). This web browser can be used to access enterprise portals. It is also known as the front end of the mobile device. The native interfaces are the default user interfaces of a mobile device, which use J2 Micro Edition for connecting to enterprise system.

Component 2 - Mobile Engine Server

It is also known as the local server and contains server components, which form the first layer of back end components. They ensure smooth flow of data exchange between the business logic of the mobile application and user. It includes Servlet Engine, which acts as a processing environment.
Component 3 - Business Logic (Programming Models)

SAP Mobile Engine supports different programming models that provide the business logic of the enterprise to mobile applications. The business logic implemented in the mobile device should be parallel to the enterprise business logic to maintain consistency of the business transactions.

SAP Mobile Engine supports programming models such as MicroITS (a standard Internet Transaction Server flow logic service), JSP (Java Server Pages) and offline browsing. You can also implement a customized model that suits your requirements.
Component 4 - Mobile Engine Public Interface

Public Interface is the final back-end layer in the Mobile Engine architecture in mobile devices. It is responsible for security and synchronization of data. This is the first layer of the mobile device that establishes communication with the SAP system.

In order to deploy a successful mobile solution, the SAP enterprise system should also contain components that are as follows:

Component 5 - Mobile Engine Synchronization Layer

A synchronisation layer is implemented to reduce the redundancy of the data in the SAP database. This layer works in tandem with the synchronization layer of mobile device to maintain data consistency and data integrity.
Component 6 - Mobile Engine Deployment

As a part of implementing Mobile Engine solution, the SAP system also incorporates a deployment console. This console helps in managing various mobile devices, which may work concurrently with the SAP system. Figure 3 shows the SAP system components for a Mobile Engine solution.

Component 7 - Web Gateways

A Web Gateway is the common interface between the mobile device and the SAP system. This gateway acts as a passage for all data exchanged between the SAP system and the mobile device. It establishes communication between the mobile device and enterprise system.
read more...

SAP Mobile Engine Architecture

The objective of a Mobile Engine is to provide mobility to enterprise systems. In a mobile enterprise, the users work remotely, which requires a mediator for establishing communication between the mobile devices and the enterprise system. Hence, Mobile Engine architecture concentrates on providing secure, timely and critical business transactions over a network.

Further to the discussion in section 2.1, Mobile Engine architecture contains basic components, which help in realizing mobile solutions for a SAP system. There are two sets of components, which are differentiated on the basis of their installation. For a successful mobile engine solution, appropriate components should be installed at mobile device and the corresponding SAP system. The mobile device components include:

* Interface
o Browser based
o Native
* Local Web Server
o Servlet Engine
* Business Logic (Programming models)
o Micro ITS
o JSP
o Cached HTML pages (or offline browsing)
o Any other Customized model
* Public Interface Layer
o Synchronization Layer


In the above Figure it displays the way these components are structured to form a Mobile Engine.
read more...