ALE Financials 4.6C

Hi,
My company wants to load using ALE financial items to the general ledger from another R3 system.  The goal is to be able to do financial reporting from our main instance including amounts from our other instances. 
It seems that if we use ALE the transaction is closed out on the distributed system and SAP wants payment to be made in the central instance.
We want the distributed instances to make their own payments and only want the ledger to be updated.
Please provide me with some direction.  I'll give points.
Thanks

Hi Guys
I am trying to migrate date of internal orders using LSMW but unfortunately i could not find the OBJECT (object Type) to assign in the system which picks the program automatically in the structure relations.
I appreciate if someone could help me on this as i was not involved in internal order migration but i have done asset data migration couple of times using LSMW.
Cheers
kris

Similar Messages

  • Study material on ALE and IDOCS

    Hi
    If anyone has some study material on ALE and IDOCS ,if you can please send it across to me , it would be very helpful to me .
    My mail id is : [email protected]
    Thanks in advance
    Ankit

    1.     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, 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.
    2. What are the benefits of ALE?
    With ALE companies get the opportunity to improve business performance and to solve organizational or technical issues.
    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 can not 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 can not 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.
    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).
    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 can not 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.
    3. 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.
    4. What is the relationship between ALE and Middleware?
    Electronic Data Interchange (EDI) is a term for the transfer of business messages between two systems. 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.
    5. Which ALE business processes are available?
    IDoc Types - Message Types
    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. The following list gives some examples:
    Master data replication (IDoc Types - Message Types - Master Data)
    - Material
    - Customer
    - Vendor
    - General Ledger accounts
    - Bill of materials
    Accounting (IDoc Types - Message Types -Accounting Business Processes)
    - Links to logistic systems
    - Distributed financial accounting
    - Distributed cost center accounting
    - Distributed special ledger
    - Profitability analysis
    - Distributed profit center accounting
    - Consolidation
    - Treasury
    Logistics(IDoc Types - Message Types - Logistics Business Processes)
    - Reallocation of materials
    - Distribution of sales and shipping
    - Product data management
    - Purchasing contracts
    - Sales and operations planning
    - Warehouse management
    - Links to warehouse control systems
    - Links to production optimization systems
    - Links to transport planning systems
    Information systems (IDoc Types - Message Types - Logistics Business Processes)
    - SAP Business Information Warehouse (BW)
    - Exchange of data between information systems
    - Web reporting
    Human resources (IDoc Types - Message Types - HR Business Processes)
    - Human resources as a single component
    - Payroll results
    - Travel expense accounting
    - Links to time collecting systems
    However, these standard solutions may not fit 100% for a company. There may be differentiation in the business process or a required distributed business process is not supported in the standard. If this happens, ALE provides tools that can be used to adapt a standard ALE business process or to create a new distributed business process.
    6. Which ALE services are available and what do they do?
    To integrate distributed systems you need more than a communication infrastructure and interfaces. Some additional services are required that are provided by ALE:
    Business process harmonization:
    Within system overlapping business processes multiple functions running on multiple systems are involved and connected through multiple interfaces. The processes are combinations of functions (sub-processes) running on the single systems.
    (Example: A business process for customer order management involves functions in sales, manufacturing, warehouse management, finance, and so on. It is possible that the sales functions are carried out on another system than the manufacturing, the warehouse management or the accounting. Furthermore, some information exchange with the customer, a supplier or a bank may be involved in the process.)
    ALE helps to coordinate the whole business process by defining it within a global model. In this model the business rules for the distribution are defined. Via the model the sub-processes get to know which part of the overall process they have to do themselves and when they have to pass the process over to another system. Through this the whole business process gets harmonized.
    Receiver determination:
    For distributed business processes a sub-process on one application (client) has to start another sub-process on another application (server). It is important that the new sub-process is started on the right server. Which server is the right one can not be defined by technical values, it depends on the business content of the process.
    (Example: A sales system forwards customer orders to two different production systems. To which system a special sales order is forwarded depends on the entries in the sales order (this may depend, for instance, on the ordered material or on the customer). One sales order may also be split into two or more different orders that may be forwarded to different production systems.)
    To notify the client which system is the receiver of the communication (server), ALE uses a distribution model. From this model the applications get the information about the right server. There are special ALE BAPIs and function modules available for this. The receiver determination makes sure that the information is sent to the right places.
    Business object synchronization (semantic synchronization):
    If business processes run across distributed systems, they have to share some data to be harmonized. This is data like business information data, master data or customizing data. If this data is changed in any of the distributed systems, other systems have to be informed about the change. There has to be some kind of subscription of the data.
    ALE provides a special service for this data synchronization. This service can detect data changes and distribute the information to those systems that need to know about the change. This service also defines which data is shared. You can determine which fields of a data object shall be common and which fields may vary locally.
    Consistency checks:
    For a business process running across two distributed applications there has to be some harmonization of the sub-processes in the single applications. For making sure that the sub processes are harmonized there are special ALE consistency check tools. These tools help to find and repair inconsistencies. By this it can be ensured that the whole ALE business process works in the right way.
    Monitoring:
    For the monitoring of distributed processes it is not enough to monitor all activities on the single systems. The overall business process has to be monitored. The ALE monitoring services provide detailed information about the communication process, the sub-process on the other systems and its results. Database links are created between the business objects in question on the client and the server. This is especially important for loosely coupled applications with asynchronous links. In this case the server can not give return values back to the client directly so that the ALE monitoring is the only channel for feedback.
    Error handling:
    Another problem with asynchronous communication is error handling. If an error occurs on the server the calling process on the client may have finished already. So the server can not return the error message to the client. A special error handling process required. This process is one of the ALE services. It uses workflow functionality to identify the error and to start the required error handling.
    7. Synchronous vs. asynchronous links?
    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.
    8. Which kind of interfaces do ALE business processes use?
    ALE business processes are integrated processes across distributed systems, requiring interfaces between the systems. These interfaces have to be stable to enable the communication between different releases and to reduce the impact of release changes within the distributed environment.
    In SAP R/3 release 3.0 and 3.1 ALE uses IDocs as interfaces. An IDocs is a data container for transferring messages asynchronously. They are release independent. Since SAP Release 3.1G BAPIs are a new type of object oriented, stable interfaces that can be called synchronously or asynchronously. Asynchronous BAPIs use IDocs as data containers. ALE business processes can use BAPIs as well. In the future new ALE business processes will use BAPIs as interfaces. But the existing IDocs will still be supported. In time, BAPIs will be created with similar functionality to existing IDoc interfaces.
    9. Why does SAP uses 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.
    10. What is the relationship between ALE and middleware?
    For distributed business processes many different services are required. Most of these services are offered by SAP. For some of these services you can also use products that are provided by SAP's complementary software partners or by other companies:
    The communication service for doing the pure communication is usually done via Remote Function Call (RFC). RFC is provided by SAP for most platforms both for synchronous and asynchronous communication. There are other messaging systems for the communication service available as well, like IBM's MQSeries. However, the communication between SAP and the messaging system is still done via RFC.
    For the serialization of asynchronous communication the RFC provides little functionality at the moment. The serialization has to be checked by the application. ALE offers some support to do these checks. The serialization of the RFC communication will be improved in the future. Serialization services are provided by some of the existing messaging systems, but even they can not guaranty a 100% serialization of the communication, since they use RFC for the connection to SAP.
    The monitoring and error handling of the communication is done via services provided by the RFC and ALE. If messaging systems are used for the communication they also offer some monitoring and error handling functionality.
    If a non-SAP system is involved in the ALE business scenario and this system does not understand SAP's BAPI or IDoc interfaces, the data has to be mapped to any interface structure that this system offers. For this mapping SAP does not provide a service but it certifies mapping tools from software partners. These tools are called ALE translator. The most known product in this area is probably Mercator from TSI International Software. The same kind of mapping can also be done by 'EDI converters'.
    Another type of middleware products offer process ware. This is mainly a combination of the communication service, the mapping service and a set of rules for the mapping. Some ALE translator can be used for this as well.
    Receiver determination is one of the ALE services (see above). Parts of this service can also be provided by some of the messaging systems, but you cannot use these systems without using ALE receiver determination.
    For the other ALE services like application monitoring, application error handling, semantic synchronization and business process harmonization, there are no middleware products available as a replacement of ALE.
    ALE is open for the use of middleware products for the distribution, but in most cases the additional middleware is not necessary. In a communication between different SAP systems usually the use of additional middleware makes no sense at all. For the communication between SAP and non-SAP systems there might be some benefits, especially if the middleware is used at the company already. The only middleware tool that is really required if the non-SAP system does not understand BAPIs or IDocs is an ALE translator.
    Check different sites for more information.
    Regards

  • ALE interface programing

    hi experts,
    whtat is ALE and why we r using ALE.please give the
    steps with  example.
      regards,
       cnu

    Check this questions u may get ur answers.
    1.     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, 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.
    2. What are the benefits of ALE?
    With ALE companies get the opportunity to improve business performance and to solve organizational or technical issues.
    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 can not 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 can not 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.
    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).
    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 can not 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.
    3. 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.
    4. What is the relationship between ALE and Middleware?
    Electronic Data Interchange (EDI) is a term for the transfer of business messages between two systems. 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.
    5. Which ALE business processes are available?
    IDoc Types - Message Types
    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. The following list gives some examples:
    Master data replication (IDoc Types - Message Types - Master Data)
    - Material
    - Customer
    - Vendor
    - General Ledger accounts
    - Bill of materials
    Accounting (IDoc Types - Message Types -Accounting Business Processes)
    - Links to logistic systems
    - Distributed financial accounting
    - Distributed cost center accounting
    - Distributed special ledger
    - Profitability analysis
    - Distributed profit center accounting
    - Consolidation
    - Treasury
    Logistics(IDoc Types - Message Types - Logistics Business Processes)
    - Reallocation of materials
    - Distribution of sales and shipping
    - Product data management
    - Purchasing contracts
    - Sales and operations planning
    - Warehouse management
    - Links to warehouse control systems
    - Links to production optimization systems
    - Links to transport planning systems
    Information systems (IDoc Types - Message Types - Logistics Business Processes)
    - SAP Business Information Warehouse (BW)
    - Exchange of data between information systems
    - Web reporting
    Human resources (IDoc Types - Message Types - HR Business Processes)
    - Human resources as a single component
    - Payroll results
    - Travel expense accounting
    - Links to time collecting systems
    However, these standard solutions may not fit 100% for a company. There may be differentiation in the business process or a required distributed business process is not supported in the standard. If this happens, ALE provides tools that can be used to adapt a standard ALE business process or to create a new distributed business process.
    6. Which ALE services are available and what do they do?
    To integrate distributed systems you need more than a communication infrastructure and interfaces. Some additional services are required that are provided by ALE:
    Business process harmonization:
    Within system overlapping business processes multiple functions running on multiple systems are involved and connected through multiple interfaces. The processes are combinations of functions (sub-processes) running on the single systems.
    (Example: A business process for customer order management involves functions in sales, manufacturing, warehouse management, finance, and so on. It is possible that the sales functions are carried out on another system than the manufacturing, the warehouse management or the accounting. Furthermore, some information exchange with the customer, a supplier or a bank may be involved in the process.)
    ALE helps to coordinate the whole business process by defining it within a global model. In this model the business rules for the distribution are defined. Via the model the sub-processes get to know which part of the overall process they have to do themselves and when they have to pass the process over to another system. Through this the whole business process gets harmonized.
    Receiver determination:
    For distributed business processes a sub-process on one application (client) has to start another sub-process on another application (server). It is important that the new sub-process is started on the right server. Which server is the right one can not be defined by technical values, it depends on the business content of the process.
    (Example: A sales system forwards customer orders to two different production systems. To which system a special sales order is forwarded depends on the entries in the sales order (this may depend, for instance, on the ordered material or on the customer). One sales order may also be split into two or more different orders that may be forwarded to different production systems.)
    To notify the client which system is the receiver of the communication (server), ALE uses a distribution model. From this model the applications get the information about the right server. There are special ALE BAPIs and function modules available for this. The receiver determination makes sure that the information is sent to the right places.
    Business object synchronization (semantic synchronization):
    If business processes run across distributed systems, they have to share some data to be harmonized. This is data like business information data, master data or customizing data. If this data is changed in any of the distributed systems, other systems have to be informed about the change. There has to be some kind of subscription of the data.
    ALE provides a special service for this data synchronization. This service can detect data changes and distribute the information to those systems that need to know about the change. This service also defines which data is shared. You can determine which fields of a data object shall be common and which fields may vary locally.
    Consistency checks:
    For a business process running across two distributed applications there has to be some harmonization of the sub-processes in the single applications. For making sure that the sub processes are harmonized there are special ALE consistency check tools. These tools help to find and repair inconsistencies. By this it can be ensured that the whole ALE business process works in the right way.
    Monitoring:
    For the monitoring of distributed processes it is not enough to monitor all activities on the single systems. The overall business process has to be monitored. The ALE monitoring services provide detailed information about the communication process, the sub-process on the other systems and its results. Database links are created between the business objects in question on the client and the server. This is especially important for loosely coupled applications with asynchronous links. In this case the server can not give return values back to the client directly so that the ALE monitoring is the only channel for feedback.
    Error handling:
    Another problem with asynchronous communication is error handling. If an error occurs on the server the calling process on the client may have finished already. So the server can not return the error message to the client. A special error handling process required. This process is one of the ALE services. It uses workflow functionality to identify the error and to start the required error handling.
    7. Synchronous vs. asynchronous links?
    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.
    8. Which kind of interfaces do ALE business processes use?
    ALE business processes are integrated processes across distributed systems, requiring interfaces between the systems. These interfaces have to be stable to enable the communication between different releases and to reduce the impact of release changes within the distributed environment.
    In SAP R/3 release 3.0 and 3.1 ALE uses IDocs as interfaces. An IDocs is a data container for transferring messages asynchronously. They are release independent. Since SAP Release 3.1G BAPIs are a new type of object oriented, stable interfaces that can be called synchronously or asynchronously. Asynchronous BAPIs use IDocs as data containers. ALE business processes can use BAPIs as well. In the future new ALE business processes will use BAPIs as interfaces. But the existing IDocs will still be supported. In time, BAPIs will be created with similar functionality to existing IDoc interfaces.
    9. Why does SAP uses 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.
    10. What is the relationship between ALE and middleware?
    For distributed business processes many different services are required. Most of these services are offered by SAP. For some of these services you can also use products that are provided by SAP's complementary software partners or by other companies:
    The communication service for doing the pure communication is usually done via Remote Function Call (RFC). RFC is provided by SAP for most platforms both for synchronous and asynchronous communication. There are other messaging systems for the communication service available as well, like IBM's MQSeries. However, the communication between SAP and the messaging system is still done via RFC.
    For the serialization of asynchronous communication the RFC provides little functionality at the moment. The serialization has to be checked by the application. ALE offers some support to do these checks. The serialization of the RFC communication will be improved in the future. Serialization services are provided by some of the existing messaging systems, but even they can not guaranty a 100% serialization of the communication, since they use RFC for the connection to SAP.
    The monitoring and error handling of the communication is done via services provided by the RFC and ALE. If messaging systems are used for the communication they also offer some monitoring and error handling functionality.
    If a non-SAP system is involved in the ALE business scenario and this system does not understand SAP's BAPI or IDoc interfaces, the data has to be mapped to any interface structure that this system offers. For this mapping SAP does not provide a service but it certifies mapping tools from software partners. These tools are called ALE translator. The most known product in this area is probably Mercator from TSI International Software. The same kind of mapping can also be done by 'EDI converters'.
    Another type of middleware products offer process ware. This is mainly a combination of the communication service, the mapping service and a set of rules for the mapping. Some ALE translator can be used for this as well.
    Receiver determination is one of the ALE services (see above). Parts of this service can also be provided by some of the messaging systems, but you cannot use these systems without using ALE receiver determination.
    For the other ALE services like application monitoring, application error handling, semantic synchronization and business process harmonization, there are no middleware products available as a replacement of ALE.
    ALE is open for the use of middleware products for the distribution, but in most cases the additional middleware is not necessary. In a communication between different SAP systems usually the use of additional middleware makes no sense at all. For the communication between SAP and non-SAP systems there might be some benefits, especially if the middleware is used at the company already. The only middleware tool that is really required if the non-SAP system does not understand BAPIs or IDocs is an ALE translator.
    Regards

  • ALE Workflow

    We're implementing ALE between our financials server and HR server.
    We would like to set up some sort of monitoring to make sure the IDocs are processed successfully and want to notify users via some sort of Workflow.
    From what I understand, the program RSEIDOCA collects the Idocs based on the status/message type etc.. criteria selected and sends them via SAP Mail to the appropriate people
    And, I need to make sure all the partner profiles have an Agent assigned to them - this would be the person who's notified of errors.
    I'm sure there's a lot left out. Can someone explain ALE workflow? How similar is it to normal workflow used on FI side?
    thanks,
    robert.

    Hi Robert,
    SAP provides std WF for error handling. The link below will give you some useful information to get started. Hope this helps.
    <a href="http://www.asug.com/client_files/Calendar/Upload/ ASUG%20EDI%20IDoc%20Error%20Handling%20Using%20SAP%20Workflow.ppt">IDOC Error Handling using Workflow Presentation</a>
    Cheers
    VJ

  • Error in ALE Service While Creation of Vendor Master

    hi,
    I am using a scenario where a third party system is sending vendor master data to a R/3 system The file is picked up by the file adapter(sender) and mapped to IDOC format, using Idoc adapter (receiver). A Vendor is then created by posting the CREMAS03 IDOC into the R/3 system.
    Everything goes fine till the Idoc comes into the R/3 system. There in BD87(Idoc Status Monitor), getting the "Error in ALE Service" error. When expanded further the specific error is that of "Cross-system company code xxxx does not exist". What is generally the cause of this error and how would I resolve it?
    For those of you who have attended TBIT 40, this scenario is Example 1 - Creation of Vendor Master Data.
    Any help would be appreciated?
    regards,
    SK

    one more thing
    if you want to be sure that you're using the right data
    try to set your system to send the vendor data out
    first - send it from BD14
    and then you'll know which fields do you need
    if you do that take a look at segment E1LFB1M
    and check for BURKS
    Regards,
    michal

  • Issue in Data transfers using ALE for E-Recruiting standalone system

    Dear Experts,
    We have an issue in data transfers using ALE. We are having standalone system where E-Recruiting is maintaind seperately and the version is EHP5.
    When we configured iDoc in Sandbox and its working fine. But when it comes to Dev and Quality servers this is not working fine.
    we have created iDocs using the following filters.
    For Object P: Infotypes 0000, 0001, 0002, 0003, 0006, 0024, 0105.
    For Objects O,S: 1032, Subtype: 0010
    For Object: 1001, Subtype: A003, A008, A012, B007
    For Object O: 1001, Subtype: A002, B002, B003, B012, Tyoe of related object: O,S
    For Objects: C, O, S, Subtype: 1000, 1002, 1028
    For Object:C, Subtype: 1001, Subtype: A007
    When we do the data transfers in Sandbox using PFAL it is transferring the data properly.
    But when we do the same iin Dev and Quality servers we are not able to do it and gettign 52, 51 errors.
    Here we are facing a strange issue. For some Users when we transfer data it is transferring data but with 52 error messgae.
    For some users I am getting 51 error where i could not transfer any data.
    For some users, when we tranfer O, S, and P related data is moving but getting mostly 52 error and all the relationships are not moving here for O,S and properly. But P related CP, BP and NA are getting created successfully.
    It is happening only in Dev and Quality server and that too some users are able to get transferred but not all.
    Where will be the issue? How can we resolve this?
    Any help will be appreciable.
    Thank you in advance.

    Hi Sekhar,
    Have a look over these threads.
    Errors in ALE data transfer to E-Recruiting.
    http://scn.sap.com/thread/1535402    
    BR,
    RAM.

  • ALE logical systems for business service or process

    Hi,
    I am trying to send an IDOC into my R/3 system. It is the same IDOC type that I have sucessfully sent out to parties. All the config is in place for communicating with the system, because I have sent others IDOCs in the past. However, they always were sent from another R/3 business system. They processed sucessfully.
    I am now trying to sending IDOC's from a BPM,as well as, from a business service. They are under the "With Party" section of the directory. These obviously do not have logical systems, so when I try to send the IDOC I get
    "Unable to convert the sender service Purchase_Orders to an ALE logical system", where purchase_Orders being the name of the business serice.
    How can I handle this problem?
    Should I hard code values somewhere?
    Which ones?
    I have read the other posts for the error above, but my situation seems to be different.
    Help!
    Chris

    Hi,
    To solve your problem, here my solution:
    1/ In your Business Process of your ID (configurator), go to menu "Service > Adapter-specific identifier" and in the part "IDoc Adapter", write your Logical System.
    2/ Create this Logical System on your target system (R/3).
    WARNING: XI allows you to used a Logical System for only one service (Business Process). Thus, if you are several interfaces, you must used different Logical Systems.
    Mickael.

  • Why do we create logical systems in ALE?

    Hi All,
            i got this question in interview.
        Why do we create logical systems in ALE?
    Thanks & Regards
    suresh

    Hi
    In addition to above .
    A logical system is used to identify an individual client in a system, for ALE communication between SAP systems. That's why you see a field for 'logical system' in the client master data in SCC4 (table T000).
    /people/udo.martens/blog/2005/09/30/one-logical-system-name-for-serveral-bpm-acknowledgements
    http://help.sap.com/saphelp_nw04/helpdata/en/b5/1d733b73a8f706e10000000a11402f/content.htm
    http://help.sap.com/saphelp_nw04/helpdata/en/69/c24ca94ba111d189750000e8322d00/content.htm
    http://72.14.203.104/search?q=cache:J-uDLyT0w54J:www.topxml.com/biztalkutilities/walkthroughs/SAP%2520Configuration.pdfwhatislogicalsystems+(SAP)&hl=en&gl=in&ct=clnk&cd=5
    http://help.sap.com/saphelp_nw04/helpdata/en/78/217dc151ce11d189570000e829fbbd/content.htm
    http://help.sap.com/saphelp_nw04s/helpdata/en/d7/9c73631d6c11d2a56e0060087832f8/content.htm
    This guide is really good shows step by step procedure.
    http://72.14.203.104/search?q=cache:Xyl0zxpyEXsJ:www.sappoint.com/abap/ale.pdfLogicalsystem(ALE)&hl=en&gl=in&ct=clnk&cd=9
    for one client config
    http://www.sappro.com/downloads/OneClientDistribution.pdf#search=%22Logical%20system(ALE)%22
    Please reward for the same.

  • Logical systems in ALE iDoc

    Hi,
    For exchanging data between two systems(not between two clients of the same system) using ALE iDoc , logical systems should be maintained in both the systems?
    For eg: there are two systems, system A and system B.
    i have maintained the logical systems as SYSA (for system A)  and SYSB ( for system B) in the system A using the transaction 'SALE'. Should this need to be maintained in system B also?
    Thanks & Regards,
    Soumya.

    Hi,
    In both the systems you have to Define the Logical systems,
    but in you assign only one to the client,
    i.e. in system A you assign the Logical Sytem of of A to the Client in SALE
    transaction the same goes for B.
    and you don't need to create a distribution model for both the systems,
    you can create it in one system and send it to the other system.
    Regards,
    Samson Rodrigues.

  • Can We send data from SAP to non SAP using ALE !

    In this case what will be the receiver side configuaration !
    What will be our receiver client !

    Hi,
    We can send SAP to Non-SAP system using ALE technology.
    Ex:-
    Business Connector, VB.NET system can be integrated using ALE technology over TCP/IP connection.
    Regards
    Vijayanand Poreddy

  • Using ale u can send from sap to sap and sap to non sap systems

    hi,
    using ale u can send from sap to sap and sap to non sap systems,
    then what is diff b/w ALE and EDI

    Hello KALYAN KUMAR,
    Application Link Enabling (ALE)
    1.You distribute data using ALE if you want to communicate from one system to one or more other (mostly internal) systems.
    2.ALE transfers data in IDoc format and uses the methods of tRFC for data transfer.
    3.ALE enables the integration of business processes across several SAP or non-SAP systems.
    Electronic Data Interchange (EDI)
    1.You use EDI if you want to exchange business application documents with an (external) partner system (for example, a customer or vendor).
    2. The SAP system sends EDI messages in IDoc format to an EDI subsystem, where they are converted to a universal EDI standard (UN/EDIFACT or ANSI/X12).
    3. This enables communication with non-SAP systems.
        By definition, two partners are involved in the process in an EDI application scenario: The sender and the recipient of an EDI message
    I hope u understands the difference:)

  • Report for Purchase Orders didnt reach target through ALE

    Hi Experts,
    we are sending Purchase Orders to Third party system using XI.
    But some of the orders when we save its automatically  system generating output medium is PRINT so these orders not going through ALE.
    1)Can anyone please tell me why the system is generating PRINT instead of ALE distribution.
    2) is there any report for how many purchase orders created for the day and how many of them gone through successfull using ALE distribution.
    Answer will be rewarded.
    Kiran

    Hi
    Have you configured the PO Output type/messages with the Medium as 'A'(ALE)
    otherwise the system willd efualt take 1(print) as default medium.
    Check the NAST table entries for that date created Output type of PO's
    for all of them the Medium(NACHA) field should be A
    then all will go through ALE
    check them.
    Regards
    Anji

  • Sales Order from one SAP to another SAP system thru ALE

    I am trying to send a Sales order IDOC from one SAP system to another SAP system (basically from DEV to QAS). Will i be able to do this using ALE ? If so, how ? I don't want this Sales order to be posted as PO in QAS. I want it to stay as a sales order.

    hi,
    use BAPI SALESORDERCREATE
    ~linganna

  • Upload data from legacy system to SAP through ALE IDOC

    Hello All,
    I have a requirement where i need to upload the data from legacy system to SAP. So i am using ALE IDOC.
    In my requirement i need to extend the Standard IDOC. I have extended the IDOC and even found the exit for the updation of the extended fields to SAP. My data would be be placed in the application server.
    Can anybody tell me how to retrieve the data and update in the tables for the extended fields.
    Could you please provide a sample program for retrieving data for IDOC.
    Thanks

    Hi,
    You can find the sample code in the following link.
    Re: calling idoc_input_creditor
    Regards
    Sajid

  • Integration of Financials with external systems

    Hi,
    I am strugling with an implementation where the client is not sure if Oracle Financials suits his business processes
    Overview of situation on Hand:
    We do not have the product installed as yet at the client site
    Products of Oracle Financials to be used :General Ledger, Account Receivable, Account Payable, Fixed Assets,India Localization Patch
    Products of Oracle Applications NOT available for use :
    Purchasing, Inventory, Order Management
    (All these areas are being covered by developing a customized Bespoke system)
    1.     Is it possible to use Oracle India Localizations (with regards to the excise functionality, for e.g. claiming of ModVat, the various excise registers that are to be maintained for e.g. RG23 A, RG23C,etc ) in the above situation (without implementing Purchasing, Inventory, and Order Management?).
    2.     Further, while passing the Vendor’s Bills (in Oracle Payables), one of the criteria for PO Matching is to check if the ModVat has been claimed. Is this functionality available in Payables with the India localization patch?
    3.     Does Oracle India localization cater for VAT requirements?
    4.     Is an Open Interface available to transfer Purchase Order data from external systems to Oracle Purchasing tables (which are shared by Oracle Payables the names being PO_HEADERS, PO_LINES, PO_LINES_LOCATIONS, PO_DISTRIBUTIONS, PO_DISTRIBUTIONS_AP_V (VIEW OF PO_DISTRIBUTIONS), PO_RELEASES (Blanket Purchase Orders), PO_LOOKUP_CODES) at transactional frequency? However, if the oracle purchasing module is not being used, can the interface tables of Purchasing be used?
    5.     An open interface (Payables Open Interface) is available in Oracle Payables to import the Invoices from external systems. While importing these invoices, does the system expect to have the Purchase Order data in the PO tables mentioned in the point above?
    6.     Is an Open Interface available to transfer Quantity Received/Accepted data from external systems to PO_line_locations table to enable carrying out of 2/3/4 way matching of Purchase orders with invoices? Can the 4 way mathcing be carried out in AP by just importing Purchase Order data??
    7.     Can the Credit Card Transaction Interface be used for uploading employee expenses / advances settlement (not carried out via credit card) directly from feeder system?
    8.     Is it possible to use Open Item interface (including import concurrent program) even though Inventory module is not being installed ? If yes, then we would like to use this interface for updating Item master from bespoke system..
    9.     Can Auto Invoice API be used to import invoices from feeder system / legacy system (via RA interface Tables) into the Oracle receivable invoice tables? Is order number as column a prerequisite for successful completion of Auto Invoice API?
    10. Where should the Masters be kept....OF of Bespoke
    eg. Employee master, Inventory Item Master etc.
    11. What is the best strategy for keeping the data in Bepoke and OF related to Masters in sync?
    I have got various answers to these questions .....but some seem to contradict each other.
    PLEASE HELP!!
    Thanks,
    Kamana

    Dear Kamana,
    Can you send me the replies given by our other Forum Friends, let me analyze the entire stuff and get back to you with a single consolidated bible for all your questions.
    Gopal

