|
RSS Feed - WebSphere MQ Support
|
RSS Feed - Message Broker Support
|
 |
|
[SOLVED] Activity throws FMC00119E Not authorized |
« View previous topic :: View next topic » |
Author |
Message
|
mphartman |
Posted: Thu Jun 19, 2003 11:25 am Post subject: [SOLVED] Activity throws FMC00119E Not authorized |
|
|
Newbie
Joined: 19 Jun 2003 Posts: 7 Location: Iowa
|
In trying to run an activity implementation written in Java and invoked by a Program Execuation Agent (PEA), an FmcException occurs as follows:
Code: |
com.ibm.workflow.api.FmcException:
FMC38009E MQSeries Workflow API Error :
API Return Code : 119
Error Origin : /projects/fmc/drvp/lbld/v340/src/fmcjccon.cxx, line 1275
Error Message : FMC00119E Not authorized
Nested Exception : None
at com.ibm.workflow.api.loc.ExecutionAgentImpl.inContainer(ExecutionAgentImpl.java:73)
at com.sptech.mqwf.activities.DumpActivity.main(DumpActivity.java:34)
|
The PEA (fmcxspea) is started under userid ADMIN. The activity is also assigned as ADMIN.
System:
AIX 4.3
MQWF 3.4.0.1
MQ 5.3.0.1
DB2 8.1.0.1
Last edited by mphartman on Mon Jun 23, 2003 5:56 pm; edited 1 time in total |
|
Back to top |
|
 |
vennela |
Posted: Thu Jun 19, 2003 1:33 pm Post subject: |
|
|
 Jedi Knight
Joined: 11 Aug 2002 Posts: 4055 Location: Hyderabad, India
|
How are you testing this.
Are you using a fat client?
What makes you believe that the PEA is running under ADMIN
Not sure what is happening but trying to understand the problem by asking more questions.
-------
Venny |
|
Back to top |
|
 |
mphartman |
Posted: Fri Jun 20, 2003 7:18 am Post subject: |
|
|
Newbie
Joined: 19 Jun 2003 Posts: 7 Location: Iowa
|
I'm actually testing it using a custom web client (IBM's Content Manager eClient).
The process is very simple. Three program activities. The first and last basically do nothing. The middle's program is set to invoke the user's program execution agent. The staff assignment is set to ADMIN.
The PEA is started manually using the following command:
Code: |
fmcxspea -u=ADMIN -p=password -y=FMC -f |
The program is declared to run a shell script which in turn executes a Java program.
The program is a simple Java program that simply reads the input container, prints the contents to a file, copies the values to the output container, sets _RC to 0, sets the output container and exits. |
|
Back to top |
|
 |
vennela |
Posted: Fri Jun 20, 2003 7:41 am Post subject: |
|
|
 Jedi Knight
Joined: 11 Aug 2002 Posts: 4055 Location: Hyderabad, India
|
Let me make a couple of suggestions here.
Since this is an authorization problem, it would help to know under what user id the shell is executed and the java program is executed.
Before calling the java program, insert a whoami line in the script.
Maybe you can do the same in the java program, before calling any of the workflow apis.
Another thing is:
Why do you want to call a java program through a shell script. Why don't you invoke the java program directly? IS there any reason for you not doing so? |
|
Back to top |
|
 |
mphartman |
Posted: Fri Jun 20, 2003 8:26 am Post subject: |
|
|
Newbie
Joined: 19 Jun 2003 Posts: 7 Location: Iowa
|
The queue manager, workflow servers, and PEA are all running under user fmc. Running as root results in the same problem.
The choice to run a shell script is one of manageability. It is easier to specify a simple shell script name rather than the long command line required to run the java executable with all the classpath, class name, arguments, properties, etc. In addition, if I want to swap out the class to run, it isn't an FDL change but rather a change in the script.
The permissions on the shell script give exec permission to owner, group, and other although this doesn't appear to be an OS permission problem by virtue the script and the Java program are invoked.
Placing a whoami in the script resulted in fmc. Not sure how to confirm this in the Java code, but since that user ran the script and is the one that invoked the Java program, I'd assume that that is the user under which the program runs. I should say that the fmc user is a os-level user not a MQWF user. |
|
Back to top |
|
 |
vennela |
Posted: Fri Jun 20, 2003 11:31 am Post subject: |
|
|
 Jedi Knight
Joined: 11 Aug 2002 Posts: 4055 Location: Hyderabad, India
|
Yes:
fmc is definitely an Operating System lever user and not a WMQWF user.
There are two things that you can try (if you feel like).
1. Add a user fmc to Workflow and run the PEA under fmc and see what happens to the program (assign the program activity to fmc).
2. In your java program prnt out the following:
a) System.getProperty("user.name");
b) From your ExecutionAgent userId
c) From your ExecutionAgent remoteUserId
I really do not know the difference between the last two but they may give you a clue.
Also, similar to 2 a) you may try setting the user.name to "ADMIN" and if you don't get a security exception or some other exception, that may solve the problem.
Quote: |
The choice to run a shell script is one of manageability. It is easier to specify a simple shell script name rather than the long command line required to run the java executable with all the classpath, class name, arguments, properties, etc. In addition, if I want to swap out the class to run, it isn't an FDL change but rather a change in the script. |
I think I like the above reasoning. It infact is well manageable.
Keep us updated on your success.
-------
Venny |
|
Back to top |
|
 |
mphartman |
Posted: Mon Jun 23, 2003 8:06 am Post subject: |
|
|
Newbie
Joined: 19 Jun 2003 Posts: 7 Location: Iowa
|
Response from Volker Hoss with IBM WebSphere MQ Workflow Development on ibm.software.websphere.mqworkflow shed some light on this.
Volker said:
Quote: |
you didn't mention that your JAVA program is not started directly by the PEA. This makes an important difference. You have to define your Program to be 'TRUSTED' so that the PEA accepts container requests. Please see the Programming Guide for further info about trusted programs running on behalf of an activity implementation. |
So because the PEA invoke a shell script which in turn invokes another process that subprocess is "untrusted" and hence "Not Authorized".
Refer to page 163 of the WebSphere MQ Programming Guide for a deeper discussion.
I've not figured out how a shell script can (or if it can) obtain the ProgramID needed to pass on to the subprogram. My fear is it can't and the Program definition in workflow will need to invoke the Java program directly. |
|
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
|
|
|
|