Check FM does not work

Dart, Jocelyn jocelyn.dart at sap.com
Wed Oct 24 20:07:45 EDT 2001


Hi Ritu,
My apologies - obviously been away too long.
Yes you are right, Virendra's solution would work
however I would still strongly advise against it
as the overheads associated with raising unnecessary workflow
instances can be signficant (in terms of performance, resource usage,
ease of error resolution...).
 
I'd agree with the others who have been commenting that
perhaps you should be looking at the BKPF document type
or other mechanisms such as BTE's to do the same job.
 
It would have been nice if the developer had used
SWE_EVENT_CREATE_FOR_UPD_TASK and then we wouldn't have this
issue... something for others raising their own events in their
own programs, user-exits or BADIs to remember perhaps.
Regards,
        Jocelyn Dart
Consultant (EBP, BBP, Ecommerce, Internet Transaction Server, Workflow)
SAP Australia
Email jocelyn.dart at sap.com <mailto:jocelyn.dart at sap.com>
Tel: +61 412 390 267
Fax: +61 2 9935 4880
 
 
 
-----Original Message-----
From: NAGPAL,RITU (HP-Roseville,ex1) [mailto:ritu_nagpal at hp.com]
Sent: Thursday, 25 October 2001 5:13 AM
To: SAP-WUG at MITVMA.MIT.EDU
Subject: Re: Check FM does not work
 
 
This does not sound correct...workflow will not be started before the
document is saved. The check function module is called in the same LUW as
the application creating the event and hence the document type is not
available in the database at that point of time. The receiver function
module is called in a separate LUW after a commit work from the application
and hence, after the workflow kicks off, the database will show the document
type. I agree with Virendra that one will end up kicking off too many
workflows if the check is made in the workflow.
Other ways of accessing the document type as suggested by Jocelyn and others
would be better.
 
Thanks, Ritu
 
-----Original Message-----
From: Krishna p [mailto:krishnap at workflow-tech.com]
Sent: Wednesday, October 24, 2001 11:31 AM
To: SAP-WUG at MITVMA.MIT.EDU
Subject: Re: Check FM does not work
 
 
I too agree with Jocelyn.
One cannot instantiate a business object without a record in the table if
your key is pointing to that table.
Eventually your workflow will be erred out first if you start the worklow
without a database record.
 
One more option is to trigger an event in the User-exits if there is one
exists after the database update.
I am not sure if there is an user exit exists after posting the FI docs.
 
Thanks,
Krishna.
 
