topic Query in Application Development and Automation Discussions

Query

Former Member — Thu, 24 Aug 2006 04:18:21 GMT

Hi,

My requirement is :-

1.) Open dataset for input

2.) Submit to RFBIBL00

3.) Submit to RSBDCSUB

4.) Move the file to the archive directory

5.) Get the status of the job (failure or completed) in a text file.

I have done till Step 4. ... for Step 5 ... I am planning to write a generic program or FM say ZSTATUSLOG ... So that ZSTATUSLOG can be used for all the interfaces ... This program or FM I'll be calling in the main program .... (If I write a program then my command will be SUBMIT ZSTATUSLOG VIA SELECTION-SCREEN USING SELECTION-SET 'VARIANT1'... else if I write an FM then I will use the command CALL FUNCTION ZSTATUSLOG)...

My problem is that if the main program fails during step 2. (example is line items coming more than 950...) then the subsequent code is not executed ... How do I code so that the pointer can jump from Step 2. to Step 5. or Step 3 to Step 5... in case of failure jobs...

Please help.

Thank You,

SB.

Re: Query

Former Member — Thu, 24 Aug 2006 04:31:21 GMT

Hi SB,

I think writing step 5 in the same program is not a very good idea. Yes you are right regarding the fifth step as a separate FM, but I guess you have to call this FM in another program. You can schedule your main program and status-get program in a job as 2 different steps, 2nd will be called once 1st is complete and will update the text file.

Another SIMPLE/easy solution is :

Update the status text file after every step. In the begining at STEP 1 set the status in file as JOB-FAILED, and once all the steps are complete update the status in file as JOB-SUCCESSFUL. Here even if step 3/4 fails the status in file is JOB-FAILED, thats what is required. You can also update these status at every step, depending on requirement.

Hope this will help

Regards,

Vishal

Reward if helpful

Regards,

Vishal Tyagi

Re: Query

Former Member — Thu, 24 Aug 2006 04:31:49 GMT

Hi SB,

From functional perspective, i dont think if there are more than 950 line items, there should be a program failure rather ur program should be call RFBIBL00 again for posting rest of the line items in another FI document. It means that if there are 1000 line items, then 2 FI doc should be posted with 950 and 50 line items respectively.

Even if your requirement is so, call your ZSTATUSLOG pgm or FM after RSBDCSUB pgm has scheduled BDC. It should read TBTCO table to get the status field value and display status accordingly. Thereafter u can move file to archive directory.

In short ur sequence should be

1.) Open dataset for input

2.) Submit to RFBIBL00

3.) Submit to RSBDCSUB

4.) Get the status of the job (failure or completed) in a text file.

5.) Move the file to the archive directory

Cheers,

Vikram

Pls reward for helpful replies!!

Re: Query

Former Member — Thu, 24 Aug 2006 21:16:36 GMT

Any more suggesstion for me to excecute Step 5...

Thank in advance

Re: Query

Former Member — Thu, 24 Aug 2006 21:40:45 GMT

Are you submitting RFBIBL00 and RSBDCSUB in one job, two steps or two jobs, one step each?

Re: Query

Former Member — Thu, 24 Aug 2006 21:48:29 GMT

Hi Vishal,

From SM36 I defined a new job called Z_VEN_INV_TEST... this calls the main prg... then in the additional step I gave the ZSTATUSLOG program with variant "Z_VEN_INV_TEST" ... but because it is immdeiately getting executed ... ( I have no control to schedule the additonal step after some time gap )... the text file is not getting updated ... I think there is some time gap between the main prg getting executed and Table V_OP updation ...

Regarding your second suggestion ... it's definately easy but not generic... I want something which will help to just plug n play with other interface jobs instead of writing seperate logics for each one...

Thank You.

Re: Query

Former Member — Thu, 24 Aug 2006 21:50:45 GMT

No Srinivas both RFBIBL00 & RSBDCSUB are in one prg only ... my requirement is to create a log report that the interface ran ... & I wanted a generic solution...

Re: Query

Former Member — Thu, 24 Aug 2006 22:17:00 GMT

Sorry I mislead you. My question was whether your SUBMITs are done with the VIA JOB option.

You can use function module BP_JOB_STATUS_GET to read the status of a particular job.

Re: Query

Former Member — Thu, 24 Aug 2006 22:22:29 GMT

OK ... but then where do I code it ??... In the main program or in a seperate program ??... If I have to code it in seperate prg... then I have to schedule this prg as a job ... how do I schedule ??... the interface job keeps running thru out the day...

Re: Query

Former Member — Thu, 24 Aug 2006 22:29:00 GMT

I have scheduled this prg as a job which runs twice a day...

Here is my Code:

Report ZVENDOR_INVOICE.

START-OF-SELECTION.

Perform to get the list of all the files in a specific directory of
application server.

PERFORM GET_DIRECTORY_FILES.

Perform to process the logic

PERFORM PROCESS_FILES.

IF FG_FLAG = 'X'.

Perform to move the processed files to archive directory

PERFORM MOVE_FILES.

ENDIF.

&----

*& Form GET_DIRECTORY_FILES

&----

Perform to get the list of all the files in a specific directory of
application server.

----

FORM GET_DIRECTORY_FILES .

CALL FUNCTION 'RZL_READ_DIR_LOCAL'

EXPORTING

NAME = p_new

TABLES

FILE_TBL = T_LISTFILES

EXCEPTIONS

ARGUMENT_ERROR = 1

NOT_FOUND = 2

OTHERS = 3.

IF SY-SUBRC <> 0.

MESSAGE ID SY-MSGID TYPE SY-MSGTY NUMBER SY-MSGNO
WITH SY-MSGV1 SY-MSGV2 SY-MSGV3 SY-MSGV4.

