Workflow Rule returns the wrong Agent from Responsibilities

[michaelhansenx]

Hello experts,

I have a problem with a rule not returning the expected agent in production system. We are using this rule to determine who should receive notifications from QM when something is registered as scrap. The problem occurs for all responsibility entries for Plant 2501 in the work center interval 100000 to 10000999.

The problem started on around 15. august and nothing like it has been registered before.

Here are the facts, as I have been able to ascertain:

The Rule in question has a lot of different possible responsibilities:

These responsibilities are selected based on Work Center and Plant.

We have a lot different responsible people in that interval (all of them priority 99) and one entry for the entire interval with priority 01. See below for two examples:

User A

User B

We also have a BUS method for ZBUS2116 called GetResponsibilities that run FM RH_GET_ACTORS along with some other custom validations.

I have checked the transport logs and nothing has been changed in this method since it was implemented 11 months ago.

When I run the RH_GET_ACTORS method manually twice in a row for the Plant 2501 and Work Center 10000193 I get two different results. The first result is User A and then User B when I run it a second time. The same results come if I run a simulation of the rule via PFAC, first time user A and second time user B.

As alreay stated this happened 'out of the blue' over a weekend. I know that nothing happens out of the blue, something has changed, somewhere.

Does any of you fine folks have any suggestions as to where i should look? I am sure there is some customizing somewhere that has been changed that I don't know about.

Thanks.

[michaelhansenx]

The problem has now been further simplified.

Turns out my system is having issues handling Responsibilities in workflow rules when priority 99 is used with a secondary priority.

Example:

User A has priority 99 and User B has prio 01.

When I simulate the rule in PFAC I get User A first time I test. And I get user B second time I test.

Now I change prio on User A to 90 and keep prio at 01 for User B.

Simulation in PFAC now gives me User A no matter how many times I press Test.

Does this sound like something anybody has seen before?

I have had suggestions of restarting the application server but that is not something we just do in my company. Last time this was done was back in juli.

UPDATE:

I have now talked to our basis guy and the problem exists on all of our 6 application servers so he thinks it is unlikely to be buffer issue as buffers are separate to each server.

/UPDATE

Any suggestions other than restart, will be much appreciated.

Thanks
.

Michael

[kaus19d]

, Looks like that your matter has been resolved & also would like to update you that we are not in your chair to use/see your SAP system. But the thing is in every company its a bit different since we take customizing service duly provided by our ABAP persons. Also different approaches by different person in different companies in different locations. So, we can provide some general solutions but ultimately the ultimate solution lies in your hand as because you are the only person available to implement solution & test that.

Coming back to you question,

Any suggestions other than restart

Well you can try searching & implementing further ideas, there is something called Idea Place here for that. Some other possible suggestions are already given by us. Other knowledge, well, I have never met any person in the world who can claim to have all the knowledge if even a single subject also.

So now that it seems that the issue is resolved, would like to take the opportunity to ask you to close the Discussion-Thread. Please follow,

Thanks,

Kaushik

[michaelhansenx]

I'm sorry if I have offended you in any way or gave the impression that I wanted you to solve the problem for me. This has never been my intention. And I apologize if my replies have come across as that.

I appreciate the feedback I have received and it has helped me to get a better understanding of what to do next time something similar happens. Some of the suggestions I have received I have been able to test and others I need further arguments to be able to push through my organization (ie. the restart of servers).

When that is said, I don't think my problem has been explained. I have found a workaround (changing the priority to anything but 99) with your capable assistance but I am no closer to explaining why this became a problem. Yes, you do not have access to my system and cannot see what I see and that is why I asked for suggestions for where to look. I just don't accept that a restart is a solution unless it is combined with an explanation of what originally went wrong.

But if I offend people by keeping this thread open, I will close it.

Thanks.

[kaus19d]

Hi,

I did not say that anyone is offended by anyone. Its just the way that if you have made your system work again, that means you can still work with that. It is obvious that whenever if there is another or similar other issue in the system, you can open another new discussion-thread. But keeping a discussion-thread, means we will again & again come by your thread, which means there are also so many of our friends whose production is stopped at this moment & we can at that time if can provide assistance to them, they can still give answer to their bosses. I am not saying that you are anyhow less or your matter does not have a priority. Everyone matter here in SCN has their equal priority. What I was trying to suggest that as you have found a way to make it work, then further on you also can do some research, follow Wiki in SCN, Browse Notes & also do a lot of work on your own. We are not here to like give you a solution on what are the things or possibilities that you can find out. That is why in SCN there is a Rule we have got called as Search Before Post considering the possibilities of finding a solution. You are too a valuable SCN member & we all are SCN members here, there is none smaller or in higher in terms of knowledge as you know. That part you also have observed when you posted the matter, as soon we got your matter we also put our effort to help you & you also actively updated the result like I asked you to use 10 instead of 99, which after you implemented, then only further your technical mind started to give some technical answers. That part also you have implemented & updated. We are also happy to know that you got some work-around regarding this matter. Technically analyzing any matter like why this happened & what are the base for that & like what would have happened if I have done that instead of doing like this, its actually called R&D which is very good if you want to be a more knowledgeable person & the more technical you become, you get more priority in market or anywhere too, even if there is any salary or a designation involved, but always the knowledgeable are respected everywhere. But doing this kind of finding in-depth technical answers is better, if consult a more experience person directly, if you have such contact rather then in a thread where you got a work-around. We are here merely to guide you on your SAP matters. But the main activity has to be carried by you only like you want to boost you knowledge base, then you have to do some research on your own. We are also doing a lot of research, interacting with many scenarios, then only we are getting to know what other possibilities or work-around can happen. That is why before any product launch, SAP also provides to some of their customers pre-launch service & also immediate assistance like immediate fixing by releasing pre-launch OSS notes which are applicable to those customer's special installation only for that moment.

Also follow,

Thanks,

Kaushik

[former_member185167]

Don't worry Michael, you didn't do anything wrong!

This is a fascinating case, sounds like a SAP bug to me.

I would try to reproduce this with the simplest possible case and then report it to SAP.

Well done to Kaushik for finding the workaround.

[michaelhansenx]

Hi Rick,

I think I might have found the problem. There is a note 2183293 - Resolution of responsibilities: Incomplete results for repeat call.

The description for this note pretty much describes my problem.

Why I didn't find this note earlier is beyond me. But i guess I just need more experience in searching the notes database.

We are currently upgrading to EHP7 which includes this note so I am unable to perform reliable testing in my Q system.

EHP7 hits our production system in three weeks. I will update this thread at that time.