WHAT IS ALE?

Application Link Enabling (ALE) is a set of business processes and tools that allow applications on different computer systems to be linked. This can be done between different SAP systems as well as between SAP and non-SAP systems. In a single SAP system different applications are integrated via a single database (e.g. finance, sales, production, and human resources). However, many companies do not have just one integrated system but a distributed environment with different applications running on different systems. To run the whole business in such an environment, the distributed applications have to be linked. This can be done through Application Link Enabling (ALE). ALE provides distributed business processes that can be used to link the applications on different platforms. There are some ALE business processes delivered in the standard SAP system. Furthermore, there are tools that can be used to change the existing ALE business processes or to implement new distributed business processes. Besides the business processes, there are special ALE services that are required to set up and control a distributed environment. These services include a distribution model, business object synchronization, and tools for monitoring or error handling. ALE is a major part of SAP's Business Framework Architecture. Besides the basis middleware, that provides the communication between components, and the interfaces (BAPIs), ALE business processes and ALE services enable the cooperation of the single components within the framework. That makes ALE the glue of the Business Framework. ALE is Application Link Enabling (ALE) It is the set of tools, programs, and data definitions that provides the mechanism for distributing SAP functionality and data across multiple systems. ALE enables the construction and operation of distributed applications. Its purpose was to overcome the limitations of a single SAP system. A single SAP system that runs on top of one database often does not fulfill the needs of larger corporations, either from a business or a technical perspective.ALE allows the implementation of loosely coupled SAP systems; each of the SAP systems has its own database and is essentially independent from the other systems. ALE allows us to distribute data between different systems and different business processes. WHAT ARE THE BENEFITS OF ALE? With ALE, companies get the opportunity to improve business performance and to solve organizational or technical issues by: Increasing Flexibility: Through distribution you can decentralize your business, enabling local units to operate independently from each other. This flexibility enables the local units to return better business results than in a centralized environment. They have the necessary flexibility to optimize business processes in different organizational units and can ensure that information systems can handle the speed of change in rapidly expanding markets. Distribution allows a high level of freedom, provided that this level of freedom has been clearly defined.

On the other hand, some companies, that already have a distributed organization with different computer systems in the local units, have the opportunity to link their units through ALE business processes. This enables them for example to provide a 'one face to the customer' approach. Another area that can benefit through ALE are virtual organizations (partnerships between independent companies, joint ventures and mergers and acquisitions). Of course, in many cases an integrated solution based on a single system is not possible at all. Some applications used by a company cannot run on the same computer system. This includes legacy systems or complementary software. It may also be possible that a company uses different SAP industry solutions or specific country solutions, which do not run on the same SAP System. If these applications run on different systems, they cannot be linked by a central database but have to use a special integration mechanism like ALE. In this way, ALE also links SAP Core Systems to other SAP components like CRM, Business Information Warehouse or APO. Reducing Costs: Besides the benefits of having an improved flexibility in setting up the whole business processes, ALE may also reduce costs, in particular costs of upgrading. If the whole business is run on one integrated system you have to upgrade the whole system, even if only one part of your company (e.g. human resources) requires an update. So the entire company is affected by the upgrade project and all users have to be trained for the new release. Within a distributed environment with release independent interfaces, like those provided by ALE, you can focus the upgrade project on that part of the company that has to be upgraded. The other parts of the company are not involved and need no training. This can save a lot of money. Furthermore, existing investments are protected. Another cost factor for distribution might be communication costs. For an overseas connection, it can be more expensive to provide online access to one central system (T1) than to connect distributed systems to each other (64K line). Increasing Security and High Availablity: There might also be some technical reasons for distributed systems. If some parts of the business have special requirements for security of data access (e.g. human resources), this can be set up much safer on a standalone system, which is, however, linked to other parts of the company through distributed business processes. A similar example is high availability. High availability is usually required by the operations part of the company (production, logistics), but not by other areas (e.g. financials, human resources). In a distributed environment high availability can be set up for specific parts of the environment instead of for the whole business. This can also reduce costs.In a distributed environment, you cannot decrease the overall workload of the systems but you can separate the user workloads on different systems. Through this scalability you can improve performance. Another benefit of distributed systems is that if a technical failure occurs on one system, all other systems continue to operate. Only a small part of the business is disrupted by the error. On one central system such an error would disrupt the entire business.

