www.sap-career.blogspot.com

What is ERP?

ERP stands for Enterprise Resource Planning.

Enterprise Resource Planning systems integrate all data processes of an Oraganization into unified system.

The key feature of an ERP system is it uses a single or Unified database to store data for the various system modules.

Various Modules which comes under ERP are listed below:

i.Manufacturing
ii.Supply Chain
iii.Financials
iv.CRM
v.Human Resources
vi.Warehouse Management

What is SAP ?

SAP stands for Systems Applicatios and Products in Data Processing.

SAP AG has released SAP R/2 Version initially.The architecture of the R/2 system is Mainframe Architecture.

Later SAP R/3 is released which has different from R/2 architecture.

R stands for RealTime.
3 stands for 3 Tier Architecture.

There are over 120,000 installations at more than 30000 Companies.SAP Products are used over 15 millon People in more than 125 countries.

>>PREVIOUS>>


WHAT IS ALE?


If you are using the Classification system for master data, such as Materials, Customers, and Vendors, in addition to distributing the master data, you will need to distribute the classification data and use the message type CLFMAS. In this example, we’ll focus on distributing the characteristics and class master using message types CHRMAS and CLSMAS, respectively; We’ll communicate these messages to another R/3 system using tRFC, and we’ll learn to configure RFC destinations and R/3 connections. We’ll also discuss monitoring aspects of tRFC and get to know programs that will confirm the status of communications. While configuring the Distribution Model, we need to create new filter objects to distribute only the configuration data created in the Classification system, because SAP delivers certain characteristics with the system that we do not need to transport to other systems.


Step 1: Maintaining the Logical System and the Distribution Model. Let’s create a new LS called CHRCLSR301 that represents the receiving R/3 system.

Here are the steps for configuring the Distribution Model:

• Execute transaction BD64.

• Enter the base LS defined for your client (say, BK1CLNT010). This LS should have been created and should be allocated to the client using transaction SCC4.

• Enter CHRCLSMODL (as an example) for the name of the Distribution Model.

• Click on Create. You will see a hierarchical listing with BK1CLNT010 as the parent and all other LSs, including CHRCLSR301, under it.

• After placing the cursor on CHRCLSR301, click on create message type.

• Enter CHRMAS.

• Repeat this operation for CLSMAS.

• If you want to distribute classes pertaining to, for example, Material and Customers only, then
you have the option of specifying a filter object for message type CLSMAS. One of the object types available is KLART — Class Type. To specify the filter, place cursor on message type CLSMAS under LS CHRCLSR301. Click on create filter object. You will see a pop-up screen with open fields Object Type and Object. Pull down the list of object types (F4), and select KLART. Enter value “001” for class type Materials in the field Object. Repeat operation for object value “011” for class type Customers.


• SAP delivers certain characteristics that are used throughout the system. We do not need to transport (distribute) these to the other R/3 system. We need to use a filter object to restrict the characteristics to perhaps those pertaining to Materials and Customers. Follow the instructions described in the next section to create new filter object types.

Step 2: Creating new filter object types. Filter objects are criteria used for selecting data of a particular message type in order to create the required IDOCs. A filter object type is basically a field on one of the IDOC segments of the IDOC type corresponding to that message type. We first need to identify the field on the IDOC that can be used for filtering data. For example, if we use the field ATKLA (Characteristics Group) to group similar characteristics that we create, then we can use the field to create the filter object type. Upon scrutinizing the IDOC type CHRMAS01, we find that ATKLA is a field on the segment E1CABNM (see Figure 5).

Further:


Figure 5 Defining a new filter object type.


• From transaction SALE Extensions -> ALE Object Maintenance -> Maintain object types (for separate message types), select Execute.

• You will see a pop-up screen for message type. Enter CHRMAS.

• Click on new entries.

• Enter ZATKLA (for example) for Object Type, E1CABNM for Segment Type, 1 for Sequential
Number, ATKLA for Field Name, 86 for Byte Offset (from documentation on IDOC type CHRMAS01), and 10 for Internal Length.

• Save.

Now that we have created a filter object type for use with message type CHRMAS, let’s complete the configuration of our Customer distribution CHRCLSMODL by executing transaction BD64:

• Expand the tree for the CHRCLSR301 Logical System.

• Place cursor on message type CHRMAS.

• Click on create filter object.

• Pull down the menu (F4) on field Filter Object Type, and select the object type that we created—ZATKLA.

• Enter value CUSTOMER in the field Object.

• Repeat this operation and enter MATERIAL in the field Object (see Figure 6).

• Save.


Figure 6 Customer Distribution Model for characteristics and classes.

Note: Menu paths may vary slightly depending on your version of R/3.

Step 3: Creating a CPIC user on target system. To communicate and process messages in the remote system, SAP uses a user ID on the target system. This user ID needs to be of type CPIC. Though the user could be a normal dialog user, a user of type CPIC should be used to preclude performance problems such as “maximum number of logons exceeded.” Ask your Basis administrator to set up this user ID. Ensure that the ID has all the authorizations required to update that system’s databases for characteristics and classes.


