Document upload problem with Service Pack 2 Update 2015-12

Hello,

I have problem with document upload WebService with Service Pack 2 Update 2015-12.

There is a error message in webservice log file:

OpenText.ContentServer.API.LLIOException: ContentService.UploadContent() failed on the Livelink Server. No results were returned. Check the Livelink Server thread logs.

at OpenText.Livelink.Service.LAPI_SERVICE.InvokeService(String serviceName, String serviceMethod, LLValue args, LLValue env, LLFileInfo fileInfo, LLValue result)

at OpenText.Livelink.Service.Core.ContentService.UploadContent(String contextID, FileAtts fileAtts, Stream inStream)

All other webservices work fine like Authentication, Search etc.

The same webservice workes fine with update 13.

Has anybody seen such problem and found workaround?

Thanks,

keit

Find more posts tagged with

Comments

Keit Kivisild

Current problem occures on CS running on windows, les services deployed on IIS, client written in Java.

If to deploy les services on same machine in tomcat there is no problem and application works fine.

Additionally, if to replace CS bin folder with previous version of CS bin folder files (update 2015-09) the uopload service works as expected. It means the same clinet application is able to upload document.

Any ideas?

Regards,

keit

Rune_Kristiansen

Hi,

I will just share my own issues after applying update2015-12. I have now problems with both AddVersion and UpdateNode. The both yield the same error message "DocumentManagement.AddVersion() failed on the Livelink Server. No results were returned. Check the Livelink Server thread logs."

After checking all logs, with debug=2 and also trace level=4 in web.config, I find nothing about the error. The only occurence is in the cws log, which just gives me the same error as I get from c#.

I tried to "hack" my way through by copying back the services_10_5_0 module from previous CS along with my previous cws directory, didnt work.

I hope someone has any ideas.

Cheers,

Rune

eLink User

If the error was happening at the Livelink server then the proper way to capture that would be

debug=2

wantlogs=true

wantlapilogs=true

The above goes into the opentext.ini of the livelink server who is responsible for the CWS command.

Your CWS host talks to a livelink server if you see web.config saying localhost/2099 or whatever the server/port is when a CWS call fails and it is something that the application developers know about it would be there.in some cases your client call could basically turn into a un handled exception in which case a trace* with threadid will show.If a trace and its thread is looked within the same time span it will indicate where in oscript the crash occurred.OT support will be quick to help you with that.

.....appu appnair appunair

Well, if I called the wrongnumber, why did you answer the phone?
James Thurber, New Yorker cartoon caption, June 5, 1937

On Mon, Feb 15, 2016 at 12:50 PM, eLink Entry: Content Web Services Forum <otdncontentwebservices971forum@elinkkc.opentext.com> wrote:

Document upload problem with Service Pack 2 Update 2015-12 Posted byKristiansen, RuneOn 02/15/2016 01:47 PM

Hi,I will just share my own issues after applying update2015-12. I have now problems with both AddVersion and UpdateNode. The both yield the same error message "DocumentManagement.AddVersion() failed on the Livelink Server. No results were returned. Check the Livelink Server thread logs."After checking all logs, with debug=2 and also trace level=4 in web.config, I find nothing about the error. The only occurence is in the cws log, which just gives me the same error as I get from c#.I tried to "hack" my way through by copying back the services_10_5_0 module from previous CS along with my previous cws directory, didnt work.I hope someone has any ideas.Cheers,Rune
[To post a comment, use the normal reply function]
Topic: Document upload problem with Service Pack 2 Update 2015-12
Forum: Content Web Services Forum
Content Server: Knowledge Center

Rune_Kristiansen

Hi Appu,

Thanks for the hint about wantLapiLogs. I added this and ran my c# code again. I get more information now about each servicemethod, but the strange thing is that the method which is failing for me, currently Addversion, does not display in the logs. I get entries for each of the other methods:

'ServiceMethod'='AuthenticateUser','ServiceName'='Authentication'
'ServiceMethod'='GetCategoryTemplate','ServiceName'='DocumentManagement'
'ServiceMethod'='GetNode','ServiceName'='DocumentManagement'

