Rel: 4.70 -- Archive Link and Workflow problem

[John Wiese]

Mike

The IMAGE.ZIMAGEPROCESS is a slight modification of the original
IMAGE.IMAGEPROCESS. The modifications in ZIMAGEPROCESS only serve to
provide some parameter ID's before and after the call to function
WF_NCI_PROCESS_30. These modifications are nominal and should not affect
the outcome of the call. The function WF_NCI_PROCESS_30 determines which
"create" mechanism to call based on the WFL document type
(TWFDB-NCITYPE). In our problem case, the WFL document type is
"ZFI_LIVDOC" which is related to BOR method BUS2081.CREATE which, in
turn, calls transaction MIRO.



ZIMAGE.ZIMAGEPROCESS CODE:
-----------------------------------------------------
BEGIN_METHOD ZIMAGEPROCESS CHANGING CONTAINER.
DATA:
      OBJ_TWFDB     TYPE SWC_OBJECT,
      NCITYPE       LIKE TWFDB-NCITYPE.

DATA: WINDOWID   LIKE SAPB-SAPWINID. "modified
DATA: DOC_TYPE   LIKE TOADD-DOC_TYPE. "modified
DATA: DOCNBR(10) TYPE C. "modified
DATA: DOCGJR(4)  TYPE C.  "modified

  SET PARAMETER ID 'BLN' FIELD DOCNBR. "modified
  SET PARAMETER ID 'BLP' FIELD DOCNBR. "modified
  SET PARAMETER ID 'RBN' FIELD DOCNBR.  "modified
  SET PARAMETER ID 'GJR' FIELD DOCGJR.  "modified

  SWC_GET_ELEMENT CONTAINER 'TWFDB' OBJ_TWFDB.
  SWC_GET_OBJECT_KEY OBJ_TWFDB NCITYPE.
  CALL FUNCTION 'WF_NCI_PROCESS_30'
       EXPORTING
            NCITYPE          = NCITYPE
            ASGKY            = OBJECT-KEY
       EXCEPTIONS
            WF_ERROR_PROCESS = 1
            OTHERS           = 2.
  IF SY-SUBRC <> 0.
     EXIT_RETURN_SYS_MESSAGE 1000.
  ELSE. "modified
    GET PARAMETER ID 'BLN' FIELD DOCNBR. "modified
    IF DOCNBR IS INITIAL. "modified
       GET PARAMETER ID 'BLP' FIELD DOCNBR. "modified
       IF DOCNBR IS INITIAL. "modified
         GET PARAMETER ID 'RBN' FIELD DOCNBR.  "modified
         GET PARAMETER ID 'GJR' FIELD DOCGJR.  "modified
         IF DOCNBR IS INITIAL OR DOCGJR IS INITIAL.  "modified
           EXIT_RETURN_SYS_MESSAGE 1001. "modified
         ENDIF. "modified
       ENDIF. "modified
    ENDIF. "modified
  ENDIF.
END_METHOD.

Thanks to you and anyone else on our Workflow list who can
provide additional insights into this issue.

John

-----Original Message-----
From: sap-wug-bounces at mit.edu [mailto:sap-wug-bounces at mit.edu] On Behalf
Of Mike Pokraka
Sent: Wednesday, May 24, 2006 1:21 AM
To: SAP Workflow Users' Group
Subject: Re: Rel: 4.70 -- Archive Link and Workflow problem

Hi John,
Curious, the Create document step is terminated by a IMAGE.ASSIGNED
event, yet the following step is the one that assigns the image....
something isn't making sense.
Could you give us more detail on what IMAGE.ZIMAGEPROCESS does?
Cheers,
Mike

John Wiese wrote:
> Dear Fellow Workflowers . . .
> 
>  
> 
> We are on the verge of a 4.70 Upgrade weekend (May 26 thru 29, 2006)
and
> we are running into an interesting issue
> 
> with Early Archiving and Workflow . . .
> 
>  
> 
> Here are "some" of the details . . . (please see attachment for full
> details):
> 
>  
> 
> WORKFLOW PROBLEM - SAP 4.7 Archive Link and Workflow
> 
>  
> 
> Problem statement: after creation of a Logistics Invoice (transaction
> MIRO), the LIV document should be assigned to the scanned image and
the
> workflow should end successfully. Instead, the workflow loops back
> around so that the user is once again prompted to create and link a
new
> document to the scanned image. Even though an LIV doc is created
> successfully and the image is linked to the document. Hence, the
> assignment of image to document isn't recognized by the workflow.
> 
>  
> 
>     * WS90000034 - ESRI ImgNew - for early archiving of scanned
documents
>     * Workflow essentially loops until flagged completed
>     * One branch of the loop is problematic - namely steps 381, 386
and 391
>     *  
>     * [Workflow  Builder - Display 'ESRI ImgNew']
>     *  
>     * 381 is the Create R/3 Document step - it eventually calls
>       IMAGE.ZIMAGEPROCESS (tcode MIRO)
>     * Screen shots below are the drill down into this step of the
workflow
>     * It dynamically calls the appropriate transaction (MIRO) for the
>       document type (ZFI_LIVDOC in our case)
>     * Possible outcomes of the step are Process Abandoned, Processing
>       rejected and Document type assigned. Process Abandoned and
>       Processing rejected work fine. "Document type assigned" is not
>       reached.
>     * The "Document type assigned" outcome is a result of a
terminating
>       event defined in the task. This seems to be the problem point.
>     * The other problem is that occasionally the workflow simply
>       bypasses those two steps (386 & 391) and then loops around
again,
>       prompting the workflow user to process, abort or otherwise make
>       the initial decision of the workflow.
>     *  
>     * [Additional screen shots]
>     *  
>     *  
> 
>  
> 
>  
> 
> Does anyone have any idea as to how-to trouble-shoot / resolve this
problem?
> 
>  
> 
> Thanks for your time and your help!
> 
>  
> 
> John Wiese
> 
> ESRI, Inc.
> 
> Redlands, Calif.  92373
> 
> (909) 793-2853 x2381
> 
>  
> 
>  
> 
> 
> 
>  
> 
> 
>
------------------------------------------------------------------------
> 
> _______________________________________________
> SAP-WUG mailing list
> SAP-WUG at mit.edu
> http://mailman.mit.edu/mailman/listinfo/sap-wug
_______________________________________________
SAP-WUG mailing list
SAP-WUG at mit.edu
http://mailman.mit.edu/mailman/listinfo/sap-wug