Question Re: FM SO_NEW_DOCUMENT_ATT_SEND_API1 mail problem in Technology Q&A

FM SO_NEW_DOCUMENT_ATT_SEND_API1 mail problem

Former Member — Wed, 25 Jun 2014 10:45:46 GMT

Hi All,

In one of a workflow for PPM , I am using this Function module to send email. But this FM is getting dumped and no information received by the WF and hence it remains in process.

The dump details are as follows:

Short text of error message:

COMMIT WORK during ON COMMIT or ON ROLLBACK

Calls trace

33 METHOD CL_DPR_TRANSACTION_MANAGER====CP CL_DPR_TRANSACTION_MANAGER====CM009 18

CL_DPR_TRANSACTION_MANAGER=>ON_TRANSACTION_FINISHED

32 METHOD CL_SYSTEM_TRANSACTION_STATE===CP CL_SYSTEM_TRANSACTION_STATE===CM001 2

CL_SYSTEM_TRANSACTION_STATE=>RAISE_TRANSACTION_FINISHED

31 FORM SAPMSSY0 SAPMSSY0 464

%_AFTER_COMMIT

30 FUNCTION SAPLSOI1 LSOI1U32 172

SO_DOCUMENT_SEND_API1

29 FUNCTION SAPLSOI1 LSOI1U25 30

SO_NEW_DOCUMENT_ATT_SEND_API1

Any Helps !

Thanks

Re: FM SO_NEW_DOCUMENT_ATT_SEND_API1 mail problem

Former Member — Wed, 25 Jun 2014 12:00:08 GMT

Hi,

you should use the workflow log to determine the content of the parameters that you are sending to this task and method. Then either in SWO1 (if it is a BOT Method) or in se24 (Class method) you can then debug it to find out where it is going awry.

Kind regards, Rob Dielemans

Re: FM SO_NEW_DOCUMENT_ATT_SEND_API1 mail problem

Former Member — Wed, 25 Jun 2014 13:27:43 GMT

Hi,

Already did that , took the parameter values from the workflow task container and executed the BOR method in debug, no dump and email received.

while within the workflow every time this step is being encountered and this FM is being called its getting dumped.

Thanks

Re: FM SO_NEW_DOCUMENT_ATT_SEND_API1 mail problem

Former Member — Wed, 25 Jun 2014 13:31:34 GMT

Hi Linda,

Who is the actual user which executes this method? If it is WF-BATCH then make sure that this user has a valid email address, it doesn't have to exist just as long as it conforms to mail address conventions i.e. xxx@zzz.com

Kind regards, Rob Dielemans

Re: FM SO_NEW_DOCUMENT_ATT_SEND_API1 mail problem

Former Member — Thu, 26 Jun 2014 06:07:52 GMT

Hi Rob,

The method is being executed by the WF-BATCH. The email address of the receiver is being provided in the binding to the BOR method.

Thanks

Re: FM SO_NEW_DOCUMENT_ATT_SEND_API1 mail problem

anjan_paul — Thu, 26 Jun 2014 09:14:20 GMT

Hi,

Try to use SO_NEW_DOCUMENT_ATT_SEND_API1 with/without COMMIT WORK = SPACE/X and check

Re: FM SO_NEW_DOCUMENT_ATT_SEND_API1 mail problem

Former Member — Thu, 26 Jun 2014 10:03:23 GMT

Hi,

Already tried that. No email is being sent when its used without comit.

Thanks

Re: FM SO_NEW_DOCUMENT_ATT_SEND_API1 mail problem

pokrakam — Thu, 26 Jun 2014 15:03:00 GMT

Hi Linda,

It's complaining that you are performing a commit inside a larger transaction. The COMMIT_WORK parameter must be off (default). If, as you say, no mail gets sent then it would seem to me some transaction logic is broken. You could either try to work out why, or the lazy simple way is to add a manual COMMIT WORK after the call to your FM. Ideally do this as late as possible before handling control back to workflow.

Hope that helps,

Mike

Re: FM SO_NEW_DOCUMENT_ATT_SEND_API1 mail problem

Former Member — Fri, 27 Jun 2014 14:16:22 GMT

Hi Mike,

I called the email FM without commit and commited immediately after it but the result is again the same dump.

Any More Suggestions

Thanks

Re: FM SO_NEW_DOCUMENT_ATT_SEND_API1 mail problem

