Config Detail
[ Up ]

Home

Before you can commence with the ALE configuration the following issues need to be resolved.

Which scenarios?

An investigation needs to have been completed on the business requirements and these then need to be mapped to the existing ALE scenarios. If the requirement is there AND the scenario exists an ALE solution could then be offered to the business. If it entails the development of an ALE solution then the costs of the development need to be investigated.

Control Data Implications

Check that the control data that is required to be in sync between the systems, for each of the ALE scenarios, is actually in sync. I.E. ALE requires that certain control data be the same for both the sending and receiving clients.

Other Master Data Implications

Certain ALE scenarios, when implemented, imply that other scenarios need to be implemented as well. E.g. cost and profit centers.

Distribution Strategy

Different distribution strategies are supported:

1. One option is to maintain all data centrally and then to distribute it.
2. Another option is to create the master data locally. There is then always one maintenance system for each view. After the master data has been maintained it is then transferred to a central management system and is distributed from there as required.

Figure 1: Distribution Strategy Options

A decision has to be made as to what strategy should be adopted for each of the required scenarios.

NOTE: Some ALE scenarios make use of direct table updates to input the data on the receiving side, as opposed to making use of std SAP transactions. This implies that no change pointers will be generated for Option B, make it quite unfeasible. It may also imply inconsistencies across clients. Eg. Cost centers can be deleted, yet there are transactions posted against them.

Information Distributed

The business needs to indicate clearly what data is required to be distributed and what data is not. The ALE administrator needs to ensure that all the fields that are required to be distributed are available for distribution in the applicable IDoc for that ALE scenario.

If this is not the case then an extension is required for that ALE scenario. (For any ALE development or extension please follow the ALE Scenario Development Procedure)

PS: This is not a trivial exercise. Allow for at least 2 weeks to complete. See development section for the detail.

Field conversion

Do any of the fields need to assume different values when being distributed? This needs to be clearly documented by the user.

If so the ALE administrator needs to identify where the applicable rule would be most suited, on the inbound or the outbound side. He also needs to be aware of the conversion rule functionality to ensure that the requirement is within the bounds of the functionality provided for.

Does the required data need to go to a certain client based on certain information contained in the IDoc? If so, filters need to be defined and documented. The users need to specify this requirement in detail.

The ALE administrator needs to ensure that that particular field is available, as a filter object, for the ALE scenario in question, otherwise he will need to add it.

Transfer Initiation Strategy

2 options are available for certain of the ALE scenarios:

The ALE administrator needs to check that change pointers exist for the required ALE scenario, as all of them are not available. If a change pointer is not available then one needs to be developed (Not documented anywhere - Would require SAP specialist help)

Mass processing

The number of IDocs that are to be created influences the settings made in the partner profiles for the various message types. The users need to give a clear indication of the volumes, frequency and timings of these bulk creations.

Various jobs need to be scheduled to process IDocs collected on the outbound side as well as to process them in the background on the inbound side. These settings will be defined in a separate document detailing the ALE performance tuning options and settings.

Serialization

Is there a need to implement this feature? Does it matter if an IDoc that was created after 1 IDoc is processed on the receiving side before the first one? If so, the ALE administrator needs to implement this feature. Areas where this may be important is for the transaction scenarios, where the ORDERS message must get to the receiving system prior to an ORDCHG coming through for that same order.

ALE performance

IDocs are fundamental to Application Link Enabling; optimal performance in ALE processing is synonymous with optimal performance of IDocs.

In ALE processing IDocs are:

You can optimize IDoc handling in one or more of the following ways:

These settings will be defined in a separate document detailing the ALE performance tuning options and settings. They are also documented in the Detailed ALE Config Guide.

Error notifications

Who is going to receive the error notifications of each of the scenarios, if at all? By default we suggest the ALE administrator, but if an applicable person, in the business, has the required skills and is willing to assume the role, the functional errors can be split and forwarded to that person.

The ALE administrator would then need to set up the applicable tasks and positions, as well as perform the required configuration to enable it.

If it is decided not to implement the workflow error notification functionality the ALE administrator would need to continuously monitor WE05 for errors on each of the applicable clients.

2 Neat ways of implementing more proactive fault reporting would be to implement either of the following:

Please ADD any comments to our Guest book, otherwise READ through it if you wish...

This Web Site was created by Kevin Wilson  and Johan Delport

Last update: Tuesday, October 27, 1998