WHEN SHOULD ALE BE USED? Besides the benefits of ALE there are also reasons not to distribute: The functional scope in a distributed environment is restricted. Not all functionality that is available in an integrated SAP system can be used with distributed systems in the standard yet. Although ALE provides tools to create new ALE business processes or to enhance existing business processes, this does involve additional expenditure. Each company needs some organizational standards and data harmonization. In a distributed environment, less standards are required than on a single integrated system. However, in a distributed environment the maintenance of the standards and the data harmonization is more difficult than on a single system. The administration of decentralized systems is more expensive. Support and service costs for hardware and software in decentralized systems are higher than these costs in a single centralized system.

ALE should be used in a company if the benefits of ALE for this company outweigh the reasons against distribution. For this you always need to carry out a company specific investigation, in which you also should consider the culture of the company. ALE is good for some companies, but not for all.

WHAT IS THE RELATIONSHIP BETWEEN ALE AND MIDDLEWARE? There are many such messages, the most common of these include a customer sending a purchase order message to a vendor, or a vendor sending an invoice message to a customer. Classic EDI is mainly restricted on the exchange of transactional data, no master data or configuration data. In most cases, EDI replaces the transfer of paper copies of these documents. Via the messages ALE business processes can be implemented between business partners. The EDI messages also use the ALE services. For the communication between different types of systems special EDI messages are defined as standards for inter company communication. There are many standards for these messages - in the United States, the ANSI X.12 standard is the most prevalent, in Europe, the UN/EDIFACT standard is used. For sending EDI messages the information has to be converted into an EDI standard. With SAP systems this is done by EDI subsystems. This conversion is the only difference between EDI messages and other messages used in ALE business processes. The processing of these messages on the SAP System is the same as the processing of other ALE messages. WHICH ALE BUSINESS PROCESSES ARE AVAILABLE? ALE business processes are integrated business processes that run across distributed systems. This can be two different SAP systems, links between SAP and non-SAP systems, SAP and Web-servers (Internet Application Components) or SAP and desktop applications. The links between the systems may be loosely (asynchronous) or tightly (synchronous) coupled. These business processes are release-independent and can run between different release levels of the systems. Many SAP applications offer ALE distribution processes, for example Master Data Replication, Accounting, Logistics and Human Resources. WHEN SHOULD SYNCHRONOUS OR ASYNCHRONOUS LINKS BE USED? When distributed applications are linked by ALE business processes, the question often arises as to how tight the link should be. Synchronous and asynchronous links have both advantages and disadvantages: Synchronous links have the advantage that the sub-process on the server can return values to the sub-process on the client that has started the link. Problems with synchronous links occur if the communication line or the server is temporarily not available. If this happens, the sub-process on the client can not be finished (otherwise there would be data inconsistencies). (Example: There is a logistics system and a financial system. Every stock movement in logistics has to be posted in the general ledger of the financial system. If the link between logistics and finance is synchronous, no stock movement can be recorded in the logistics system if the communication line to the financial system is down.). Because of this, synchronous links are usually used if the client only wants to get some data from the server and the sub-processes on the server do not have to write any data to the database.

With asynchronous links the sub-process on the client can be finished even if the communication line or the server is not available. In this case the message is stored in the database and the communication can be done later. The disadvantage of asynchronous links is that the sub-process on the server can not return information to the calling sub-process on the client. A special way for sending information back to the client is required. In addition, a special error handling mechanism is required to handle errors on the receiving side. Asynchronous links are used if a synchronous link is not applicable. For the problems with sending return information to the client and with error handling there is some support from the ALE services.