----- Original Message -----
From: "Dart, Jocelyn" <jocelyn.dart at sap.com>
To: <SAP-WUG at MITVMA.MIT.EDU>
Sent: Tuesday, October 23, 2001 6:35 PM
Subject: Re: Check FM does not work
 
 
> Hi Patrick,
> Firstly, no you can't put COMMIT WORK in a check function module
> as this interrupts the event linkage process - I won't go into all
> the reasoning but there is some doco on this in the R/3 library.
>
> Secondly, unfortunately Virendra's solution would have the same
> problem - because the workflow would be started before the document is
> saved.
>
> Thirdly, it would be better to create a document type attribute
> as part of the BSEG (or your delegated subtype of BSEG) object
> if there isn't already one there (you don't mention what release
> you are on), as you could then access it throughout all your workflows
> now or in the future.  Setting up attributes (which are reusable) to read
> the
> database rather than coding direct reads (which aren't reusable)
> in FMs is a good habit to get into.
>
> However, none of that solves your problem.  What you need to do is
identify
> where and how the BSEG.CREATED event is raised.  You may need to contact
> the developers via OSS to do this if you can't track it down yourself.
>
> Once you know where and how the event is raised you can look at ensuring
> that the event is only raised once the database tables have been updated.
>
> For instance if the event is raised based on change documents, make sure
> the change documents have update priority 2 (delayed) so that they occur
> AFTER the document itself has been committed to the database. On the
change
> document function module XXXXX_WRITE_DOCUMENT where XXXXX is the change
> document object, you should see it is an update module with "Start
Delayed".
>
>
> According to OSS note 38968 BSEG is created via change documents.
>
> Or if the event is raised directly using function module SWE_EVENT_CREATE
> swap to SWE_EVENT_CREATE_FOR_UPD_TASK (e.g. see OSS note 123782 which
> may be related...) .
>
> Suggest you also take it up with the FI developers via OSS to clarify
> when and how the event is raised.
>
> Hope that helps.
> Regards,
>         Jocelyn Dart
> Consultant (EBP, BBP, Ecommerce, Internet Transaction Server, Workflow)
> SAP Australia
> Email jocelyn.dart at sap.com <mailto:jocelyn.dart at sap.com>
> Tel: +61 412 390 267
> Fax: +61 2 9935 4880
>
>
> -----Original Message-----
>> From: virendradapt [mailto:virendradapt at micron.com]
> Sent: Wednesday, 24 October 2001 4:49 AM
> To: SAP-WUG at MITVMA.MIT.EDU
> Subject: Re: Check FM does not work
>
>
> Hello Patrick,
> Not exactly answering what you asked, but if you can check the document
> type("ZR") inside the WF template and end if it is not "ZR" could solve
you
> problem.
> Disadvantage would be more Workitems than required.
> Virendra.
>
>  -----Original Message-----
>> From:   de Valensart Schoenmaeckers, Patrick
> [mailto:deValensartSchoenmaeckers.Patrick at pmintl.ch]
> Sent:   Tuesday, October 23, 2001 11:43 AM
> To:     SAP-WUG at MITVMA.MIT.EDU
> Subject:        Check FM does not work
>
> Hi workflowers.
>
> I want to trigger an approval workflow for all FI-AP documents, except for
a
> FI document type "ZR". I have then linked my workflow to the event
> BSEG.CREATED with a "check" function module that raise an exception if the
> document type is ZR (via transaction SWE2).
> However, it looks like when posting an FI document, the function module is
> called before that the table BKPF is updated. So my select statement does
> not select anything, and the FM does therefore not raise an exception as
> expected. When I try to use the test tool "generate event" (transaction
> SWUE), it works fine (which is normal, because I am then working on an
> existing document.)
>
> I searched OSS to solve this problem without success. I also tried to put
a
> "commit work" statement in the function module, but that gives an error
> message (a sap office Express info "Update was terminated") when trying to
> post the document, and it is not posted. Any help or tip to solve this
would
> be very much appreciated.
>
> Thanks in advance & Kindest regards to all.
>
> Patrick de Valensart
> Associate IS Analyst
> Philip Morris Benelux M&S
>
>
> P.S. Here is my FM :
>
> FUNCTION Z_AP_WF_EVENT_CHECK_NOT_ZR.
> *"----------------------------------------------------------------------
> *"*"Update function module:
> *"
> *"*"Local interface:
> *"       IMPORTING
> *"             VALUE(OBJTYPE) LIKE  SWETYPECOU-OBJTYPE
> *"             VALUE(OBJKEY) LIKE  SWEINSTCOU-OBJKEY
> *"             VALUE(EVENT) LIKE  SWEINSTCOU-EVENT
> *"             VALUE(RECTYPE) LIKE  SWETYPECOU-RECTYPE
> *"       TABLES
> *"              EVENT_CONTAINER STRUCTURE  SWCONT
> *"       EXCEPTIONS
> *"              DO_NOT_TRIGGER
> *"----------------------------------------------------------------------
>   INCLUDE <CNTAIN>.
>   DATA : BEGIN OF KEY,
>            BUKRS LIKE BSEG-BUKRS,
>            BELNR LIKE BSEG-BELNR,
>            GJAHR LIKE BSEG-GJAHR,
>            BUZEI LIKE BSEG-BUZEI,
>          END OF KEY.
>   CLEAR KEY.
>   KEY = OBJKEY.
> * commit work.
>   SELECT SINGLE * FROM BKPF WHERE BUKRS = KEY-BUKRS
>                               AND BELNR = KEY-BELNR
>                               AND GJAHR = KEY-GJAHR.
>   IF BKPF-BLART EQ 'ZR'.
>     RAISE DO_NOT_TRIGGER.
>   ENDIF.
>
> ENDFUNCTION.
>
 


More information about the SAP-WUG mailing list