ENDIF.

CLEAR T_LISTFILES.

ENDFORM. " GET_DIRECTORY_FILES

&----

*& Form PROCESS_FILES

&----

Perform to process the logic

----

FORM PROCESS_FILES .

LOOP AT T_LISTFILES .

DELETE T_LISTFILES WHERE NAME = '.' .

DELETE T_LISTFILES WHERE NAME = '..'.

CLEAR T_LISTFILES.

ENDLOOP.

Open the file

LOOP AT T_LISTFILES.

CONCATENATE p_new

'/'

T_LISTFILES-NAME

INTO V_FILEPATH.

OPEN DATASET V_FILEPATH FOR INPUT IN TEXT MODE ENCODING DEFAULT

MESSAGE V_MSG.

WRITE: V_FILEPATH.

IF SY-SUBRC <> 0.

WRITE: 'File cannot be opened', V_MSG.

EXIT.

ENDIF.

Reading the file.

DO.

READ DATASET V_FILEPATH INTO T_INPUTFILE.

IF SY-SUBRC <> 0.

EXIT.

ELSE.

Capture session name.

IF T_INPUTFILE+0(1) = '0'.

V_SESS_NAME = T_INPUTFILE+1(12).

ENDIF.

APPEND T_INPUTFILE.

CLEAR T_INPUTFILE.

ENDDO.

Close the file.

CLOSE DATASET V_FILEPATH.

Submit the input file to the standard SAP program 'RFBIBL00'.

IF T_INPUTFILE[] IS NOT INITIAL.

SUBMIT RFBIBL00 WITH DS_NAME = V_FILEPATH

WITH FL_CHECK = SPACE

WITH CALLMODE = 'B'

WITH XLOG = 'X'

AND RETURN.

IF SY-SUBRC = 0.

FG_FLAG = 'X'.

ENDIF.

IF P_RUNBI = 'X'.

Perform to run the batch input session.

PERFORM RUN_BATCH_INPUT_SESSION.

ENDIF.

CLEAR : T_INPUTFILE,

V_SESS_NAME.

REFRESH : T_INPUTFILE.

ENDLOOP.

ENDFORM. " PROCESS_FILES

&----

*& Form MOVE_FILES

&----

Perform to move the processed files to archive directory

----

FORM MOVE_FILES .

LOOP AT T_LISTFILES.

CONCATENATE p_new

'/'

T_LISTFILES-NAME

INTO V_FILEPATH.

CONCATENATE V_FILEPATH

p_arch

INTO ARCH_DIR

SEPARATED BY SPACE.

CALL FUNCTION 'SXPG_COMMAND_EXECUTE'

EXPORTING

COMMANDNAME = C_CMD_TEST

ADDITIONAL_PARAMETERS = ARCH_DIR

OPERATINGSYSTEM = SY-OPSYS

TARGETSYSTEM = SY-HOST
DESTINATION =
STDOUT = 'X'
STDERR = 'X'
TERMINATIONWAIT = 'X'
TRACE =
IMPORTING
STATUS =
EXITCODE =

TABLES

EXEC_PROTOCOL = T_MOVETODIR

EXCEPTIONS

NO_PERMISSION = 1

COMMAND_NOT_FOUND = 2

PARAMETERS_TOO_LONG = 3

SECURITY_RISK = 4

WRONG_CHECK_CALL_INTERFACE = 5

PROGRAM_START_ERROR = 6

PROGRAM_TERMINATION_ERROR = 7

X_ERROR = 8

PARAMETER_EXPECTED = 9

TOO_MANY_PARAMETERS = 10

ILLEGAL_COMMAND = 11

WRONG_ASYNCHRONOUS_PARAMETERS = 12

CANT_ENQ_TBTCO_ENTRY = 13

JOBCOUNT_GENERATION_ERROR = 14

OTHERS = 15

IF SY-SUBRC <> 0.

MESSAGE ID SY-MSGID TYPE SY-MSGTY NUMBER SY-MSGNO
WITH SY-MSGV1 SY-MSGV2 SY-MSGV3 SY-MSGV4.

ENDIF.

ENDLOOP.

ENDFORM. " MOVE_FILES

&----

*& Form RUN_BATCH_INPUT_SESSION

&----

Perform to run the batch input session

----

FORM RUN_BATCH_INPUT_SESSION .

IF CALLMODE = 'B' AND Z_VERARB = 'X'.

SUBMIT RSBDCSUB WITH MAPPE = V_SESS_NAME

WITH VON = SY-DATUM

WITH BIS = SY-DATUM

AND RETURN.

EXPORTING LIST TO MEMORY.

ENDIF.

Re: Query

Former Member — Thu, 24 Aug 2006 22:45:03 GMT

You cannot get the status of your SUBMITs if you are doing them like this. The problem with SUBMIT is that it creates the spool instead of giving you any status ( like sy-subrc value or exceptions ). So if your RFBIBL00 execution fails for some reason, you will get the log in the spool but your sy-subrc will still be 0.

What you can do is to do the following steps.

call JOB_OPEN function module and get the job number.

SUBMIT RFBIBL00 VIA JOB job number from above.

SUBMIT RSBDCSUB VIA JOB job number from above.

call JOB_CLOSE function module using job number.

You can then find the job status of the above job using the function module that I gave you previously. But even in this case, by the time you reach step 5, your job above may not be completed. So either you have to wait until the above is finished and then read the spool/log of that job using BP_JOBLOG_READ and BAPI_XBP_JOB_SPOOLLIST_READ.

Re: Query

Former Member — Thu, 24 Aug 2006 23:30:05 GMT

But Sri.. I need something which I can use for all interface jobs... Can there be any other way ??