How to identify what the actual error is when a new workflow doesn't work when tested in SWDD?

[BaerbelWinkler]

Hi Folks,

a while ago mike.pokraka was kind enough to walk me through an example about how to set up a simple workflow to prompt (new) developers to read our development guidelines. Even though I don't know much about Workflow and ABAP OO, with his help I managed to get this to work in a sandbox system.

Last week I finally started to retrace the steps outlined in Mike's chapter in the Workflow book and "copied" the workflow definition and needed classes/methods from the sandbox-system into the actual development system. Everything generated okay but when I test the workflow from within SWDD, I'm getting several error messages instead of the pop-up message.

From SWIA_DIAG (with message ID/number):

• Error when creating a work item - (SWP044)
• Error when creating a component of type 'Step' - (SWP087)
• Error when processing node '0000000004' (ParForEach index 000000) - (SWP088)
• Error when starting work item 000000600098 - (SWP085)
• Deadline determination failed - (SWF_RUN539)
• Work item 000000600098: Object FLOWITEM method EXECUTE cannot be executed - (WL821)

Most of them don't have a long description and even if there is one, I have a hard time with a) interpreting what it means and b) identifying which of them is the actual "culprit" for the string of messages. The same goes for the search results I found when looking for mentions of the various messages.

Here is how the step history for the failed test looks like:

I already compared the workflow- and task-definitions as well as the classes and methods between the sandbox and the development system and just cannot see a difference. So, perhaps I'm just not interpreting the errors correctly and/or I'm looking in the wrong place(s) for the underlying issue.

Not sure if this is perhaps related but when I defined the task as a standard task in the dev-system, this message was displayed when a customizing transport was created:

"Check the object list of the order (inconsistency in SOBJ)" - (5A378)

I didn't get this message in the sandbox system, so I'm not sure why it got triggered in the dev-system and we (meaning our basis team) haven't yet determined if the indicated report RHSOBJCH can be safely run in the system and what the consequences of that might be as far as transports into the subsequent systems goes.

Can anybody point me in the right direction?

Thanks much and Cheers

Baerbel

[BaerbelWinkler]

In order to not have this hanging in limbo for too long, I selected Rob's response as the best answer. As we however haven't yet found the underlying issue of why this behaves differently in the sandbox and dev systems, I'd like to leave the question open for the time being. I don't really like not knowing/understanding why something isn't working as it should.

[former_member186746 · Accepted solution]

hi Bärbel,

first you should use the technical workflow log to figure out the content of the various workflow containers and check in your workflow where it is used and if it has data. Deadline determination failed could be because you use a parameter as the deadline but it hasn't got a value.

Regarding customizing transport when creating a task, this is because of the agent assignment (pftc additional data-->agent assignment-->maintain, or directly from the yellow button in the builder view) this is considered as HR relationship data in SAP. In most environments you don't have the prompt for changes to the organizational model, then you manually have to include them in a transport using report RHMOVE30. You should check if these values are the same in sandbox and test.

Kind regards, Rob Dielemans

[BaerbelWinkler · Accepted solution]

Thanks for your answer, Rob!

My problem is, that I can look at the workflow containers for a long time but it won't do much good as I just don't know how to properly interpret what I'm seeing. And yes, I'm unfortunately really that clueless (and apparently just got lucky that I got it to work somehow in the sandbox environment)! If it hadn't worked farily quickly in the sandbox-system I wouldn't have tried to recreate this in the dev-system which I only did after a colleague - who knows more about workflow than me - had checked it out.

Cheers

Bärbel

[former_member186746 · Accepted solution]

Hi,

Are workflows working in the dev environment? There is a good chance that SWU3 (automatic workflow customizing which has to be executed in every system using worklfow) was carried out in sandbox but not in dev.

If you have the time then also execute the workflow tutorial in SAP help, this should give you a rough understanding of bindings, container elements, modeling, steps, methods, etc,

https://help.sap.com/saphelp_nw70ehp3/helpdata/en/4f/349c952acb2786e10000000a42189d/frameset.htm

Kind regards, Rob Dielemans

[BaerbelWinkler · Accepted solution]

Thanks, Rob!

I compared SWU3 in the sandbox and dev-systems and both show the same combination of green check-marks and red "X" so no difference there either - at least not at first glance which is all I can do.

