Most common failures Egate Eways arent up Arch, Batch, Sync, Async RFC connections are down or have

reached maximum capacity and require clearing down. SAP RFC connections arent connecting to EGATE SAP RFC queues are down or have reached maximum capacity SAP process event queue contains errors ZTINT contains files SAP interface directories contain old files Failures do to reference data. Should you have any incorrect ref data or jobs failing due to incorrect or hot fixed ref data. These need to be resolved be requesting that the correct reference data variable be updated in the Moose data base. Once his has been successfully completed the new changes will be applied once the latest reference data build has been deployed. Maestro Missing archive folders House keeping failures This is a work around should your job fail on a house keeping step with an error similar to the following. + MAESTRO_SCHED=J3Z_MAM_B0016ASC + let 10 == 09 + let 10 == 10 + + remsh egate-pre-10 -l egappd10 -n /opt/product/egate/batch/bin Log onto the relevant server where the failed job resides. ie. egate-pre-09 Once logged on navigate to the following directory /opt/product/egate/batch/bin This is found in the error log.(standard list in maestro) NB: Note this location will depend on the error received in the standard list(error log) Run the below command to filter for all the CFG files ls -lrt |grep cfg Look for the following file JUP_R3_cleanup.cfg This next step will vary depending on the schedule that is failing. You are going to filter the following location JUP_R3_cleanup.cfg for the schedule that has failed in this case B0016. cat JUP_R3_cleanup.cfg |grep this will be the ref data parameter at the top of the page ie) B0016ASCHG:FIL The below location will depend on the failed schedule. /opt/product/batchfiles/shared/jupiter/ Run ls lrt to sort the order of the files in ascending order. This will make it easier to determine the latest files.

If the file has insufficient privileges it should look something like this drwxrx--- You need to change the file permissions on the required file to 770. This is done via the following transaction. chmod 770file name In most cases this should be sufficient, but the case it isnt the below folders can also be modified. SAP MON Failures Jobs in maestro that fail on SAP MON jobs these can normally be rectified by re running the failed job. If this does not resolve the failed job then you can try and track this through SAP ISU via ST22, this will allow you to view any error logs that might have occurred in SAP. It will allow you to filter by the time around which the failure occurred. Maestro schedule failures Schedule - J3Z_SAP_REPRINTS - Failed in TRT C2 +1, but passed in C2 last week Resolution: Update from Harry Van Der Kruys: The problem lies within the handling of the processed and error counter in FM Z_BC_S_CHANGE_POINTERS_UPDATE. This FM has no type definition for these counters; hence SAP defines them as a 4 character field. The overflow error occurs because more than a 10000 records are processed successfully. This is not an issue on day to day processing, as only process +/- 1500 a day. This is never the less an issue when processing a back log of more than 10000 change pointers (per run). In that case you might end up sending the reprint twice as only the CP flags are not set. You have to make sure not more than 10000 records are processed per run (for now) I have made a change to the logic (part of Release 4), so we now do define the variables as type integer (which will allow for up to 2.147.483.647 records, even though not used), to prevent this from happening in the future, even though this won't be an issue during day to day processing. J3Z_SAP_AUTO_REFUND schedule failed during Release 6 Cycle 1, the following job in the schedule failed"J3Z_SAP_AUTO_REFUND_2131_SASP 09/16/2011 00/01/18 00 564Job cancelled after system exception ERROR_MESSAGE Job has failed with the following error message:Archive file 007587-001FI_MKKDOC is being processed HTTP error: 404 File Not Found 3015: item not found: can't find document 4C98547F46293EF3E10000000A32054E - Item not found! This is a known issue within our pre-prod environment, due to the fact we do not have archiving. Defect closed.

Schedule failure J3Z_SAP_REPRINTS In Release 5 C4 +2, +++ EEWO1048I Retrieving the job log of a job:: REPRINT_INVOICES , 22240600 10/27/2011 22/24/07 00 516Job started 10/27/2011 22/24/07 00 550Step 001 started (program ZRINT_REPRINT_INV_BATCH, variant CUS&_CUST, user ID MAESTRO) 10/27/2011 22/28/43 EB 036Reprint: Longer runtime possible 10/27/2011 22/28/45 00 671Internal session terminated with a runtime error (see ST22) 10/27/2011 22/28/45 00 518Job cancelled Information on where terminated Termination occurred in the ABAP program "SAPLERDK" - in "ISU_DB_ERDK_SELECT". The main program was "REAPRIN0 ". In the source code you have the termination point in line 107 of the (Include) program "LERDKU16". The program "SAPLERDK" was started as a background job. Job Name....... "REPRINT_INVOICES" Job Initiator.. "MAESTRO" Job Number..... 22240600 The termination is caused because exception "CX_SY_OPEN_SQL_DB" occurred in procedure "ISU_DB_ERDK_SELECT" "(FUNCTION)", but it was neither handled locally nor declared in the RAISING clause of its signature. The procedure is in program "SAPLERDK "; its source code begins in line 1 of the (Include program "LERDKU16 ". Mail sent to Dave H and he has allocated Praful to investigate this further Praful's Response: If you check the two screen prints below it suggest that the job hasn't been executed for quite some time, so the number of change pointers have risen to 16054 as seen in the screen print3. The system is not able to handle these many change pointers at a time so the job should actually be running at regular intervals. For now you have to suppress or kill the number of change pointers and then redo your reprint invoices & execute the batch job. Alex Repsonse: Hi Praful, Thanks, you have confirmed that it was due to the long interval between executions that caused the error. Chalapati - I think this is a reasonable explanation and the defect can be closed.

Maestro process over view

Maestro Schedule released in TWS Issue resolved and ready for re test

NO Egate YES FTP (Net Weaver) YES Pass

NO

Open standard list in maestro to trouble shoot error

Log tracke/defectr to relevant support team to investigate

SAP FTP

NO PASS YES Open standard list in maestro to trouble shoot error

Log tracker/defect to relevant support team to investigate

SAP

Maestro job is updated with the out come of the job in SAP

YES FAIL Open standard list in maestro to trouble shoot error

NO Log tracker to relevant support team to investigate

Schedule has been successfully completed