Rel: 4.70 -- Archive Link and Workflow problem

[jimmy sun]

John,
  sounds like you want to establish the link between the SAP document and the Image file, and it failed.
  Are you sure IMAGEPROCESS is the correct Method to use? It looks to me, you may want to take a look of the method ImageAssignEarly. Because yo have an image file, and created a SAP document with the info. 
   
  Jimmy
  

John Wiese <jwiese at esri.com> wrote:
  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


_______________________________________________
SAP-WUG mailing list
SAP-WUG at mit.edu
http://mailman.mit.edu/mailman/listinfo/sap-wug



"Whether you think you can or whether you think you can't, you're right!"     --Henry Ford
		
---------------------------------
Blab-away for as little as 1¢/min. Make  PC-to-Phone Calls using Yahoo! Messenger with Voice.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mailman.mit.edu/pipermail/sap-wug/attachments/20060524/adf96bf6/attachment.htm