Performance and Workflow - Part 5

• 
• 

Details

Category: Workflow

Published on Wednesday, 06 August 2008 01:00

Written by Kevin Wilson

Hits: 11291

Tables

SWWWIHEAD

• Different selections of data of the table SWWWIHEAD take a long time.
• To stop this incorrect behavior of the database you must change the secondary indexes on SWWWIHEAD so that the respective index contains the client (field CLIENT) as an additional first field.
• After this change, the database statistics must be refreshed if necessary.
• Note that the change to the secondary indexes requires that you reconstruct the respective indexes. During this time, you cannot use the workflow system. Make sure that all entries that are no longer required have been archived and deleted.

tRFC and qRFC tables

The system has a very high interface load and/or many tRFC/qRFC entries are in the error status and/or many tRFC/qRFCs wait for their processing

Before you solve the problem, you must make a more precise analysis of the problem.

1. Outgoing t/qRFCs

              Check whether you use tRFC or qRFC:

• Use Transaction SE16 to check how many entries are contained in table ARFCSSTATE.

• Now determine for how many entries field ARFCRETURN is empty in table ARFCSSTATE.These entries stand for tRFCs which have not been processed yet or which encountered errors. Tables ARFCSSTATE and ARFCSDATA are affected here, these tables contain many entries. (refer also to point 5)

• All entries of table ARFCSSTATE, for which the ARFCRETURN field is not empty, come from qRFCs which are either not yet processed or which are in an error status.Here tables ARFCSSTATE, ARFCSDATA and TRFCQOUT are affected by the growth (refer also to 3). (see also 3rd)

1. Incoming t/qRFCs

a) Table ARFCRSTATE contains many entries, it does not matter if these were written by tRFC or qRFC. Find solutions in Note 366869.

b) Tables TRFCQIN, TRFCQDATA or TRFCQSTATE contain many entries. These are qRFC. (Refer also to 4.)

The following describes known solutions. If there is no solution for the situation in your system, open a message under component XX-SER-TCC, SAP will complete this note systematically.

Generally, you should not delete tRFC entries (especially qRFC entries), because, as a result, the applications that the databases use to communicate become inconsistent.(Only some cases mentioned in Note 366869 are exceptions) Apart from that, the following always applies:After deletion you must check and restore the consistency of the databases involved.

2. Known solutions for outgoing (sending) qRFC :

a) Example APO

                        When you call Transaction SMQ1, many queues are on CPICERR. The system writes this error if the data required by the Live-Cache was blocked during execution. Normally, the system post-processes this error automatically (by default every 15 min). If you want to make this post-processing immediately, you can subsequently send the queues from SMQ1 manually. You do not have to mind the sequence of the queues, the qRFC identifies automatically which other queues must be processed in which sequence within the same LUW.

                        However, if no lock but a real CPIC error is the cause for the CPICERR (example: target system not started, destination not maintained in SM59 ..), you must correct the error before post-processing.

a) Example CRM mobile sales

                        In Transaction SMQ1, many entries stand for queues having the name CRM_Site_00....XX in status NOSEND. Generally, these queues have many (> 100) entries, the first date (oldest queue entry) is older than one week.

                        These queues are the queues of the mobile clients.The owner of the mobile client have not logged on to the CRM (CONTRANS not started) from the SMQ1 after the "first date".The system constantly places queue entries into the outbound queue for each individual mobile client, this has the effect that the queues andd thus the qRFC table grow, this is due to the Deltaload from the OLTP and the replication of the data in the middleware.This results in a poorer performance for all qRFC users and above all for the communication to the OLTP System.

                        (The growth per queue depends above all on the quantity of data subscribed for the mobile client.

                        SAP recommends limiting the quantity to the minimum from the beginning.

                        The only solution here:The mobile clients must log on to the CRM and start CONTRANS on a regular basis (at least once a week). CAUTION:If one or more clients are no longer required or have no owner, they must be logged off from the admin station by the administrator.  Temporarily, this actually causes load on the system, however, this causes a consistent removal of the queues.

1. Known solutions for incoming qRFC:

a) CRM: in Transaction SMQ2, queues stand on STOP.

                        Either the CRM application writes this STOP or it is set manually. A short STOP triggered by the application is normal.

                        If, however, the queues stand on STOP for a long time and were not deregistered by purpose in SMQR, an application problem exists. This can either have been caused by a short-term lock of the application object, and a simple reset of the status, and thus processing again, helps.

                        Or a real application error may exist, you can determine the cause by using Transaction SMW01:Select the date according to the queue STOP date, select the corresponding line and choose the 'Error' button. The system displays the application error which has to be solved by the user department. Afterwards you can trigger the queue again from SMW01 via menu Message --> Process --> Retry to process.

                        If you have intentionally deregistered the queue, note that stopping many queue entries for a long time can also affect the performance. You should register and process the queues again as soon as possible.

1. Known solutions for outgoing tRFC:

               Using Transaction SM58 check now for all users which function module is supposed to be processed by the TRFCs:

a) For function modules: 'SWW_WI_*' and a status text indicating an error there is a workflow problem. First check the workflow Customizing using Transaction SWU3 and continue to search for possible workflow errors.

                        If you corrected the error, try to re-process the tRFC. If that does not work technically, you must first contact your workflow-application department to clarify which steps are to be taken in order to ensure the business flow before you use the "Reorganization" via Transaction SM58 to delete the entries that cannot be re-processed.

a) For function module: "IDOC_INBOUND_ASYNCHRONOUS" (Release 4.X and higher) or "INBOUND_IDOC_PROCESS" (3.X release) and a status text that refers to an error there is a ALE/EDI-RFC transmission problem.

                        Please check the technical function of the interface (Destination test in Transaction SM59, checking of the ALE/EDI Customizing for this interface).

                        Correct the error and then re-process the tRFC, otherwise this IDOC is lost for the business process.

a) A common cause with the use of ALE/EDI in the system in Releases as of 4.6 is that the error workflow is delivered for these interfaces, but the general workflow Customizing is not delivered. Since the workflow for the error handling cannot be deactivated in EDI, carry out the workflow Customizing in this case and define processors for the work items.

                        In ALE you have the choice to carry out the error handling either via the workflow or via Transactions BD87 and BD88.If you choose BD87/88, you can deactivate the workflow for the troubleshooting. So the TRFC entries for the error workflow are suppressed.

                        Concerning the deactivation of the error workflow for ALE and EDI proceed as follows:

• Transaction WEDI-> Control -> System Process Code. Here you can deactivate each standard tasks by selecting 'inactive'.

• Deactivate the event linking via Transaction SWE2 by removing the cross in the "Type Linkage active". Here you can deactivate the error workflow on message type level. You might only deactivate the event linking for certain message types.

                     Set event PROCESSSTATEREACHED always to 'active' for the IDoc object if you are communicating via the file interface, otherwise no immediate processing is possible.

                        If the error workflow has been deactivated and the IDOC errors have been corrected with BD87/88, you can delete the corresponding entries in the TRFC tables using Transaction SM58.

• < Prev
• Next >