Process Mapping Logo

Process Mapping - Forums

Sharing 19 years of knowledge and experience

 
Metastorm BPM forums
Sign up Latest Topics
 
 
 


Reply
  Author   Comment  
NewUser

New Member
Registered:
Posts: 6
Reply with quote  #1 
Hello, I wonder if anyone ran into this issue with Metastorm BPM 7.5.17.

We have noticed recently that when creating a new action item, it suppose to show up in your "ToDO" list immediately.

What happened to us was that most of the time, the new item displays in the "ToDo" list, however, sometime it does not. When it happens, we can see the error message in the eLog table which says "[HANDLE_ALERTS]There were no users on the todo list"

I search Metastorm KB, and there was a known issue in earlier release.

Anyone know what might be wrong? We can not re-produce this error as it happens randomly.


0
sleclerc

Avatar / Picture

Senior Veteran
Registered:
Posts: 365
Reply with quote  #2 
Check to make sure that every user has the following two roles in the eAssignment table:

1. everybody
2. a role name that matches their eUserName (for instance, eUserName = 'sleclerc' and eRoleName = 'sleclerc')

I've run across systems where people are creating users by adding records to the eUsers table only, and without these additional role assignments you will see the problem you have reported.

__________________
Scott

US Navy Seals --> "The only easy day was yesterday"
0
NewUser

New Member
Registered:
Posts: 6
Reply with quote  #3 
Scott, I appreciate your reply, I will check and let you know if this is my problem tomorrow when I get to the office.
0
NewUser

New Member
Registered:
Posts: 6
Reply with quote  #4 
Scott, I checked our eAssignment table, not all users were entered there. Is it true that all users have to be in eAssignment table, are they any exceptions?

This does not explain why sometimes things worked out OK, sometimes it does not?

0
jwoodhull

Member
Registered:
Posts: 10
Reply with quote  #5 
Actually, yes, it is required that all users have at least one row in the eAssignment, specifically where the eRolename = eUsername.  Without this row, the user cannot receive any eAlerts.  The Everybody role should be assigned to all users as well, but is only needed if your processes use it.

When you say it sometimes works and sometimes does not, do you mean that the same user (ex. Joe) can sometimes create folders but other times cannot? 
0
rudean

New Member
Registered:
Posts: 1
Reply with quote  #6 

Quote:
Originally Posted by NewUser
Scott, I appreciate your reply, I will check and let you know if this is my problem tomorrow when I get to the office.

I have the same issue No ToDo list, however my user has the everybody role as well as an assigned role to the eUserName in the eAssignment table yet the problem persists. Any idea why

0
DavidHolliday

Member
Registered:
Posts: 33
Reply with quote  #7 
Here's the note from Metastorm related to that error...

"We were expecting some users to be on the ToDo list, log an error in the designer log.

We log this error when:

    1) We are using static roles
    2) There is a rolename for this action 
    3) This rolename does not resolve to a username."

0
Jerome

Avatar / Picture

Guru
Registered:
Posts: 5,507
Reply with quote  #8 
Quote:
Originally Posted by DavidHolliday
Here's the note from Metastorm related to that error...

"We were expecting some users to be on the ToDo list, log an error in the designer log.

We log this error when:

    1) We are using static roles
    2) There is a rolename for this action 
    3) This rolename does not resolve to a username."

Someone has no idea, then, because the error is related to the alert list, and has nothing whatsoever to do with any 'action' a suggested by this statement.

Had they said 'stage', or, more exactly 'to do list' I would have believed it, because it would be correct.

__________________
Post an example, and we will have a much better idea what the problem is. In about 90% of posts, the problem is one of communication. Examples bridge that gap.
0
DavidHolliday

Member
Registered:
Posts: 33
Reply with quote  #9 
The note is verbatim from the comment in the HANDLE_ALERTS stored procedure that documents the error. Now I guess the Metastorm programmer who coded the procedure may not have known what he or she was doing at the time but I doubt that was the case. More likely he wasn't careful with his wording.

The error is generated during the creation of eAlertScratch table records. It occurs when the static role associated to the To Do list of the next stage is empty (e.g. there are no records associated to it in the eAssignment table) and no records are created as a result.


0
abeebe

Member
Registered:
Posts: 29
Reply with quote  #10 
I know this is an old post, but I am seeing something similar to this, but it is showing up in the application log for the server.  This just started happening and is not allowing any of the to-do or watch lists to get populated.  There were no changes to the database or the processes before this started and nobody seems to know what has caused this (lucky us).

We are running v7.6.4.9 in development and 7.6.4.8 in production.  I am wondering if maybe the table and procedures scripts are out of date and it took a while for it to catch up, but it doesn't seem likely.  I have included a copy of the message from the event log.

If anyone has an idea of what to look at or try, I am all ears...:)

Thanks

Alan

Database exception while trying to raise alerts. Operation: ExecuteSQL. Code: State:S1000,Native:20000,Origin:[Oracle][ODBC][Ora]

. Description: ORA-20000: [HANDLE_ALERTS] call to this procedure failed, the statement number was: 5. The Oracle error number is: -6502. The Oracle error message is: ORA-06502: PL/SQL: numeric or value error: character string buffer too small. The call stack is: ----- PL/SQL Call Stack -----

object line object

handle number name

0x68fd03b20 5653 package body EWORK.EWORK

0x68fd03b20 5939 package body EWORK.EWORK

0x69f670ff8 10 procedure EWORK.ESP_RAISE_ALERTS

0x68de7dc

.

0
abeebe

Member
Registered:
Posts: 29
Reply with quote  #11 
Ok, well after doing tons of research and a little help from the OpenText help desk (actually quite a bit of help) I was able to figure out what was happening.  At first this looked like a procedure issue, but then after we dug further, it seemed to be an eAlert Generator issue.  The help desk responded that the eAlert Generator was locked, so I started digging into the eAlertGeneratorLock table and there was a record in there that would not go away. If I manually deleted it, it would just come right back.

So, then I started looking into the record in the eAlertRequest table and noticed something odd.  the todo list field had a listing of every user that it should be on their todo list, but it didn't have commas between each of the user IDs.  These are populated through a select statement for a dynamic role and when I was removing the hard coded credentials for a different schema, I took out the extra quotes and commas that are needed to properly delineate the user ids in the field of the eAlertRequest table.

Once I went in and put those back in, and cleared out the bad rows in the eAlertRequest table (and deleted the record in the lock table and restarted the engine) everything started working again.  I can't remember if this was a problem that I did in the past, but this is what happens when you manually modify these things.

Hopefully this will help others that may have a similar issue.

Thanks

Alan
0
Previous Topic | Next Topic
Print
Reply

Quick Navigation:


Create your own forum with Website Toolbox!