After this I would suspect to find:
'ServiceMethod'='AddVersion','ServiceName'='DocumentManagement' ?

But the above three is all I can find in all the logfiles. These are listed in threadN.out by the way.

Is that strange, or would it not show because it is failing at an earlier stage? Does this mean that the AddVersion somehow is not implemented or something?

The section in the log I am pointing to for the 'servicemethod's looks like this

02/16/2016 11:36:35 Executing API: #35002577.InvokeService
02/16/2016 11:36:35 inArgs: A<1,?,'Arguments'=A<1,?,'categoryID'=22039116>,'ServiceMethod'='GetCategoryTemplate','ServiceName'='DocumentManagement','_ApiName'='InvokeService','_ClientVersion'='9.7.1','_ConnectionName'='','_Cookie'='NBUKXYUVuUFe0Y7JmZyH7A64PVJBAsIsigzFbO51JX7gPkd3IAwhNBrMie2WEees','_DomainName'='','_ImpersonateUserDomain'='','_LLENVIRON_ASSOC'=A<1,?,'REMOTE_ADDR'='10.1.44.48','REMOTE_USER'='MCD\\runek'>,'_Request'='llweb','_UserName'='','_UserPassword'='XXXXXXXXXX'>
02/16/2016 11:36:35 ------------------------------------------
02/16/2016 11:36:35 _LLENVIRON_ASSOC contains:
02/16/2016 11:36:35 REMOTE_ADDR=10.1.44.48
02/16/2016 11:36:35 REMOTE_USER=MCD\runek
02/16/2016 11:36:35 End _LLENVIRON_ASSOC

Cheers,

Rune

eLink User

If you install Livelink Builder on the LL server that runs the service and put a break point here as shown in the screen cap you would know for sure.

Typically I would have thought the webservices api that you run would run under "anonymous" authentication and in that case one would not see this as in your call

IsigzFbO51JX7gPkd3IAwhNBrMie2WEees','_DomainName'='','_ImpersonateUserDomain'='','_LLENVIRON_ASSOC'=A<1,?,'REMOTE_ADDR'='10.1.44.48','REMOTE_USER'='MCD\\runek'>,'.It could be a red herring but unless SSO is established all the way around by modifying the web.Config from OT and thereby your app.config.Somewheere in OT documentation I have read that file operations

The transport that I have highlighted means expect an anonymous upload.For SSO using IWA it is usually different that is if you do not want to sent a userid/password in code.

<binding name="ContentServiceBinding" maxReceivedMessageSize="2147483647"

messageEncoding="Mtom" transferMode="Streamed">

</security>

</binding>

I know for a fact that when you deploy webservices and if you are not careful IIS will make the application default with "windows authentication" so if the call is not reaching livelink and terminating at the ws proxy layer it may have some effect.Try with the least complicated scenario(ws and llserver on the same host,and all websites/applications anonymous) I would hazard a guess that OT has probably done nothing to the webservices side on that update level ,but you can check the release notes.

Also use Fiddler to debug the SOAP message.

If you send me the snippet of code when I get time I can put it and try to see that unless you re doing something similar to this

https://knowledge.opentext.com/knowledge/llisapi.dll/open/15628099#link9

Anyways I use Kyle's posted method in the KB for most upload code and it uses contenservice and web.config tweaks and works happily ever after.

.....appu appnair appunair

Well, if I called the wrongnumber, why did you answer the phone?
James Thurber, New Yorker cartoon caption, June 5, 1937

On Tue, Feb 16, 2016 at 4:55 AM, eLink Entry: Content Web Services Forum <otdncontentwebservices971forum@elinkkc.opentext.com> wrote:

Re Document upload problem with Service Pack 2 Update 2015-12 Posted byKristiansen, RuneOn 02/16/2016 05:52 AM

