Form step - 'Back' arrow completes step

PEOU Tom T Tom_PEOU at rta.nsw.gov.au
Sun Oct 9 19:59:30 EDT 2005


Hi Nigel,

 

Copying the task is a good move because it won't impact on other
workflows that may be using that task. Ensure that you make the copy
through PFTC and note down the new task number. In your workflow, note
down the bindings for the original task before you replace it with your
new task - The bindings should remain identical, plus any additional
container elements that you may be passing into your new (copied) task.

 

As for the 'Edit' form completing upon save - I believe that this should
be the case for most forms... However, when you refer to the
Approve/Reject not completing until a decision is made (and backing out
would keep the work item in the inbox), you must remember that this is
how the 'DECISION-PROCESS' method works. The 'Edit' forms you refer to
is probably when you are calling a different Method (from Bus.Objs.) -
And this task can be considered as completed when you exit the form
(back out or saving) - An option to counteract this exit is to start
making modifications to the Method that calls this form... But the
easiest solution is to turn on 'Confirm End of Processing'.

 

I have not yet encountered performance issues when storing large amounts
of data into the WF and Task Containers. I've developed a workflow with
a multiline 255 char container and has easily stored around 3000 entries
without encountering any performance or data integrity issues.

 

Cheers,

T

 

 

Tom Peou

Workflow & ESS Administration

Roads and Traffic Authority

Centennial Plaza

260 Elizabeth Street

Surry Hills, NSW

P: (02) 9218 6601

E: Tom_PEOU at rta.nsw.gov.au

 

 

 

 

 

________________________________

Hi Tom.

 

Thanks for your response - the 'confirm end of processing' is a step in
the right direction, but as you state, is not foolproof (nor
particularly elegant, but hey!). At first I wasn't sure whether I'd
screwed something up by changing the SAP standard task - I added a
container variable based on 50 char SGTXT and redefined the work item
header text, to allow a more meaningful description than 'Change form'.
I initially tried to copy the task and create my own, but this obviously
doesn't bond with the forms wizard (unless, again, I'm missing something
here - still in my formative days as far as workflow goes).

 

I know I've read that an 'edit' form is not completed until the save
button is selected - not absolutely sure if this was one of our
Jocelyn's articles or whether it was SAP help. The approve step
certainly stays open until either approve or reject is selected -
backing out of the form leaves the item in the workbox. Is the fact that
the edit form 'completes without saving' a fault, would you think? If so
I'll harass SAP via OSS.

 

One other question if I may. This particular workflow is a very simple
one which collects specific EAN data when a field in the material master
changes, and goes on to update a 'Z' table as well as the material
master itself. Works fine except for the edit form 'fault', and the data
collection is minimal. Another workflow I am persevering with, however,
is completely based on simple forms, and creates a material. Each form
(structure) is pretty big and when split into several plants /
warehouses / sales orgs. &etc., the form data is stored in multi-line
container elements until calling a sub-workflow for each
BAPI_MATERIAL_SAVEDATA step. Works fine and the users are OK with it,
but my question is whether it is OK to have so much data being stored in
the workflow container (performance / resource wise) rather than writing
data out to 'Z' tables and suchlike. Haven't managed to find any doco on
this and am hoping it's alright.     

 

All the best.

 

Nigel.

 

________________________________

 

 


IMPORTANT NOTICE: This e-mail and any attachment to it are intended only to be read or used by the named addressee. It is confidential and may contain legally privileged information. No confidentiality or privilege is waived or lost by any mistaken transmission to you. The RTA is not responsible for any unauthorised alterations to this e-mail or attachment to it. Views expressed in this message are those of the individual sender, and are not necessarily the views of the RTA. If you receive this e-mail in error, please immediately delete it from your system and notify the sender. You must not disclose, copy or use any part of this e-mail if you are not the intended recipient.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mailman.mit.edu/pipermail/sap-wug/attachments/20051010/d4c2a8c6/attachment.htm


More information about the SAP-WUG mailing list