Google+ SAP CRM Middle ware Data Load and Monitoring - SAP ABAP

SAP CRM Middle ware Data Load and Monitoring

With SAP CRM Middle ware data load and monitoring you can load customizing and business objects from SAP R/3 to SAP CRM.Often a customizing load is started earlier than business objects are loaded.Typically you will want to load objects in an outlined sequence, e.g. when downloading customer material information from SAP R/3 to SAP CRM, you must load enterprise companion and materials masters before you can start the load for buyer-material-data.To start out an initial load go to SAP Menu-Structure and Know-how-Middle ware-Data Exchange path shall be followed.

Initial Load


The objects to be exchanged between CRM and SAP R/three systems may be filtered utilizing filter criteria.Filters for the initial load are additionally used for the delta load from the SAP R/3 system. For the preliminary load towards the SAP R/3 system, there is no filtering of the load objects.Filter settings, that are saved in desk SMOFFILTAB, check with table fields. The filter for business objects are predefined (saved in table SMOFFILFLD) whereas filters for customizing or condition objects could be set on existing fields.Filter choices enable the filtering of business objects at the supply, on the goal, or at both the supply and the target for business objects. Nevertheless, enterprise data are usually filtered at the source. Customizing or situation objects can be filtered at the supply only. Saving a filter entry triggers the automatic transfer to the Plug-In in SAP R/3.

The transaction to specify the filter criteria is found underneath Structure and Expertise- Middle ware-Data Exchange-Object Management-Business Objects / Customizing Objects / Situation Objects.

The transaction to start out the initial load could be discovered at Structure and Know-how- Middle ware-Data Exchange-Preliminary Load-Start.

While there are no restrictions for repeating knowledge transfers from SAP R/3 to CRM, data transfers from CRM to the consolidated database follow a unique logic. To keep away from inconsistencies between the consolidated database and cell application databases, a repeated initial data switch from CRM to the consolidated database is prevented. If you are positive that no Cell Purchasers have been provided with information or that no data might be extracted again, then a repeated preliminary data transfer from CRM to the consolidated database can be carried out. To do this, you could change an entry in table SMOFINICUS (for extra information, go to the SAP Library).The transaction used to observe the preliminary load is under Structure and Expertise-Middle ware-Knowledge Change-Preliminary Load-Monitor Objects.

The information sent from the SAP R/3 system will be discovered within the inbound queue in the CRM Server (transaction SMQ2). The data will likely be saved in the outbound queue in the SAP R/3 system provided that the connection has been interrupted or the parameters have been set specifically to do that (transaction SMQ1).It's also doable to use the Middleware Portal beneath Architecture and Expertise-Middle ware-Monitoring-Central Monitoring-Middleware Portal.



The figure contains a screen shot of the Initial Load monitor.Often all site visitors lights ought to be green. If an Preliminary Load remains to be operating, the site visitors lights show the status Running (yellow light). In two instances, the monitor reveals the status Ready:
The dad or mum objects aren't yet loaded. In this case, the Initial Load of the mum or dad objects have to be carried out first. As soon because the Initial Load of the guardian objects has finished successfully, the object with the standing Waiting are loaded automatically.
The variety of objects for which Preliminary Load was started is greater than the variety of out there system processes. On this case, the out there processes are used for the Preliminary Load and the remaining objects are set to the status Waiting. These objects are loaded routinely as soon as system processes are available.

The determine provides an outline of message monitoring capabilities in an SAP CRM system environment.In this course the CRM Server tools and the R/three instruments are discussed. The course mySAP CRM Mobile Gross sales and Service covers the monitoring of the cellular shoppers and the communication sation (It displays information on individual classes between a cell client and the CRM Server, in addition to statistics on the data exchange for every site).

