| |
|
RSS Feed - WebSphere MQ Support
|
RSS Feed - Message Broker Support
|
  |
|
| Ineligibile users rec. work |
« View previous topic :: View next topic » |
| Author |
Message
|
| callocam |
 Posted: Mon Jul 21, 2008 7:47 am Post subject: Ineligibile users rec. work |
 |
|
Novice
Joined: 09 Jun 2006
Posts: 14
Location: Middletown, Ct
|
Greetings folks,
Our business community has not been able to determine when this first happened, maybe a few months ago, but we have identified users are receiving work they are not qualified for.
These worktasks are assigned to a team called TRNATMED and the users are coded in the FDL as such:
PERSON 'X017217'
PASSWORD %6DB73D3F6698A008CF76BE9AB8ED27E9
GROUP 'ECHSGRP'
SYSTEM 'ECHSSYS'
FIRST_NAME 'JACK'
LAST_NAME 'SMITH'
LEVEL 0
IS_NOT_ABSENT
RESET_ABSENT
END 'X017217'
UPDATE PERSON 'X017217'
GROUP 'ECHSGRP'
SYSTEM 'ECHSSYS'
AUTHORIZED_FOR WORKITEMS_OF 'TRNATMED'
END 'X017217'
But somehow these users are getting work assigned to team TRNATDEN.
I have reviewed a output of the FDL export from production and these users have the only single AUTHORIZED_FOR statement.
My only suggestion was delete the users from workflow and then readd them back in. We have had issues this past winter where users were in the FDL but for some reason were not able to log into the application.
So I prepared a FDL DELETE statement and new FDL add to get them back into the system.
My DBA took a FDL export before picture, and then we ran the DELETE command. It got good codes. Ran another export and wouldn't you know it, the user is still in the export AFTER the delete?!!
Having no other options, we ran the add PERSON and it said the user was CREATED. So I don't understand why did the prev. export still have the user in the FDL? Is it some sort of whacky logical delete?
In any event the last time we tried this, the user was still pulling the incorrect work.
There hasn't been any changes to this part of the application is quite some time.
The filter that pulls work for these users is as follows:
"STATE = READY AND NAME = 'EC Ready' "
Again, we haven't changed this code in a very long time, and the issue isn't consistent across the application, only a very few users (3 to 5). While there are hundreds of users that support this part of the application.
Any feedback or ideas are appreciated. As anyone else run across this issue?
Thanks muchly!
Ettore |
|
| Back to top |
|
 |
