IWSOAPException in TeamPortal

TeamSite 5.5.2 on Solaris
TeamPortal for IBM on Solaris

The My TeamSite portlet in TeamPortal renders blank for one of the users registered in our system. I've tracked this down to line 87 in the myTeamSite.jsp file:

> fileArray = portalClient.getModifiedFiles(wa.getVPath(),null, true)

I've checked and confirmed that the wa.getVPath() argument is returning a valid value.

This throws an IWSOAPException exception that is caught in the clause below:

catch (IWSOAPException iwex)
{
((PortletContext)application).getLog().error(iwex.getMessage());
}

I threw in a System.err.println statement here:

catch (IWSOAPException iwex)
{
System.err.println(iwex);
((PortletContext)application).getLog().error(iwex.getMessage());
}

and the following is printed to stderr:

com.interwoven.portals.sdk.IWSOAPException: OpenAPI method "IWTask::getSubjectTaskCollection" failed due to Sciface call "TWFClientTask::IsValid": Sciface error #920 (Object being looked up was not found)

Without access to the source code for the getModifiedFiles method that is throwing the exception, I'm unable to further debug this issue.

This exception is thrown for only one of the many users registered on our system.

This exception is thrown for this single user only when the user does have modified files in TeamSite. If the user has no modified files, the exception is not thrown.

Does anyone know what this exception means?

Find more posts tagged with

Comments

sajiddc

sleepyd,

the error :
>>com.interwoven.portals.sdk.IWSOAPException: OpenAPI method "IWTask::getSubjectTaskCollection" failed due to Sciface call "TWFClientTask::IsValid": Sciface error #920 (Object being looked up was not found)

means that the certain task for that user does not exists . Would it be possible for you to share some background info on your workflow with us?

sleepyd

hi sajiddc,

thanks for the reply.

the thing is, this scenario has nothing to do with workflows or tasks - it's the getModifiedFiles method that is yielding this exception. it's meant to return the output of a List Modified command, filtered for files modified by the current user.

interesting new development:
now, for a different user, the same method produces another IWSOAPException, only with a different error message:

com.interwoven.portals.sdk.IWSOAPException: TeamSite Templating Configuration Error

sajiddc

sleepyd,

Does this post

http://devnet.interwoven.com/forums/cgi-bin/showflat.pl?Cat=&Board=PRODUCTS_OPENAPI&Number=13724&page=0&view=collapsed&sb=5&o=21&part=

answer your question?
Navneets po

sajiddc

Test post. Testing to see if the "email all replies to my real email address" works

Migrateduser

Hi,
So few questions first--
1) Does it happen always for this user (when there are modified files) ? or only sometimes ?
2) Who had created the task and attached the files ?
3) Who all (users ) had access to the task.

GetModifedFiles() is a smart call. It does two things. First it gets all the modified files in a workarea, then it removes those files which are already attached to an existing task.

To me it looks like a race condition thing. What could be happening is that because some other user transitioned the same task when this user made the call to getModified, so the task goes away and boom....

There is another way to check all this using good old clts.
1) call 'iw-home'/bin/iwlistmod to get the list of modified files
2) then call iwgetfilejobs to find all the jobs on each file
3) then call iwgetwfobj on each task id.

This way you can create the full picture of what could be happening.

sleepyd

Hi sendkapil,

Thanks for the reply. It was a huge help to me.

I was getting this exception only for certain users, and only when certain files had been modified. I took your advice and used CLTs to retrace the activities of the GetModifiedFiles method, and I've discovered that the problem files all have something in common: running iwgetfilejobs on these "problem files" returns workflow/task IDs that are not valid. (A subsequent call to iwgetwfobj confirms this.)

So now I understand why the exception is being thrown.

I just have to figure out why iwgetfilejobs thinks that these files are attached to non-existent jobs.

Any ideas on that?

Your help is very much appreciated - IW Support has not even responded to the case I submitted two weeks ago!

XMLConfirmation55.dcpackage.zip

output.pdf

Migrateduser

Since I have access to the source code, I could figure it out. OUr support is great, but in this case it was tough to figure out the problem without the code.
---
iwgetfilejobs thinks that these files are attached to non-existent jobs ::: For this problem I'll have to ask someone in the workflow team. Try posting it there, at the same time I'll forward this mail to workflow team also.
--

sleepyd

Thanks for the suggestion. I've created a new post in the Workflows forum.

I've also received a response from a TSE who's working my case.