I'll take a look at the tutorial which however seems way too involved for the simple task at hand which is just utilising workflow via "confirm end of task" to send a pop-up to a user and therefore doesn't have a lot of functionality or logic.

Cheers

Bärbel

[former_member186746 · Accepted solution]

You can test the workflow and all of its tasks independently using SWUS. That way you can quickly see if the problem is on task level or on step level.

[BaerbelWinkler · Accepted solution]

Thanks again, Rob.

I tried testing via SWUS but I get the same result as via SWDD.

Now for something weird - but I guess that it's actually a clue of where the issue is:

I copied a wrapper program with which the task can be triggered via SAP_WAPI_START_WORKFLOW from the sandbox into the dev-system as I'll need that down the line in any case. With the program I can also display the status of the most recent processing of the task for one or more user(s). When I run this program for my or a colleague's user-ID, the task is actually sussessfully created and the work-item shows up as it should in the business workspace and can be processed. The pop-up gets displayed and can be confirmed via the relevant button. The status of the item then switches to "completed" as expected.

So, the issue I run into in SWDD/SWUS seems to be somewhere "between" the workflow and the task itself. A colleague will take a look later today and will hopefully spot what's wrong or incomplete.

Cheers

Bärbel

[former_member186746 · Accepted solution]

Hi Bärbel,

In that case check the agent assignment in the workflow and also in the task (is it a generic task or is it linked to roles, etc). Also check the difference in user parameters, in HR for instance MOLGA is used in feature which can be used in workflow.

Kind regards, Rob Dielemans

[pokrakam · Accepted solution]

Rob is on the right path, but I’d like to add that the messages are just a hierarchy - two the last one (deadline) is the underlying cause, and the others show how it’s propagated up through the WF system.

So please check the deadline determination - my guess is that something simple is missing.

[BaerbelWinkler · Accepted solution]

Thanks, Mike!

Just before my lunch-break my colleague suggested to take out the deadline determination, so I switched it to "No active deadline monitoring" and testing via SWDD then worked. It also works if I select "WFS Workflow Creation" and make it "+3 Days"

As soon as I switch it back to the expression, I get the error-message again. The expression is copied from the sandbox system where everything works. I already compared the code and settings more than once between the systems and just don't see where there's a difference.

This will most likely turn into one of those cases where I just saw what I "knew" should be shown but actually wasn't! 🙂

Cheers

Baerbel

[anjan_paul · Accepted solution]

Hi,

Just an observation, you call custom Class method to determine the deadline date. Might be there is some issue. Could you please share some code of this.

Thanks

[BaerbelWinkler · Accepted solution]

Hi Anjan,

sure, it's the code suggested by Mike in the chapter of the Workflow-book mentioned in the OP:

* <SIGNATURE>---------------------------------------------------------------------------------+
* | Static Public Method ZCL_WF_UTIL=>GET_FC_DATE
* +-------------------------------------------------------------------------------------------+
* | [--->] I_OFFSET  TYPE  SWD_TIME_O
* | [<-()] R_DATE  TYPE  SWF_DLDATE
* +--------------------------------------------------------------------------------</SIGNATURE>
  METHOD get_fc_date.

  "Calculate n workdays from today based on factory calendar
  CALL FUNCTION 'END_TIME_DETERMINE'
  EXPORTING
  duration  = i_offset
  unit  = 'TAG'
  factory_calendar  = '99'
  IMPORTING
  end_date  = r_date
  EXCEPTIONS
  OTHERS  = 1.

  IF sy-subrc NE 0.
  "Return default date without calendar calculation
  r_date = sy-datum + i_offset.
  ENDIF.

ENDMETHOD.

