Form step - 'Back' arrow completes step

Sun Nov 6 17:13:21 EST 2005

For anyone who is interested - I contacted SAP some while ago re. the fact that an edit form work item was incorrectly set to completed without saving first (eg. when back-arrowing out of the form); they have responded with a new note, numbered 894465, which fixes the problem. The note hasn't been translated yet but seems to hit the spot.

Thanks again to Tom and Jocelyn for earlier advices.

Regards.

Nigel. 

-----Original Message-----
From: PEOU Tom T [mailto:Tom_PEOU at rta.nsw.gov.au]
Sent: Monday, 10 October 2005 10:00 AM
To: sap-wug at mit.edu
Subject: Form step - 'Back' arrow completes step

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.

This is an email from Australian Health & Nutrition Association Limited,
ABN 63 096 452 872 trading as Sanitarium Health Food Company.

THIS E-MAIL IS CONFIDENTIAL.
Any recipient who is not the intended recipient is requested to
notify the sender by return e-mail and erase all copies of the message
and attachments. The sender cannot guarantee that this email or any
attachment to it is free of computer viruses or other conditions which may
damage or interfere with data, hardware or software with which it might be used.

If you do not wish to receive commercial email messages from Sanitarium Health Food
Company, please send an unsubscribe message to the sender of this email, or contact
unsubscribe at sanitarium.com.au.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mailman.mit.edu/pipermail/sap-wug/attachments/20051107/408dd5f0/attachment.htm