Maybe you are looking for

  • Is there a way to overwrite the ORIGINAL songs with my iTunes library info?

    Hi there, I would like to know if there is a way to overwrite the original songs with my iTunes library info? What I mean is, I have MANY songs that I have transferred to iTunes (and were obviously not purchased from iTunes) and I always put the info

  • Using the time function for formulas.

    i am having alot of trouble adding when making my cells under the time format.  it comes up with crazy results.  i have made certain that the date is none and the time is uniform in all of the cells.  The table is entering under a time and having two

  • J1IFQ Reconcialation of subcon challan

    Dear All, We are encountering the Problem During Reconcilation of Quantity in Subcontracting cycle Received in Multiple GR. The Following steps are followed, 1. We have created a Subcontract PO with BOM Explosion. 2. The Required Components are issue

  • MySQL database overflow??

    I am using a MySQL database which contains data on bankaccounts. For example, person X has 4 accounts. These accounts are listed in a selectbox. By clicking on one of the accounts, the page is refreshed with the account ID. When an ID is set, more de

  • Error message on 'Today' CRM Page

    Has anyone had this error message? Version 2007.1.652.2 Message NPCode Value [E] or CodeType [eventtype] does not exist. Source NetPoint.API Stack at netpoint.api.common.NPCode.getCodeName(String CodeValue, String CodeType, String encoding, String co