The only difference between sandbox and dev is that I by now eliminated most of the exceptions in the dev-version and only left "1" in there as shown in the book (I had all of them there before but it didn't seem to have an effect on the behaviour.)

Thanks for taking an interest!

Cheers

Bärbel

[BaerbelWinkler · Accepted solution]

Forgot to mention: when I test the function module via SE37 with the relevant parameters it provides the expected result in the dev-system, so it looks as if the factory calendar is set up properly.

[pokrakam · Accepted solution]

Please check the data types, and also have a look if there are any dumps.

F1+F9 on the "Date" field should tell you the correct type to use. You may need to do a conversion.

Also, the book example is heavily trimmed down - e.g. leaving exceptions out and not bothering with determining the correct factory calendar or including it as a parameter.

Something else to try - this would be a bug in your SAP version - add the input parameter name to the class:

%zcl_wf_util.get_fc_date( i_offset = 3 )%

Sometimes when we press enter, SAP adds it in.

Or else, just for test purposes, hardcode tomorrow's date into the return parameter and see if that works.

[BaerbelWinkler · Accepted solution]

Thanks yet again, Mike!

I just got around to check the code and data types again and still cannot see a difference between the sandbox and the dev-system.

Adding "i_offset" to the expression doesn't help either, I still get the error-message but no dump. As mentioned above, it does work when I go for "WFS Workflow Creation +3 Days", so I think, I'll just stick with that for now.

What is a bit weird - although possibly just for me! - is that I don't seem to be able to have the system jump into debug-mode even if I set breakpoints in the class ZCL_WF_UTIL and switch on system debugging. Is this stuff not "debuggable" because it happens in a different session or does it just need to be activated differently?

[pokrakam · Accepted solution]

Yes it will execute in a new session via RFC. You can use SWUS_WITH_REFERENCE to duplicate a WF and run it in the local session.

Did you try hardcoding a return value?

[BaerbelWinkler · Accepted solution]

Thanks for the tip about SWUS_WITH_REFERENCE! I'll try that tomorrow.

No, I didn't try it with hardcoding as the calculated option via "WFS Workflow Creation" did work - I saw a properly calculated deadline date when I tested this last week. On the other hand, whether or not I set the date will not make much of a difference anyway as deadline monitoring doesn't seem to be active in our dev-systems. So, this will just become another manual task for me to do - or I will simply set up a regular batch job to run my wrapper program in "check status mode" and have it report back to me.

[pokrakam · Accepted solution]

Try hardcoding it anyway, we want to test whether the date is not getting passed back correctly or if it's something to do with the values returned by the FM.

Use SWU3 to set up deadline monitoring. Expand the runtime environment bit, select deadline monitoring and click the generate button. Error monitoring should also be scheduled, and all the other bits before that should also be green.

[BaerbelWinkler · Accepted solution]

This morning I tried different things:

I used SWUS_WITH_REFERENCE and a break-point in ZCL_WF_UTIL.GET_FC_DATE and the processing for the method and function module seems to work and produce the correct result, but the process nonetheless ends with the error.

Then, I changed the code in the method to simply calculate r_date from sy-datum + i_offset as it would do if the FM-call ended in an error. The fields seem to be filled properly but still got the error.

Last I tried with directly assigning the date as expression %DATUM%, but that again ended with the error.

As soon as I switch from "EXP Expression" to "WFS Workflow Creation" things work. And the deadline gets set.

While searching around some more, I happened upon a question from last November which seems to be about the very same issue. Unfortunately, the correct answer hadn't spelled out the details so I added a comment asking about how it was eventually resolved via SWU3 (incidentally, "neat feature" that comments are possible on closed threads....).

(Sorry for the lack of screenshots - I couldn‘t get this posted from my work-computer so tried via my iPad where I didn‘t have them available for easy upload).

[pokrakam · Accepted solution]

This is indeed bizarre, and should work very simply without such weirdness.

But I have another small suspicion - can you clear the time zone field and/or set a time zone for user WF-Batch?

[jcgood25 · Accepted solution]

Jeremy Good - testing a suspicion on the Former Member labels appearing.

[BaerbelWinkler · Accepted solution]

Mike - unfortunately, I cannot set the time zone for user WF-Batch as I just now realised that the user doesn't even exist in the dev-system I'm building the workflow in. I cannot check with our basis-team at the moment but the reason for this is most likely that no actual workflows are needed in this particular dev-system. It just functions as a central dev-system for all things SAP- and most Z-DDIC-objects to keep those in-synch across two otherwise seperate landscapes which each has its own actual development system. It was just easier - or so I thought! - to build this stuff once and release it into both landscapes in one go instead of having to develop everything twice.

[david_flad3]

I'd be inclined to also check the workflow customizing -- is the runtime configuration correct, was the workflow background process initiated by a user with SAP_ALL instead of a user with restricted authorizations, and things of this type. This has caught us before when spinning up a new system in the middle of an existing landscape, or performing a copy from a higher level system back into a lower level system.

On the HR side, consider as well anything that expects to know the HR plan ID, and other org elements in order to determine the right org level item to pull information from.

Sometimes it's the little things that drive us crazy most often...