Skip to Content

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

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

Add comment
10|10000 characters needed characters exceeded

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

  • Get RSS Feed

2 Answers

  • Best Answer
    May 14 at 12:17 PM

    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

    Add comment
    10|10000 characters needed characters exceeded

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

  • May 22 at 09:02 PM

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

    Add comment
    10|10000 characters needed characters exceeded