The Show BDoc Messages perform (transaction SMW01 or Message Stream ? Display BDocs messages).The Middle ware Trace perform (transaction SMWT or Message Flow-Show Middle ware Trace).Inbound and outbound queue monitoring (transaction SMQ2 or Queues-Display Inbound RFC Queues, transaction SMQ1 or Queues-Display Outbound RFC Queues).The monitoring of the tRFC connections (transaction SM58 or Transactional RFC-Display Transactional RFC Requests) is a regular program used to observe connection problems.

The info loads with SAP R/3 methods can be monitored utilizing transactions R3AM1 or Information Trade-Monitor Objects.In SAP CRM a common Monitoring Cockpit is available. Architecture and Know-how-Middle ware-Monitoring-Central Monitoring-Monitoring Cockpit (SMWP)
The Show BDoc Messages function lists all BDoc messages (transaction SMW01). It displays the
following:
  1. The BDoc ID and BDoc kind, the BDoc state, the circulation context, the queue identify, the date and time when the BDoc message was despatched.
  2. The stream hint, the info and error segments, the service in which the error occurred (last service reached), the recipient record.
  3. The succession of BDocs if a cell scenario is in place
The Unique BDoc represents the primary sBDoc being created (S-1). S-1 is mapped to messaging BDoc M-2, which is written to the CRM database by the validation service. M-2 shouldn't be displayed. The validation service then creates messaging BDoc M-three, the Reference Bdoc, which represents the predecessor of the BDoc in display, synchronization BDoc S-4. If an error has occurred whereas the M-2 was processed by the validation service, only S-1 is displayed with the error information. The same applies if an mBDoc was created by the R/3 adapter. The Original BDoc is M-1, which will in all probability be displayed alone if there is a validation service error. Successfully processed messages appear with a inexperienced light, these nonetheless in process with a yellow mild,and people with a terminal error situation with a pink light. If a message is in course of and does not get processed within a reasonable amount of time, it's doable to restart the message, view the message content, or discard the message. A BDoc message may be marked as deleted (be aware that deleting BDoc messages may cause data inconsistencies) or processing may be retried.

The consistency of all distributed knowledge and processes is assured even if particular person parts of the integrated system are quickly unavailable. All calls and knowledge transports take place asynchronously through buffers (queues). This ensures that if particular person components can't be accessed, no data is misplaced and no delays happen in the general schedule. There are inbound and outbound queues. qRFC queues are displayed in three steps:
  1. After you specify one or more purchasers, queue names and queue destinations, the transaction SMQ1 or SMQ2 shows a listing of all queues that match the required values.
  2. Next you'll have the option to select specific queues of curiosity and consider further details.
  3. From the detailed view on the selected queues, you can show the queue entries by double-clicking the corresponding queue.
Choose these menu paths for the queue transactions:

Structure and Know-how-Middle ware-Monitoring-Queues-Show Outbound Queues (SMQ1)
Architecture and Expertise ? Middleware-Monitoring-Queues- Show Inbound Queues (SMQ2)

The identical qRFC outbound queue monitoring used on the CRM Server will additionally be used on the SAP R/3 system.If an object is not processed correctly within the SAP R/3 system and an error situation is simply not returned through BAPI parameters, the SAP R/3 system itself should be checked.A doable error state of affairs could be that a enterprise object was changed in a CRM Server application, but the change (delta load) is not received within the SAP R/3 system.In case of errors or lacking information updates within the goal system, you may perform the following steps:
  1. Examine Show BDoc Messages including the middle ware trace information.
  2. Check the outbound queue.
  3. Test the table BDOC_TRACK within the SAP R/3 system (which reveals info on the information dealing with of the R/3 application).
  4. Examine the outbound queue of the SAP R/3 system.
  5. Examine the inbound queue of the CRM system.
As properly as, you want to confirm the RFC vacation spot and the logical system assigned to your web site (in the Administration Console) and the CRM Middleware parameter settings in the CRM system and the SAP R/3 system (for instance, CRMRFCPAR).

Related Posts

No comments :

Post a Comment