Step 4: Maintaining the RFC destination. R/3-to-R/3 communication uses tRFC. RFCs are Remote Function Calls used to invoke function modules for transactional or asynchronous activities, typically on remote systems. The word transactional prefixed to RFC merely indicates that particular function is invoked per logical unit of work, which could be one Material Master, one delivery, or one invoice. SAP tRFC and aRFC (asynchronous Remote Function Call) both have advanced mechanisms to track data packet communications and to maintain status. For example, to ensure delivery of data, tRFCs are “retried” until the calls are successfully completed.


To set up an RFC destination for our interface:

• Execute transaction SM59.

• Place the cursor on R/3 Connections. Click on create.

• Enter the name of the RFC destination, say CHRCLSR301.

• Enter “3” for connection type—this is an R/3 connection.

• Enter a description of the RFC destination.

• Press Enter. You will see a few additional fields appear on the screen.

• Enter the name and system number of the other R/3 server in the field Target Machine.

• Enter logon information such as Client, Language, User ID (the CPIC user ID defined earlier),
and password.

• Save.

• Click on test connection. You will get a list of connection and communication timings for logon and transfer of a certain number of bytes. This does not verify the password entered earlier. If the password is incorrect, you will notice system problems on the target instance.

• Click on remote logon. If you are using a CPIC user ID, there will be no action taken. If it is a dialog user, you will be logged on to the target system. This is only a test (see Figure 7, page 90).


Figure 7 Creating an RFC Destination.


It is important to ensure that the name of the LS and the RFC destination are the same. You can also access this function using SALE -> Communications -> Define RFC destination.

Step 5: Generating RFC port and partner profile. Here we learn how to generate RFC ports and partner profiles for an R/3-R/3 interface using SAP functionality. The port definition is generated based on the RFC destination that we created in the previous step, while the partner profile is generated based on the Customer Distribution Model we created, along with the port generated.


Follow these steps to generate these objects:

• Go to SALE (ALE Customizing) -> Communications -> Generate Partner Profiles.

• On the screen that appears, enter the Customer Model CHRCLSMODL as defined earlier.

• Enter details for receiver of notifications. This is to identify the recipient of workflow messages in case of errors.

• Switch the Outbound Parameters to Collect IDOCs.

• Switch the Inbound Parameters to Background, so there is no overriding by express flags.

• Execute.

• You will see a list of messages confirming the generation of a port and partner profile.


The tRFC port has an internally assigned number. If you browse the partner profile CHRCLSR301 generated in this step, you will notice there are three entries generated for Outbound Parameters for message types CHRMAS, CLSMAS, and SYNCH. The message type SYNCH is for synchronous communications between the two R/3 systems and is used for validation of ALE functions. The port associated with the three outbound parameters’ entries is the port generated in this step.


The objects created in this process must be generated in the client/instance from which the communications are originating.


Step 6: Creating a receiving partner profile on the target system. We must now create an LS and a partner profile for receiving messages from the sending system. This is a mirror image of the sending LS on the target system.


Here are the steps of the process:

• Create a Logical System BK1CLNT010 on the target system.

• Create a partner profile with partner number BK1CLNT010 on the target system.

• Maintain its Inbound Parameters. Create a new entry for message type CHRMAS, with process code CHRM, and processing mode Background, with no express override flag. Create a similar entry for message type CLSMAS, with process code CLSM, and processing mode Background, with no express override flag.

• Save.


Step 7: Distributing the Customer model. The Customer Distribution Model CHRCLSMODL was created on the “sender” system. This determines and dictates the flow of certain message types — CHRMAS and CLSMAS in this case — to other systems. This information has to be communicated to the recipient system as well, so that it can accept and process the inbound IDOCs. ALE provides tools to “distribute” Customer models.


Here are the steps of the process:

• Go to SALE -> Distribution Customer Model -> Distribute Customer Model -> Distribute Customer Model.

• Specify the Customer Model to be distributed — CHRCLSMODL.

• Specify the Receiving Logical System — CHRCLSR301.

• Execute.


You should receive a message confirming the success of the action. Browse the Customer Distribution Model on the target system to see that it has been created correctly.


Working the Interface

Now that we have configured the system for an R/3-to-R/3 interface, let’s examine the methods for executing this interface and for understanding its results. This section will also go over techniques for monitoring the communications and will discuss performance issues related to R/3-R/3 ALE communications.

Sending data. SAP provides standard ALE programs for sending and processing IDOCs. The two programs we are going to use to send data to the target system are RBDSECHR for sending Characteristics Master and RBDSECLS for sending Class Master. Note that characteristics data has to be sent before the Class Master, since characteristics belong to classes — classes are like envelopes for characteristics. As a first step, let’s create the communication IDOCs on the sending system. To do this:

• Go to BALE Æ Master Data -> Classification System -> Characteristics -> Send. This is the same as executing program RBDSECHR or transaction BD91.

• Enter the name of the Logical System — CHRCLSR301 in this case.

• Execute.


