Discussions
Categories
Groups
Community Home
Categories
INTERNAL ENABLEMENT
POPULAR
THRUST SERVICES & TOOLS
CLOUD EDITIONS
Quick Links
MY LINKS
HELPFUL TIPS
Back to website
Home
Content Management (Extended ECM)
API, SDK, REST and Web Services
Getting *very* frustrated with LAPI
Robert_Davies_(unlondonadmin_-_(deleted))
Hi.I'm really getting frustrated with LAPI/Java.Is there *any* diagnostic information available to tell you why a call might not be working? The status value returned from many of these calls isn't explained anywhere I can find (You tell me what -21474842645 means!)The actual cause of my error (this time) was that I was passing the wrong value for the 'database' field in the session variable. Would it have been so hard to indicate this somewhere?I really don't appreciate being forced to trawl through thread.out files trying to find out why an API call is failing!Matt/
Find more posts tagged with
Comments
NetSys_(Delete)_271892
If you are tired of the thread.out files you should get your hands on the builder. It will display the thread.out files in the debug-window.
Robert_Davies_(unlondonadmin_-_(deleted))
Thanks for the suggestion but I don't find the builder debug window any more convenient than the log files.In any case this isn't a solution. Providing a diabolical log file is no substitute for good error handling and debugging facilities. These are things that Livelink in general (and LAPI in particular) seem very weak on.If LAPI is to become a usable API - and I contend that at the moment it is not, at least the Java API is not - then I think there are foundations that have to be built of which solid error handling is one. (complete architectural redesign, and rigourous complete documentation are others that come to mind).Would anyone from OTC care to comment?Best regards/matt.
NetSys_(Delete)_271892
Hmmm...despite my former answer I think I agree with this. Much of the debugging in LL is very hard to do. One of the things that is most irritating is that it is so very hard to get an overview over what functions are called by what functions during the debugging. And as you say, missing documentation is an issue too.
Mike_Oliver_(ollie_(Delete)_137504)
It is one thing to complain because something isn't what you want or need, it is something else to provide a suggestion as to how to improve it. Saying, "start over" or "redesign" is not helpfull, it only says you are unhappy. Simone Oettinger is the Product Manager, I am sure she will welcome any constructive input. What we need is input that is precise and constructive. Certainly, we all want better documentation on what is there and guides to show how to use what is there and we ARE working on just that. But if a function is missing that you feel we need, then tell us EXACTLY what you want. You give the example of not knowing what the error code is, well you can echo( errorcode ) and in most cases you will see the text associated with the error code in the debug log. Perhaps a function construct like OnErrorGoSub($MyErrorHandler) which would be a basic function would help. If you want to do more than just complain, and if you want to help us, we need to know what you want in more precise terms, so we can build it.
Mike_Oliver_(ollie_(Delete)_137504)
It is one thing to complain because something isn't what you want or need, it is something else to provide a suggestion as to how to improve it. Saying, "start over" or "redesign" is not helpfull, it only says you are unhappy. Simone Oettinger is the Product Manager, I am sure she will welcome any constructive input. What we need is input that is precise and constructive. Certainly, we all want better documentation on what is there and guides to show how to use what is there and we ARE working on just that. But if a function is missing that you feel we need, then tell us EXACTLY what you want. You give the example of not knowing what the error code is, well you can echo( errorcode ) and in most cases you will see the text associated with the error code in the debug log. Perhaps a function construct like OnErrorGoSub($MyErrorHandler) which would be a basic function would help. If you want to do more than just complain, and if you want to help us, we need to know what you want in more precise terms, so we can build it.
Mike_Oliver_(ollie_(Delete)_137504)
AKA OOPS Don't double click on the Submit button (not always easy on a touch pad)
Michael_Oliver_(MorningstarAdmin_(Delete)_1424285)
I use a function called LL_SessionStatus that returns the text of an error message. I looked in the lapi docs and they make mention of a function called LL_GetLastStatus. I don't see this function in my VB includes. However, there is this define in the c lapi.h header:#define LL_GetLastStatus LL_SessionStatusAnd yes, there is a VB declaration:Declare Function LL_SessionStatus Lib "llkernel.dll" (ByVal session As Long, ByRef status As Long, ByVal message As Long) As LongAnyway, I've used this function in my error trapping/logging:Public Sub LLerror(ByVal errorno As Long)Dim errstat As LongDim siz As LongDim buf As String * 256Dim errval As LongDim tmp1 As Longstatus = LL_ValueAlloc(tmp1)errstat = LL_SessionStatus(session, errorno, tmp1)If (errstat = LL_OK) Then errstat = LL_ValueGetString(tmp1, buf, 256, siz) MsgBox "(Session#: " & CStr(session) & "] Livelink Error [" & CStr(errorno) & "]" & vbCrLf & buf Out2Err ("(Session#: " & CStr(session) & "] Livelink Error [" & CStr(errorno) & "] :" & buf)End Ifstatus = LL_ValueFree(tmp1)End SubHope this helps a little,Darryn GrahamMorningstar Systems, Inc.(410) 902-7633 ext 15dgraham@mstarsys.com
Sury_Balasubramanian_(primav027_-_(deleted))
I have had to pick up LAPI in order to do a dynamic data integration between Documentum and LiveLink [updates in that one-way direction only]. We are doing this for a LiveLink client for one of their clients.The integration is based on the LL 9.0.0.1 server.I must agree with some of the points expressed three years ago. Minimally, I would like to see 1) a comprehensive API documentation that lists all functions as well as a all functions categorized by type. And richly cross-referenced.2) code samples for doing baseline things.3) improved error messaging that can speak to the failure: e.g., the "get(name) not supported for this type" could be more descriptive.4) higher abstraction levels in the API for document management functionality. The mechanism of generic LLValue objects is cool at a very, very low level. However, once you are trying to do anything of weight, you end up immediately writing higher level classes to hide the enormous amount of work that must be done to do simple things.Hope this helps...ryck.birch@trinitytechnologies.com
eLink User
Message from chris meyer <<A HREF="mailto:cmeyer@opentext.com">cmeyer@opentext.com> via eLink
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
Agreed, and it has been done with Java. Have a look here:
https://knowledge.opentext.com/knowledge/livelink.exe?func=ll&objId=2734728&objAction=browse
cheers, chris
> 4) higher abstraction levels in the API for document management functionality. The mechanism of generic LLValue objects is cool at a very, very low level. However, once you are trying to do anything of weight, you end up immediately writing higher level classes to hide the enormous amount of work that must be done to do simple things.
