Long Mail Title side effects

[former_member185167]

Greetings Workflowers,

Is anybody else making use of the handy checkbox in transaction SWPA (scroll to the bottom) called 'Long Mail Title'?

It's very useful in that it allows you to send mails from workflow with subject lines longer than 50 chars. However, it does seem to have some unwanted side effects.

1. As someone here pointed out a while back, the mails sent from a SendMail step now no longer wait for the RSCONN01 batch job and now get sent immediately! Strange, but not a deal breaker.

2. Unless I'm very mistaken, the change also causes SendMail to ignore any positions or pernrs! It will still send to users and email addresses but anything starting with a P or an S is gone.

Has anyone else seen this? I searched SCN and OSS (sorry, SAP Support) and couldn't find anything relevant.

Any suggestions to fix this are welcome.

regards

Rick Bakker

[SandySingh · Accepted solution]

Hi Rick,

Thanks for raising an interesting issue.

Looks like the second issue is a 'data' issue. I have debugged the FM 'SWI_GET_USERS_OF_ORG_UNIT' which internally calls 'RH_STRUC_GET' with evaluation path WF_ORGUS. This evaluation path has following values. Check in TX - OOAW.

10	O	B	002	Is line supervisor of	*	O
20	O	B	003	Incorporates	*	S
30	C	A	007	Describes	*	S
40	A	A	003	Belongs to	*	S
50	S	A	008	Holder	*	US
60	S	A	008	Holder	*	P
70	P	B	208	Is identical to	*	US

I tried passing S, O, P as inputs to SWI_GET_USERS_OF_ORG_UNIT and in every instance it evaluated to USER US. No issues at my end.

I think may be the relationships for this user (with S ,P) are not valid in your system. Check HRP1001 and also check if someone has modified the SAP standard evaluation path  WF_ORGUS.

@ Karri

Thanks for sharing the SAP note.

Regards

sandy

[Former Member · Accepted solution]

No problem.

Rick, actually I think that if emails get sent immediately, that can be a deal breaker. If a test system sends emails to real users' emails, it can create lots of confusion. For example I recently witnessed a case that extended notifications were sent from the test system (old system copy from production) for hundreds of users (without RSCONN01). I am not sure if the reason was this, but in SWNCONFIG the notification priority was set "high". My guess was that if the priority is high, it might send the emails immediately - do you know about this? I haven't had a chance to test this.

Regards,

Karri

[former_member185167 · Accepted solution]

Hi Karri,

Thanks for that Note, I'll see if we can get it applied.

I'm not too worried about mails being sent immediately. A proper Test system should have the proper SCOT settings such that only a chosen few can receive emails. I wouldn't rely on hoping that nobody runs RSCONN01.

It could well be that high priority mails get sent immediately, I'm not sure but I suspect that is indeed the case.

regards

Rick

[former_member185167 · Accepted solution]

Hi Modak and Sandy,

Sorry, I should have explained that with the Long Mail Title unchecked then the SendMail step finds the user from the Position and Pernr. Once I check the box then the user is no longer found. So, I don't think it's a data issue.

In my system the email is fetched from SU01, by the way.

I assume it goes (S ->) P -> US -> email, via PA0105 and then SU01.

regards

Rick

[former_member185167 · Accepted solution]

Hi Sandy,

On second thoughts it could be a data issue - always a likely scenario in a Test system.

As I understand it, by checking that box a whole different mail procedure is run.

I checked WF_ORGUS, it's the same as you listed.

regards

Rick

[former_member185167 · Accepted solution]

Hi All,

The problem seems to be that when you choose the Long Mail Title (mail subjects > 50 chars) then a completely different routine is used for sending mails. This explains the wide range of side effects.

The split happens in fm SWW_SRV_MAIL_SEND.

When LMT is set then (amongst others) fm SWI_GET_USERS_OF_ORG_UNIT is used and it expects to see US entries in table HRP1001. But, some systems don't have that, they have P (Pernrs) instead which should be matched to US via table PA0105.

(By the way, in my system org path WF_WFADM is used)

When LMT isn't set then fm SO_NEW_DOCUMENT_SEND_API1 is eventually used and I'm quite sure it can handle sending mails to Positions or Pernrs correctly (still have to test).

I can't think of an easy fix for this, except to abandon Long Mail Title.

Any suggestions welcome.

regards

Rick Bakker

[I042439 · Accepted solution]

Hi Rick

Did you check the note 855626 - WF: No user is assigned to an organizational unit

and see if WF_WFADM eval path has the entries as per the note?

Regards,

Modak

[SandySingh · Accepted solution]

Hi Rick,

1. You can implement an implicit enhancement in FM SWI_GET_USERS_OF_ORG_UNIT to replace evaluation path WF_WFADM with 'WF_ORGUS'.