WHY DOES SAP USE ALE INSTEAD OF DATABASE REPLICATION OR DISTRIBUTED DATABASES? Database replication is another possibility for doing business object synchronization. However, there are some major disadvantages with database replication. At the moment database replication is database dependent and release-dependent within one database. This makes database replication impossible for the use with non-SAP systems and even for the replication between SAP systems, you have to make sure that all systems are running on the same SAP release and the same database release of a single database vendor. Furthermore, with database replication you cannot do things like field conversions or version changes. ALE does not have these shortcomings because it offers application driven data replication independent of the underlying database. Another technology, distributed databases, is no alternative for ALE at the moment, either. There are some good results of distributed databases available, but the performance is far from sufficient for using it with larger applications like SAP. HOW CAN I SERIALIZE IDOC PROCESSING? There are various procedures for processing IDOCs in a serialized way that is to process them or transfer them to the application in a certain sequence. Depending on your respective requirements, one of the methods proposed in note 752194 may be suitable for the required purpose. DIFFERENCE BETWEEN OPEN SQL AND NATIVE SQL? Native SQL allows you to use database specific. SQL statements in an ABAP program, this means that you can use database tables that are not administered by the ABAP Dictionary, and therefore integrate data that is not part of the R/3 System. Open SQL consists of a set of ABAP statements that perform operations on the central database in the R/3 System. The results of the operations and any error messages are independent of the database system in use. Open SQL thus provides a uniform syntax and semantics for all of the database systems supported by SAP. ABAP programs that only use Open SQL statements will work in any R/3 System, regardless of the database system in use. Open SQL statements can only work with database tables that have been created in the ABAP Dictionary. In other words, OPEN SQL is ABAP specific and NATIVE SQL is database specific. I think that open sql is translated to native SQL. Open is much safer but it is somehow limited. Open SQL, native SQL are the interfaces to create the database applications. Open SQL is consistent across different types of existing Databases. Native SQL is the database language specific to database. Its API is specific to the database. Open SQL API is consistent across all vendors Open SQL refers to commands that can be translated into statements of any other SQL language.

For Example: MS-SQL Server and Oracle both are databases. There are two different languages that are used to query these databases and get results. Somme commands exist only in MS-SQL and some only in Oracle. Open SQL is used when we want tp write queries that will work on any underlying database. It contains only those commands which can be translated into any underlying databases command. Open SQL is a subset of native SQL . SQL has been divided into two parts. Open SQL can recognized by the ABAP program. They are 10 SQL statements out of which we use only 5. 1. Select. 2. Insert. 3. Delete. 4. Modify. 5. Update. 6. Fetch. 7. Open Cursor. 8. Close Cursor. 9. Roll Back. 10. Commit. out of which we use only the first 5..... Native SQL Cannot be recognized by the ABAP program. To execute Native SQL Exec SQL. ....... ....... ...... End Exec. as it cannot be recognized by the ABAP we go for Open SQL. Open SQL allows you to access database tables declared in the ABAP Dictionary regardless of the database platform that you R/3 System is using. Native SQL allows you to use database-specific SQL statements in an ABAP program. This means that you can use database tables that are not administered by the ABAP Dictionary, and therefore integrate data that is not part of the R/3 System. As a rule, an ABAP program containing database-specific SQL statements will not run under different database systems. If your program will be used on more than one database platform, only use Open SQL statements. Open SQL Open SQL is a set of ABAP/4 commands which perform operations on database tables. The results of these operations and associated error messages are independent of the database system used. Open SQL thus offers you unified SQL syntax and semantics for different database systems (see Portability). An ABAP/4 program which uses these commands can be run on database systems supported by SAP without modification. Native SQL

Native SQL allows you to perform operations on databases over and above those in the Open SQL command set. In contrast to Open SQL, Native SQL supports not only operations on the local database active in the R/3 System, but also on any external databases. We normally use open SQL, but in some case when you want to say look at the upper case value of an upper/lower case field in a database, you can use native SQL. Native SQL seems somewhat slower and you have to know which databse you will be using it on before coding. For more information type EXEC in the editor and press F1. open sql statements are executed regardless of what database we are using at back ground. Finally this open sql statements are converted to native sql statements by database interface. native sql statements are database provider specific. sql statements of one provider is different from another. we have to adjust according to syntax of each database.