If the number of characteristics is large, then you should schedule RBDSECHR as a background job after having defined an appropriate variant. Use transaction WE05 to view the created IDOCs. They should be in status “30” — IDOC ready for dispatch (ALE service). Browse the IDOCs to understand and verify the data.


For the Class Master:


• Go to BALE Æ Master Data -> Classification System -> Class -> Send. This is the same as program RBDSECLS or transaction BD92.

• Enter the class types — 001 for Material and 011 for Customer in this case. Enter the names of classes you want to distribute. Enter the name of the Logical System — CHRCLSR301 in this case.

• Execute.

If the number of classes is large, you should schedule program RBDSECLS as a background job with an appropriate variant. Display the created IDOCs, and browse them to understand and verify the data.

Dispatching IDOCs to the target system. Once you have created the communication IDOCs, the next step is to dispatch them to the target system. This is when the tRFC calls are invoked to connect and communicate to the remote system. Using transaction SM59, test the connection for RFC destination CHRCLSR301 to ensure that the communication channels are open and working.

• Go to WEDI -> Test -> Outbound from IDOCs. This is the same as program RSEOUT00 or transaction WE14.

• Enter the parameters, such as message types (CHRMAS, CLSMAS), partner number of receiver, and date last created.

• Execute.

If there is a large number of IDOCs, schedule program RSEOUT00 as a background job with an appropriate variant. After processing, you should find all IDOCs to be in a status of “03”—Data passed to port OK. Bear in mind that a status of “03” does not necessarily imply that the tRFC communication was successful. I’ll discuss a method of updating this status with the results of the final processing later in this section.

Monitoring transactional RFC. While dispatching IDOCs from one R/3 system to another using tRFC, it is possible to monitor the communications and take appropriate actions to ensure its success. The main tool is the tRFC monitor, which can be accessed via BALE -> Monitoring -> Transactional RFC. This is the same as executing transaction SM58 or program RSARFCRD. Enter the period and user who initiated the RFC. This log displays only RFC calls that had an error. If there are entries in the log, you can analyze them by reading the system logs and dumping analysis for that period using transactions SM21 and ST22 successively. Carefully analyze these errors to take the correct action. The R/3 Connection may not be active, or the user may not have the necessary authorization for creating entries in the target system. If the problems are other than certain mandatory settings, most RFC transactions should get processed within a small period of time. In case of errors in communication, you may find several jobs in the Job Overview (transaction SM37) with a prefix ARFC. These are normal, since the system is scheduling jobs to reprocess the RFC transactions. However, an excessive number of such jobs could bog down the system, since all batch processors would get flooded, resulting in a repetitive loop causing more jobs to be created. The status records of RFC calls sent from the system are stored in table ARFCSSTATE, while those of RFC calls on the receiver system are stored in table ARFCRSTATE.


Processing IDOCs on the target system. When the IDOCs arrive on the target system from the host machine, they are created with a status of “64” — IDOC ready to be passed to application. This is because we chose the option of “background” on the target system, rather than processing them immediately. We now need to run a program that will process these IDOCs and post the data to the application. To do this:

• Go to BALE -> Periodic Work -> ALE Inbound IDOCs. Choose the radio button for “64” — IDOC ready to be passed to application. Execute. This is the same as executing program RBDAPP01.

• In the panel displayed, enter parameters such as message type (CHRMAS and CLSMAS in this case), creation date, or IDOC numbers. Execute.

• A list will be displayed indicating the status of the processing.


Also check the status of the IDOCs, using transaction WE02 or WE05. All IDOCs must have a status of “53”—Application document posted.


If workflow has been set up, you will receive work items in your inbox in case of errors. There you can edit the IDOCs if the errors are related to data and then reprocess them. However, in case of application errors, you can check the logs to determine the cause of these errors and take remedial action.


The necessary steps include:

• Execute transaction SLG1.

• Enter CAPI for Object (Classification system) and CAPI_LOG for Subobject. If necessary, enter time restrictions and user information. Execute.

• You will see a display of errors pertaining to characteristics, and you will also see log messages for all successful class (CLSMAS) transactions.


In case of errors due to system availability, deadlocks, or temporal data problems, it is possible to schedule program RBDMANIN in the background to reprocess the IDOCs in a status of “51”

— Error: Application document not posted.


How does the sending system know that the tRFC calls to the remote system were successful? There is a program you can execute that collects information about the result of the tRFC calls on the remote system and reports the information to the host client.


To do this:

• Go to BALE -> Periodic Work -> Check IDOC Dispatch. This is the same as executing program RBDMOIND or transaction BD75.

• Enter the IDOC creation date and the number of IDOCs after which the process can be committed, say 100. This implies that after checking the status of 100 IDOCs, the program will update its status.


If the tRFC calls were successful, the aforementioned process should update the status of the IDOCs dispatched to “12” — Dispatch OK.





>>NEXT>>



1 comment:

Anonymous said...

Its like you read my mind! You appear to know a lot about this, like you wrote the book in it or something.
I think that you could do with a few pics to drive the message home a bit, but other than that, this
is great blog. A fantastic read. I'll certainly be back.

Also visit my web blog; bmi calculation

www.sap-career.blogspot.com