FUNCTION SWI_GET_USERS_OF_ORG_UNIT.
*"----------------------------------------------------------------------
*"*"Lokale Schnittstelle:
*"       IMPORTING
*"              OTYPE LIKE  SWHACTOR-OTYPE
*"              OBJID LIKE  SWHACTOR-OBJID
*"       TABLES
*"              USER_LIST STRUCTURE  SWHACTOR
*"       EXCEPTIONS
*"              NOT_FOUND
*"              NO_ACTIVE_PLVAR
*"----------------------------------------------------------------------
  DATA: BEGIN OF LIST OCCURS 100.
          INCLUDE STRUCTURE SWHACTOR.
  DATA: END OF LIST.


  DATA: TASK LIKE SWWORGTASK-TASK_OBJ,
        FOUND.


  IF OTYPE <> 'US'.


    CALL FUNCTION 'RH_STRUC_GET'
         EXPORTING
              ACT_OTYPE      = OTYPE
              ACT_OBJID      = OBJID
              ACT_WEGID      = 'WF_ORGUS'
         TABLES
              RESULT_TAB     = LIST
         EXCEPTIONS
              NO_PLVAR_FOUND = 01
              NO_ENTRY_FOUND = 02.


    CASE SY-SUBRC.
      WHEN 0.
        LOOP AT LIST.
          IF LIST-OTYPE = 'US'.
            FOUND = 'X'.
            USER_LIST-OTYPE = LIST-OTYPE.
            USER_LIST-OBJID = LIST-OBJID.
            COLLECT USER_LIST.
          ENDIF.
        ENDLOOP.
        IF FOUND IS INITIAL.
          RAISE NOT_FOUND.
        ENDIF.
      WHEN 1.
        RAISE NO_ACTIVE_PLVAR.
      WHEN 2.
        RAISE NOT_FOUND.
    ENDCASE.
  ELSE.
    USER_LIST-OTYPE = OTYPE.
    USER_LIST-OBJID = OBJID.
    COLLECT USER_LIST.
  ENDIF.
ENDFUNCTION.

2. You can also EDIT the sap standard evaluation path.

Snapshot of WF_WFADM from OOAW .

10	O	B	002	Is line supervisor of	*	O
20	O	B	003	Incorporates	*	S
30	C	A	007	Describes	*	S
40	A	A	003	Belongs to	*	S
50	S	A	008	Holder	*	*
60	AG	A	007	Describes	*	S
70	AG	A	007	Describes	*	C
80	AG	A	007	Describes	*	O
90	AG	A	007	Describes	*	A
100	AG	A	007	Describes	*	US
110	A	A	008	Holder	*	US
___	__	_	___	_________________________	__	__

Regards

Sandy

[former_member185167 · Accepted solution]

Hi Sandy,

Thanks! You're right, that is the way to fix it. I went for option 2.

I thought evaluation paths only read HRP1001, I was wrong.

I don't think too many people will encounter this error because in later versions (I'm on 702) it seems to be fixed, i.e. FM SWI_GET_USERS_OF_ORG_UNIT uses WF_ORGUS instead of WF_WFADM.

And many of the earlier versions won't have the Long Mail Title option.

Thanks for everyone's help. SCN is great!

regards

Rick Bakker

[I042439]

Hi Rick

The FM SWW_SRV_MAIL_SEND calls FM SWI_GET_USERS_OF_ORG_UNIT somewhere down the line. Application of these notes have changed the logic in such a way that it will break the Org Unit till the Person level only (say, from a position) and does not goes till Users 'US')

The Above function calls FM RH_STRUC_GET with evaluation path WF_WFADM.

Check in your system if this evaluation path is correct.

Helpful note: 855626 - WF: No user is assigned to an organizational unit

Hi Karri

For your line feed issue I found the following note.... maybe this helps?

1758602 - Line break in mails from the workflow

Regards,
Modak

[Former Member]

Modak, that exactly was the note that needed to be implemented to fix the original email line break problem. Anyhow, even after that note there still is small issue with certain email. To be honest it is just a minor issue that I have not put the effort to try to solve it. I am not even sure if it was caused by this whole email title renewal thing...

Kind regards,

Karri

[Former Member]

In general, I remember that the note that was supposed to bring the long email titles (and did it too) caused lots of problems. I had to implement at least few notes (including 1964279) to fix them. The actual email content was somehow broken (unwanted line feeds etc.). Actually I am still seeing one small problem in one certain email in one certain language, and have not been able to find a reason (other than it is most likely caused by the note corrections that were supposed to fix the email content problems).

Anyhow I didn't notice the problem number 2 that you described since we were not sending emails to pernr or position.

Regards,

Karri

[Former Member]

Hi,

There is a note for the RSCONN0 problem. I will try to find it for you.

Kind regards,

Karri

EDIT: note 1964279 should fix the "send immediately" problem.

[I042439]

Hi Rick

Since it's from you.... it's gonna be a tough one!

But no harm in asking a silly question...Do we have infty 0105 (email and user) assigned to the concerned P or S objects?

Meanwhile, search for more specific answer is on!

regards,

modak