Cancel UBE Processing

Hi Everyone !

Welll it migth not be a big problem for some but for me it is ! I have a UBE that I want to cancel the processing before it sends the select to the database in case the user has wrongly inputted the PO's parameters. I've tried to use the Stop Event Processing system function in the Initialize Section but it didn't work.[shocked]

Thanks for any suggestion,

Renato Garcia - JDE Developer

Hi Renato,

What about StopBatchProcessing system function?
Although, you can not use in the Initialize Section but in the AdvanceSection or DoSection event.

If the affected section is not the first unconditional section (omit the header and footer sections), then you can check PO in one of the previous section(s) and issue the StopBatchProcessing there, when necessary.

If this section is the first unconditional, and it is not a requirement, to enable Selection/Sequencing for the user at version level, then you can create a dummy unconditional section before that section and place your logic there. In this case, not necssary anyway to use StopBatchProcessing. You can make the section to conditional and call it or not.

Regards,

Zoltán

In the past, I have had to abort a UBE because of invalid processing options. One sneaky way is to check the processing options, and if they are not valid, set data selection to something that will NEVER return selected data (eg. Company is equal to 'JZZ2').

Of course you would then need to make sure that any subsequent unconditional sections do not process as well.

Just a thought,
Ben again

Hi Ben again,

Nice solution!
I like it.

My 2 cents to it:

To prevent any subsequent unconditional sections to process:

Set a flag in the Init Section.
If the flag is on, then call a conditional section from the End Section.
In the conditional section you can print out the message about wron PO values as you want and issue the StopBatchProcessing system function.

I am curious, how does it work. I hope, Renato will share with us the results.

Regards,

Zoltán

Hi Ben !

I tried what you suggested and it works but the select is still sent to the database what causes a delay because I am using a view that joins some of the biggest tables like F0911, F0901 etc. If there is no other way I'll keep that way !

Thank you very much !

Hi Zoltán,

You know what ? It seems very nice ! I havent thought that and it fits perfectly !

Thanks,

If you want to make sure that the NULL select is as fast as possible, then you should make the data selection be on the primary table's - first field of the primary index. So in the case where you are looking into F0911 linked to some other tables, the first field of the primary index is DCT. So data select on DCT is equal to 'B' or some other value that doesn't exist. This should bring the data select back faster than say... UPMT is equal to 89998!

Ben again

RAG,

I like Ben's idea of using some data selection so no records are selected. I do shy away from picking some arbitrary value that you think will 'never' be valid. What I have done in the past to ensure no records is do custom selection for some data item and value using <equal> AND another custom selection for same data item and value...but use <not equal>.

However, I am not sure if this statement will adversely affect performance even using the first key field. I'd be curious to hear your results trying it both ways.

Good luck.

Jeremy,

Just to send you a feedback, I've tried Ben's idea (F0911.DCT = 'B') and your (F0911.DCT = 'B' and F0911.DCT <> 'B') separately and both returned within the same time, much faster than the condition I've used before (F0901.AID = Null) what I could not understand since the AID is also a primary index for the F0901 (table joined to F0911 by this field). Well I decide to keep both ideas so I'll be assured not to have any unexpected result.

Thank you and Ben a lot,