| hos |
| Posted: Tue Jul 22, 2008 4:44 am Post subject: |
|
|
Chevalier
Joined: 03 Feb 2002
Posts: 470
|
This sounds strange!
Check the following:
- users cannot be deleted if they are still involved in some workflow. Recheck
the return code of fmcibie whether the UserID is REALLY deleted. Use the
Sustitute Person Tool described in the Administration Guide to make a
person eligible for deletion.
- what parameters did you use for fmcibie? See Getting Started with
Buildtime for a description of the various parameters. For instance you can
use fmcibie /e=out.fdl /u=admin /p=pwd /c"EXPORT PERSON *" to export
all persons. Did you use the default configurationID? Did you use the -f or
-o option (-f does NOT delete)?
- there is a known limitation w.r.t. UPDATE Person:it does not replace the
AUTHORIZED_FOR setting, but adds the new authorization. Use REPLACE
Person instead.
- do you have an LDAP bridge running which synchronizes an LDAP directory
with the MQWF RT DB? |
|
| Back to top |
|
|
| jmac |
| Posted: Tue Jul 22, 2008 5:24 am Post subject: |
|
|
Jedi Knight
Joined: 27 Jun 2001
Posts: 3081
Location: EmeriCon, LLC
|
Ettore:
After you try everything Volker has suggested, IF you are still not having any luck export all of your Person objects, zip it up and email to me and I will have a look.
Also, IF running any of the steps Volker listed, let me know what the results were.
John
_________________
John McDonald
RETIRED |
|
| Back to top |
|
|
| callocam |
| Posted: Fri Aug 22, 2008 5:44 am Post subject: |
|
|
Novice
Joined: 09 Jun 2006
Posts: 14
Location: Middletown, Ct
|
Sorry for the delay on your replies.
Our basic process has been to:
* export the entire FDL to identify the user
* DELETE PERSON FDL
* export FDL again to confirm the user is gone
* add the PERSON back in with the AUTH for statement
* export FDL to confirm the user is readded.
We did have a DBA issue where I believe we were pointing to a incorrect version of the database. Because as I said in my previous post the PERSON wasn't actually deleted. We have since straightened that out.
I asked my DBA to provide me with the parms we use in the JCL:
// PARM='ENVAR("_CEE_ENVFILE=DD:FMCHEENV"),ABTERMENC(ABEND)
// /-u ADMIN -p password -i -o -t'
Yes, I'm aware that if a user ownes any work, we can not delete/readd them back. But one thing I've found frustrating is that on occasion the users don't log off the application as they should and that leaves orphaned rows on the SESSION table. So when we try to delete them it says that the user is still logged in and the rows won't expire from the table for 24 hours. By that time the user has already gone back on the job and the process happens again.
Is there a danger of deleting those orphaned rows from the SESSION table? I'm guessing that there would be but would be nice to hear from you guys that I'm correct.
Well, we tried this process again for a single qualified user the other day, and sure enough, they are still pulling the incorrect work. Even though our plan worked well. Very strange indeed.
Lastly, we do not have a way to synch the LDAP users with runtime. There is a service we use that keeps the users in synch.
Thank you for your help thus far. |
|
| Back to top |
|
|
| jmac |
| Posted: Fri Aug 22, 2008 8:10 am Post subject: |
|
|
Jedi Knight
Joined: 27 Jun 2001
Posts: 3081
Location: EmeriCon, LLC
|
Ettore:
If I am understanding you correctly you can try something like the following (NOTE: I have never done this.):
You can change the Session Expiration time on the Session Tab of the Dimension properties the default is 20 hours. If you were to change this to something like 3 hours, you might find that many of these "orphaned" rows are gone.
I am sure you know I would be very worried about direct updates to the tables. You would be best to talk directly to the workflow lab to find out if this is advisable. Perhaps Volker will weigh in on this post.
Hope all is going well,
John
_________________
John McDonald
RETIRED |
|
| Back to top |
|
|
| callocam |
| Posted: Fri Aug 22, 2008 10:21 am Post subject: |
|
|
Novice
Joined: 09 Jun 2006
Posts: 14
Location: Middletown, Ct
|
Hey John,
Yea man...things are alright. Just bought a pellet stove to heat the house for next winter. Figure it a good investiment these days. Guessing you may not need such things in your neck of the woods. 
If I were to make this change, do I need to do a FDL import of the entire DOMAIN block or just the SESSION info below in RED?
Any ideas on why I can't get past the root issue of the users pulling incorrect work? I may add that all these users are offshore. Any reason you can think of that working 3000 miles away from the runtime database would cause this? LOL
// ---------------------------------------------------------------------------
// Domain
// ---------------------------------------------------------------------------
DOMAIN 'DOMAIN'
DESCRIPTION 'Default domain'
DOCUMENTATION 'Default domain (documentation field)'
MAXIMUM_MESSAGE_SIZE 4000000 B
// -------------------------------------------------------------------------
SERVER
TYPE EXECUTION_SERVER
CHECK_INTERVAL 5 MINUTES
NUMBER_OF_INSTANCES 10
EXTERNAL_CONTROL NO
NO IMMEDIATE_CLEANUP
NAVIGATION_TRANSACTION_THRESHOLD 1999999999
// -------------------------------------------------------------------------
SERVER
TYPE SCHEDULING_SERVER
START_MODE DEFERRED
CHECK_INTERVAL 5 MINUTES
CREATE_NOTIFICATION_ITEMS_THRESHOLD 10
DELETE_NOTIFICATION_ITEMS_THRESHOLD 100
NOTIFICATION_CHECK_INTERVAL 5 MINUTES
// -------------------------------------------------------------------------
SERVER
TYPE CLEANUP_SERVER
START_MODE DEFERRED
START_TIME EVERY DAY AT 0:00
STOP_TIME EVERY DAY AT 6:00
CHECK_INTERVAL 5 MINUTES
CLEANUP_TIME 7 DAYS
CLEANUP_DELAY_TIME 1 HOURS
// -------------------------------------------------------------------------
SERVER
TYPE PROGRAM_EXECUTION_SERVER
EXTERNAL_CONTROL NO
IMPLEMENTATION_SUPPORT EXTERNAL
NUMBER_OF_INSTANCES 10
PLATFORM OS390
SUPPORT_MODE SAFE
USER_SUPPORT AGENT
// -------------------------------------------------------------------------
PROGRAM_EXECUTION_AGENT
DLL_LOAD_MODE UNLIMITED
// -------------------------------------------------------------------------
PROCESS
NO AUDIT_TO_DB
NO AUDIT_TO_MQ
NOTIFICATION_MODE RUN
REFRESH_POLICY PULL
KEEP_WORKITEMS NEVER
KEEP_PROCESSES NEVER
NO AUTONOMY
// -------------------------------------------------------------------------
ACTIVITY
CHECKOUT_POSSIBLE
INCLUDE_PROCESS_ASSIGNMENT
PREFER_LOCAL_USERS
PREFER_NON_ABSENT_USERS
NO SUBSTITUTION
NOTIFICATION_SUBSTITUTION
NO DUPLICATE_NOTIFICATION
AUDIT_FILTER_DB ''
AUDIT_FILTER_MQ ''
// -------------------------------------------------------------------------
PROGRAM
FENCED_MODE
KEEP_LOADED
EXECUTION_MODE NORMAL
EXECUTION_USER AGENT
INPUT_CONTAINER_ACCESS
OUTPUT_CONTAINER_ACCESS
NO DLL_V2_COMPATIBILITY
NOT TRUSTED
// -------------------------------------------------------------------------
IMPORT
DO NOT OVERWRITE
// -------------------------------------------------------------------------
OPERATION
SYSTEM_QUALIFIER 'Q18XP'
OPERATION_MODE ROBUST
EXTERNAL_RESTART NO
MAXIMUM_QUERY_MESSAGE_SIZE 4000000 B
CLIENT_MESSAGE_EXPIRATION_TIME 15 MINUTES
MESSAGE_RETAIN_PERIOD 7 DAYS
ERROR_RETAIN_PERIOD 7 DAYS
MESSAGE_RETRY_LIMIT 5
// -------------------------------------------------------------------------
SESSION
SESSION_EXPIRATION_TIME 20 HOURS SESSION_EXPIRATION_CHECK_INTERVAL 1 HOURS
NO UNIFIED_LOGON
END 'DOMAIN' |
|
| Back to top |
|
|
| jmac |
| Posted: Fri Aug 22, 2008 10:33 am Post subject: |
|
|
Jedi Knight
Joined: 27 Jun 2001
Posts: 3081
Location: EmeriCon, LLC
|
The entire domain FDL would have to be imported an and a restart of MQWF would be required, because the Domain info is only read at startup time.
I just realized one other possible way to solve your problem. If you bring MQWF down and then back up, I am pretty sure that will clear the Session table. (not positive on zOS, but pretty sure it should). Maybe that would be the easiest way to do this, get them to cycle the system prior to running your utility.
Let me know how it goes
_________________
John McDonald
RETIRED |
|
| Back to top |
|
|
| hos |
| Posted: Sun Aug 24, 2008 11:33 pm Post subject: |
|
|
Chevalier
Joined: 03 Feb 2002
Posts: 470
|
Hi guys, here are my thoughts:
If you can afford to stop and restart MQWF this will certainly clean up the session table. However no user can actually work with the system during this time.
Shortening the default session expiration time is risky because MQWF does not monitor the activities of a logged on user. Means, that a user is logged off after this time even if he is busy working.
I do not see a problem to delete entries in the session table if you exactly know which one to delete. Session IDs are not reused if a user logs in again, so an orphan session entry is no longer needed by MQWF.
With respect to your root problem:
IF you are able to sort out the DB and import problems, means you have verified that the users in the runtime DB have the intended authorizations, and you are still seeing the problem, my guess is that there is an error in you business model. Check the 'Owner' field of the workitem in question. Is it really TRNATMED? |
|
| Back to top |
|
|
|
|
|
| |
|
Page 1 of 1 |
|
You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot vote in polls in this forum
|
|
|
|
