nav[aria-label="Primary Navigation"] { padding: 0; & ul { list-style: none; width: 100%; display: flex; flex-direction: row; justify-content: start; align-items: start; gap: 30px; padding: 0; & li { margin: 0; } & ul li { list-style: none; } } }

External task can't start

junwang

Hi there,

I upgraded TS 6.7.2 to 7.3.1 on Windows 2003 Standard Edition. Publish workflow doesn't work anymore after upgrading. I can see the task is CreateEdition, but the Java class is not called, the external task is the subclass of CSURLExternalTask.

One of the step of workflow is creating an edition using external task, which stuck in workflow. Other external tasks before the creating edition work fine, and the owner of the task is $iw-user, the owner of creating edition task is $iw_areaowner, I wonder whether it is a permission issue, but the owner of the branch is a master user and has administrator role in the branch. I check the administrator role --> Branch-Specific tab-->Content Management--> Publish Edition is checked.

There is no much error in logs, the only one I can find is in access.log.

127.0.0.1 - - [16/May/2013:10:44:33 -0400] "POST /iw-cc/urlexternaltask HTTP/1.1" 500 2880 0 -
127.0.0.1 - - [16/May/2013:10:44:31 -0400] "POST /iw-cc/urlexternaltask HTTP/1.1" 302 - 2 -

Anyone can shed a light on it? Thanks.

Find more posts tagged with

Comments

Rick Poulin

That snippet shows that the call is executing, but failing (returning an HTTP 500 error). That means it's throwing an exception, so it either can't find/initiate your class, or your class is throwing an error.

Double-check that your ClassName variable doesn't have any typos, and that it's actually in the app's classpath. Then, turn on debug logging on your class and go hunting for exception messages in the logs. If the person that wrote the class didn't actually use proper logging and exception handling, then I give you permission to slap them silly, even if you're the one who wrote it. Smiley Happy

junwang

That snippet shows that the call is executing, but failing (returning an HTTP 500 error). That means it's throwing an exception, so it either can't find/initiate your class, or your class is throwing an error.

Double-check that your ClassName variable doesn't have any typos, and that it's actually in the app's classpath. Then, turn on debug logging on your class and go hunting for exception messages in the logs. If the person that wrote the class didn't actually use proper logging and exception handling, then I give you permission to slap them silly, even if you're the one who wrote it.

Thanks rpoulin to reply. I give more test on it.

The ClassName variable is set properly, the class is in the classpath, same jar file with other external class. I am not sure what you mean for the "Turn on debug logging on your class", but I change two external class to print some message in the constructor to make sure the class is loaded, one is the first external task (AddComments), and anther one is the CreateEditon.

I login using my user name, and the first external task AddComments print the message into server.log, but the CreateEditon didn't print anything.

I end the job, login as the branch owner, and submit same workflow. The first external task (AddComments) stuck there, and print nothing.

May relate with the branch owner or permissions, but I don't know which part I should check.

Thanks,

Jun

junwang

I spent a lot of time to check, compare, update the user permissions, user groups and roles. Finally, I updated the iwcache.xml, and did a iwreset, then iwcache.xml reflected the changes I made in tsusers.xml. And the workflow worked properly.

iwcache.xml had some corrupted data, and it can't be updated until I manually change it, which causes the problem.

Rick Poulin

I am not sure what you mean for the "Turn on debug logging on your class"

I mean your Java code should be written to use something like this, so you can properly debug your code (understanding what's happening rather than doing an incremental change+test loop every time you need to fix something):


private static final Log LOGGER = LogFactory.getLog(MyCustomTask.class);

public void execute() {
  if (LOGGER.isDebugEnabled()) {
    LOGGER.debug("I'm doing stuff!");
  }
  /* ... */
}

Then, you can control logging levels via the log4j.xml file, or /iw-cc/command/iw.base.loggers. Not only will this make your life easier, it's also a baseline standard practice in Java, which means that the person who takes over after you is less likely to hate your code. Smiley Wink

DEAPI to create aggregation__cwong.rptdesign

junwang

First, that is not my code, I am doing upgrade to make it work.

Second, not matter which way we enable debug, it wouldn't show the log. As I said, the class couldn't be load.

Third, the root cause of the issue is TeamSite blocks to load the class if it thinks the permission is wrong. If you can provide more information about how TeamSite uses the permission to control the workflow, that will be helpful.

Thanks.

Topic_39521__Hashmap access in HTML5 Chart.rptdesign

Rick Poulin

First, that is not my code, I am doing upgrade to make it work.

I'm not assigning blame. I was merely expanding on my suggestion, since you said you didn't understand what I meant.

Second, not matter which way we enable debug, it wouldn't show the log. As I said, the class couldn't be load.

Logging may or may not have helped in this case, depending on where permissions were getting in the way. I understand that you had already solved your issue; I'm just trying to help you debug new ones more easily later.

Third, the root cause of the issue is TeamSite blocks to load the class if it thinks the permission is wrong. If you can provide more information about how TeamSite uses the permission to control the workflow, that will be helpful.

See, this is the part where logging would help. I'm not convinced that your class doesn't execute at all (permissions alone can't prevent your class from getting called by the WF engine). Instead, it's more likely that your class executes but then dies because a CSSDK call fails on an uncaught CSAuthorizationException. But then I haven't seen your workflow or your Java code, so that's just my guess.

junwang

I enabled JBoss debug mode to trace code in Eclipse, so when you say "turn on debug logging on your class", I thought you may talk about something feature in JBoss App server that I don't know. That is why I ask what you mean.

I understand now, you mean use a logger to generate logs. Our applicaiton already injected a log service into the external task using Spring, which is based on Log4J, similar to your code. But the logger doesn't work.

The problem is the Java external task Object can't be created, the class doesn't execute at all. As I said, I printed some comments in the "constructor", the log file will should the message if the object is created. But I got nothing if I use workarea owner, and I can see the output when I switch to my account.

If I have TeamSite source code I can look at the super class, and see how it instantiates the oject, but I can't.

Rick Poulin

I understand now, you mean use a logger to generate logs. Our applicaiton already injected a log service into the external task using Spring, which is based on Log4J, similar to your code. But the logger doesn't work.

Well, depends on what you're doing. AOP may not work with ClassName, because the WF engine uses reflection to instantiate your class, which may bypass the AOP encapsulation. With TaskBeanId, passing in a Log instance via dependency injection is just plain bad, because then you don't know where your messaging came from, and you can't control logging levels on a class-by-class level. Does your logging actually print to file when your workflow goes through successfully? Feels like you have something weird here.

I shudder to think about not having proper logging. You can't really attach a debugger to a prod box, after all.

see how it instantiates the oject

As I understand it, it depends on which task variable you use. If using ClassName, then it does something along the lines of


Class.forName(cstask.getVariable("ClassName")).getMethod("execute", CSClient.class, CSTask.class, Hashtable.class).invoke(csclient, cstask, params);

whereas using TaskBeanId (without ClassName) leads to something along the lines of


((CSURLExternalTask) applicationContext.getBean(cstask.getVariable("TaskBeanId"))).execute(csclient, cstask, params);

Note that in both cases, it has to first instantiate a CSClient and a CSTask (parent object) from the context, meaning that you need a valid session token, and the user running the task needs to have access to the context area and so on.. but it can't possibly check that your user has access to do whatever your custom code is about to do. Thus, if a UserTask would work given the context, then your URLExternalTask will also work and trigger your class (provided it can be resolved).