The printing of Acknowledgement Text only on second copy is achieved using the COPIES WINDOW in Smartforms. Define Window ACKN_COPY of the type COPIES WINDOW and Output to Only Copies Copies Differ. Also set the condition in the Condition Tab of the window SFSY-JOBPAGES = 1, so that it only print on the first page of the copy. one main window one or more secondary windows one or more copies windows one or more final windows individual output areas for graphics or addresses

For graphics and addresses the above general characteristics apply as well. However, since they can have no inferior nodes, you only have to consider their elementary characteristics. The main difference between main and secondary window is the page break behavior: While in a main window a page break automatically occurs as soon as the end of the window is reached, in a secondary window the remaining output is truncated; there is no page break. The window types final window and copies window have the same characteristics as a secondary window. Final windows are processed only after all the nodes in the tree have been processed. Copies windows can be used to explicitly print a particular content only on the copy or only on the original. Append structures in tables, what happens when version is upgraded ?

1.

Whenever your going for upgradation append structures and exits will not be copied. You have to do it manually. 2. At time of upgradation all exits and changes in SAP tables are overwriteen by SAP default.than you have to rewrite all changes by SE95 after upgradation. 3. If You Create Append Structure By Customer Namespace then At The Time Of Upgradtion It is treated As Customer apeen Structure.It is maintained automatically by SAP. 4. But If you Do not maintain Customer namespace Then Conflict Occur And you Have to modify it yourself. 5. if you create the Append Structures and the fields according to the SAP naming standards (i. e. use the name for the Append Structure, what the system provides, field names should start with ZZ* or YY*), than nothing will happen after upgrade. All appends, fields and the data in them will stay there. This is from SAPHelp: "The customer creates append structures in the customer namespace. The append structure is thus protected against overwriting during an upgrade. The fields in the append structure should also reside in the customer namespace, that is the field names should begin with ZZ or YY. This prevents name conflicts with fields inserted in the table by SAP. The new versions of the standard tables are imported after an upgrade, and the fields, foreign key definitions and search help attachments contained in the append structures are added to the new standard tables at activation."

2.

Eric is absolutely right,,the answers u got from some people ae not right.. I am sending you the se line s from the most trusted ABAP library along with the link where you can find all info about append structure..

The new versions of the standard tables are imported after an upgrade, and the fields, foreign key definitions and search help attachments contained in the append structures are added to the new standard tables at activation. http://help.sap.com/saphelp_nw2004s/helpdata/en/cf/21eb61446011d189700000e8322d00/content.htm You use the Modification Assistant to modify delivered classes and interfaces and transaction SPAU to adjust them during upgrade or import of a Support Package. http://help.sap.com/saphelp_nw2004s/helpdata/en/60/d6ba5aceda11d1953a0000e82de14a/fr ameset.htm

Using Variables for Date Calculations Prerequisites To use a selection variable for date calculation, you must have defined a date field as a selection criterion or parameter in the relevant program. PARAMETERS DATE LIKE SY-DATUM. Procedure To assign a date calculation variable to an existing variant: 1. In the initial screen for maintaining variants, choose the appropriate variant.

2. Select the Attributes field. 3. Choose Change.

The attributes screen for the selected variant is displayed.

4. In the Selection Variable column, press F4 and choose a type of selection variable. The display window
shows the possible types for the selected field.

5. 6. Select type D for dynamic date calculation. 7. In the Variable Name column, choose the F4 help. All possible date calculations are displayed. 8.

9. Select an entry and choose Choose.

If necessary, enter the required values. To subtract days, you must enter them in the format of a number with a minus sign in the last position (for example 10-). Note that you cannot change the proposals in the list, nor can you add new proposals. Here you can also specify the selection options for the date calculation.

10. Save your entries.

You return to the attributes screen.

11. Save the attributes.

Result You have assigned a variable to a variant for date calculation and saved it. Note that after choosing the selection variable, you must save the attributes again on the attributes screen. You can choose Selection Options on the selection variable screen to make further specifications for date calculations