Hi Appu,Thanks for the hint about wantLapiLogs. I added this and ran my c# code again. I get more information now about each servicemethod, but the strange thing is that the method which is failing for me, currently Addversion, does not display in the logs. I get entries for each of the other methods:'ServiceMethod'='AuthenticateUser','ServiceName'='Authentication'
'ServiceMethod'='GetCategoryTemplate','ServiceName'='DocumentManagement'
'ServiceMethod'='GetNode','ServiceName'='DocumentManagement'After this I would suspect to find:
'ServiceMethod'='AddVersion','ServiceName'='DocumentManagement' ?But the above three is all I can find in all the logfiles. These are listed in threadN.out by the way.Is that strange, or would it not show because it is failing at an earlier stage? Does this mean that the AddVersion somehow is not implemented or something?The section in the log I am pointing to for the 'servicemethod's looks like this02/16/2016 11:36:35 Executing API: #35002577.InvokeService
02/16/2016 11:36:35 inArgs: A<1,?,'Arguments'=A<1,?,'categoryID'=22039116>,'ServiceMethod'='GetCategoryTemplate','ServiceName'='DocumentManagement','_ApiName'='InvokeService','_ClientVersion'='9.7.1','_ConnectionName'='','_Cookie'='NBUKXYUVuUFe0Y7JmZyH7A64PVJBAsIsigzFbO51JX7gPkd3IAwhNBrMie2WEees','_DomainName'='','_ImpersonateUserDomain'='','_LLENVIRON_ASSOC'=A<1,?,'REMOTE_ADDR'='10.1.44.48','REMOTE_USER'='MCD\\runek'>,'_Request'='llweb','_UserName'='','_UserPassword'='XXXXXXXXXX'>
02/16/2016 11:36:35 ------------------------------------------
02/16/2016 11:36:35 _LLENVIRON_ASSOC contains:
02/16/2016 11:36:35 REMOTE_ADDR=10.1.44.48
02/16/2016 11:36:35 REMOTE_USER=MCD\runek
02/16/2016 11:36:35 End _LLENVIRON_ASSOCCheers,Rune

[To post a comment, use the normal reply function]
Topic: Document upload problem with Service Pack 2 Update 2015-12
Forum: Content Web Services Forum
Content Server: Knowledge Center

image.png

Rune_Kristiansen

Hi,

Thanks for your feedback. We have issued a ticket on this to OT and they say they will make this a priority. They also said that with java webservices, this does not happen. I am not sure if this is mentioned in any posts yet. I ran a test and installed tomcat, deployed war file and tweaked my application to run from tomcat and not IIS. So far, one of the functions (AddVersion) works. I bet the other ones will work also. You did however point out something. I use windows authentication. Our cs server is set up like that, and also cws. It might be worth to try anonymous, maybe the functions works then.

I'll post back when I have tested anonymous cws on iis.

Cheers,

Rune

Kyle_Swidrovich

Thanks Rune.

Yes, we have this issue as a priority (LESAPI-2110 is the reference number).

We haven’t been able to reproduce this issue in house, but we’ve heard a number of customers report this issue, specifically with 2015-12.

We’ll continue to investigate.

Any insight from your end (or any other customer experiencing this similar problem) will be very helpful to us, so please communicate any new findings back through your support ticket.

If anyone is willing to install Wireshark (with a local loopback adapter, if CWS + Content Server are on the same machine), we’re looking to capture the raw packet data between the Web Service itself and the Content Server service (listening on port 2099 by default).

Cheers,

Kyle

Chris Meyer

Hi Rune,

Can you tell me three specifics of your request:

Are you creating a new document or new document version?
If it’s a new document, does it automatically inherit category values?
If yes, do any of these category values have facets based on them?

Thanks
Chris

Kyle_Swidrovich

Hello all,

We've determined root cause. It seems to affect non-English locales with alternate date formats.
The fix is quite simple and we're working towards hotfixing this ASAP.

Thanks for the collaborative effort!

Kyle

Jim Hewitt

The patch for this issue has been posted.

CS10: https://knowledge.opentext.com/knowledge/cs.dll?func=ll&objId=62239633&objAction=properties

CS 10.5: https://knowledge.opentext.com/knowledge/cs.dll?func=ll&objId=62227593&objAction=properties