pokrakam — Fri, 27 Jun 2014 16:16:51 GMT

Hi Linda,

What I meant was to do the commit as late as possible, not immediately afterwards. I don't know your application process, but what the dump says is that something at a higher level is in control of a transaction and you're throwing a spanner in the works.

But if it doesn't sent the mail without a COMMIT then something is not right in your transaction handling.

Is the code where you're sending the mail in a dedicated method or does it do other stuff? The COMMIT should be right at the end of the method. Or, perhaps the workflow is a task being run synchronously, or something...

If you read the call stack of the dump it could tell you more, perhaps there is a Z-object higher up and you may need to look there.

Hope that helps,

Mike

Re: FM SO_NEW_DOCUMENT_ATT_SEND_API1 mail problem

Former Member — Wed, 16 Jul 2014 10:07:01 GMT

Mike,

You are quite right. Although Logically it does not make sense. The Business Process is that A Workflow activity want to do something with an entity X and if it is not able to do it then another activity sends an email and the result is the dump.

Now it seems that the Entity X was not cleanly rollbacked. I am using the standard Function module to perform the change to the Entity and it must Rollack it as well if not successful, I hope atleast.

Advisable to use explicit Rollback ?

BR,

Re: FM SO_NEW_DOCUMENT_ATT_SEND_API1 mail problem

pokrakam — Wed, 16 Jul 2014 10:32:33 GMT

Hi Linda,

Looks like you have just about answered your own question

Yes, if something started a transaction and it was not completely terminated (either complete or rollback) then another COMMIT will cause upset.

I am not fully in the picture, but what it sounds like is that you are trying to send the mail within the same LUW. So perhaps what is happening is that it's busy rolling back and you're trying to do new stuff?

If so, the a better strategy may be to complete the failure within the WF step, model an exception and send the mail in a separate step. This makes it clearer in the WF log and easy for anyone to see where the mail originated.

Hope that helps,

Mike

Re: FM SO_NEW_DOCUMENT_ATT_SEND_API1 mail problem

Former Member — Wed, 16 Jul 2014 11:29:34 GMT

Hi Mike,

These are two different Workflow Steps/tasks. One step attempts to change an entity and the other sends an email afterwards if required.

So my question is after the first step or at the end of the first step , should i write an explicit rollback or may be commit , so that it finishes off cleanly and the next step should send the email ? I am using a standard function module in the first step so i was hoping i need not to take care about any commit or rollback.

I had already tried a wait for few minutes after the first step, still the result was the same.

Thanks

Re: FM SO_NEW_DOCUMENT_ATT_SEND_API1 mail problem

pokrakam — Wed, 16 Jul 2014 11:35:59 GMT

That is interesting... (translation: I haven't a clue )

If you wait a few minutes and it still fails then it's unlikely to be a delayed write - unless your system is struggling performance-wise.

You could try a COMMIT WORK AND WAIT at the end of the first step to see if that helps.

Does a standard sendmail step work?

Is there any other code in the method or just the send mail stuff?

Re: FM SO_NEW_DOCUMENT_ATT_SEND_API1 mail problem

Former Member — Wed, 16 Jul 2014 11:59:48 GMT

Mike,

Yes its interesting

ok i try with commit work and wait.

The standard email task used to work but because of complex email requirements, i changed it to the activity one.

The code is just creating the email content and then calling the FM to send the email.

Thanks

Re: FM SO_NEW_DOCUMENT_ATT_SEND_API1 mail problem

Former Member — Wed, 16 Jul 2014 12:09:58 GMT

Hi Smith,

Try to give the following submit after the commit work,

COMMIT WORK.

SUBMIT RSCONN01 WITH MODE = 'INT' AND RETURN.

Regards,

John K.

Re: FM SO_NEW_DOCUMENT_ATT_SEND_API1 mail problem

pokrakam — Wed, 16 Jul 2014 13:50:22 GMT


linda smith wrote:

The standard email task used to work but because of complex email requirements, i changed it to the activity one.

So it's got to be something in your email code. Perhaps copy the basics from the standard email task and perform your changes incrementally, or remove as much as possible from your code to start with just a blank email and then add bits back in - just to see what causes it to break.

e.g. Maybe you're calling a Z method that calls another Z method in another class that then calls a FM that starts a new DB transaction you're not aware of or something distant like that. I'm sure you get the idea...