FM SO_NEW_DOCUMENT_ATT_SEND_API1 mail problem

[Former Member]

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

[Former Member]

Hi Smith,

Try to give the following submit after the commit work,

        COMMIT WORK.

        SUBMIT RSCONN01 WITH MODE = 'INT' AND RETURN.

Regards,

John K.

[pokrakam]

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

[Former Member]

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

[pokrakam]

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

[Former Member]

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,

LS

[pokrakam]

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

[Former Member]

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

[pokrakam]

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?

[Former Member]

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

[pokrakam]

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...

[Former Member]

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

[Former Member]

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

LS

[Former Member]

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. [email protected]

Kind regards, Rob Dielemans

[Former Member]

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

[anjan_paul]

Hi,

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

[Former Member]

Hi,

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

Thanks