Download Java API

Timm_Berens

Hello,

I am looking for the download of the LAPI for Java. Somehow I am unable to find a link in the knowledge base.

So, is it possible to download the Java Packages or is it only distributed via the sdk disk?

Regards,

Timm

Find more posts tagged with

Comments

Kyle_Swidrovich

Hi Timm,

LAPI was last released as a part of the 9.7.1 SDK.

As per the download page for the SDK, the 9.7.1 SDK has been classified as restricted for export.

As such, you will need to contact your local OpenText Customer Support office to request the 9.7.1 SDK in order to obtain LAPI.

The official notice on this can be found by expanding the 9.7.1 section here:

https://knowledge.opentext.com/knowledge/cs.dll?func=ll&objId=4042029&objAction=browse&sort=name

Regards,

Kyle

Timm_Berens

Thank You!

Shambaditya_Biswas

From where I can downl;oad Lapi SDK for CS10.03 ..... Actully I have to implement Security Clearence SDK

Appu_Nair

Kyle has posted right above this posting what the procedures to get LAPI 9.7/1 SDK. CS10 will accept lapi client calls but there is no 64 bit supplied by OT after 9.7.1 .9.7 code written in lapi should work against a CS10 instance.

Why use LAPI do you not have the support in webservices the lapi replacement?

Jim_Coursey_(inactive)

A couple of weeks ago someone posted that Web services would not be replacing (all?) of LAPI and that there would still be need for both. Is that true or did I misunderstand?

From: eLink Entry: LAPI Forum [mailto:lapi@elinkkc.opentext.com]
Sent: Wednesday, May 09, 2012 2:30 PM
To: eLink Recipient
Subject: RE Download Java API

RE Download Java API

Posted by anair@alitek.com (Nair, Appu) On 05-09-2012 14:22

Why use LAPI do you not have the support in webservices the lapi replacement?

[To post a comment, use the normal reply function]
Topic:	Download Java API
Forum:	LAPI Forum
Content Server:	Knowledge Center

Appu_Nair

Jim I will try to give a layman explanation as I don't think you program.If I am mistaken please excuse.Also the first thing that people complain about lapi is that they cannot understand its data handling so I was basically advising the user to try the modern stuff.

Everything that you program(almost) in livelink is actually understood by the livelink system as Oscript.LAPI or the API for livelink consists of 2 separate parts.

LAPI client facing code is written in industry standard languages such as C,C++,Java,C# & VB.NET.To get your client code to the livelink server a transport mechanism is also developed.It hits the livelink server proper this is the second part using TCP/IP.You generallu use this method if you want to byspass the gui and do things programmatically.for that you install a lapi program(library) in your programming environment,
LAPI calls are transferred into the Oscript layer.With oscript you can write stuff that is not in the product which we call extending or customization.

Part 2 of the implementation is still part of CS10.OT is deprecating use of LAPI in favor of webservices which one of the obvious advantages is they do not have to support 4 or 5 languages.So Part1 that is the SDK for all those languages stopped after 9.7.1 SDK.Also OT will not invest their resources to fix any bugs in lapi.It goes without saying that newer things happening in livelink may not have a lapi equivalent.(again completely debatable as anybody can write this)

So for existing lapi investments,they will have to write using the 9.7.1 version and hope it works(it should) in CS10.This may continue till such time as OT thinks whether or not they can do away with Part2.

The new webervices also are of the same paradigm.Part1 the transport and client code layer and Part2 Oscript,whether you call it webservices,enterprise library services(SAP integrations use this kind to get stuff into livelink) or whatever anything useful in livelink is still performed by OSCRIPT.

The 64 bit vs 32 bit debut is still acheivable meaning a 32bit lapi app can run in a 64 bit system.In fact some OT products I have had to recompile for 64 bit systems.

For any lapi investments out there it is probably very safe.

Does that answer or give you confidence about lapi

Jim_Coursey_(inactive)

Thanks for the explanation Appu.

From: eLink Entry: LAPI Forum [mailto:lapi@elinkkc.opentext.com]
Sent: Wednesday, May 09, 2012 3:30 PM
To: eLink Recipient
Subject: RE RE Download Java API

RE RE Download Java API

Posted by anair@alitek.com (Nair, Appu) On 05-09-2012 15:26

Everything that you program(almost) in livelink is actually understood by the livelink system as Oscript.LAPI or the API for livelink consists of 2 separate parts.

LAPI client facing code is written in industry standard languages such as C,C++,Java,C# & VB.NET.To get your client code to the livelink server a transport mechanism is also developed.It hits the livelink server proper this is the second part using TCP/IP.You generallu use this method if you want to byspass the gui and do things programmatically.for that you install a lapi program(library) in your programming environment,
LAPI calls are transferred into the Oscript layer.With oscript! you can write stuff that is not in the product which we call extending or customization.

The new webervices also are of the same paradigm.Part1 the transport and client code layer and Part2 Oscript,whether you call it webservices,enterprise library services(SAP inte! grations use this kind to get stuff into livelink) or whatever anything useful in livelink is still performed by OSCRIPT.

The 64 bit vs 32 bit debut is still acheivable meaning a 32bit lapi app can run in a 64 bit system.In fact some OT products I have had to recompile for 64 bit systems.

For any lapi investments out there it is probably very safe.

Does that answer or give you confidence about lapi

[To post a comment, use the normal reply function]
Topic:	Download Java API
Forum:	LAPI Forum
Content Server:	Knowledge Center

Darrin_Tisdale

This direction is all well and good, but functionality gaps remain with the web services that are accessible via LAPI. A few I know off the top of my head:

Creation of non-standard object types such as CAD Documents or any other ones for which there is not already a base SDO in the Document Management service
Access to more esoteric options of categories, for example, setting a category on an object so that it should not be inherited.

Until there is functionality parity, the web services can be used in some but not all circumstances.

If there are pieces of functionality not supported in the web services SDK but still needed, I recommend creating both sides, as it were.

Create a custom module that implements the functionality you need in OScript. There, you can access DAPI, WAPI, CAPI, or any of the other APIs you need, along with the more succinct LLNode encapsulations. You have all the richness there.
Then using the custom module, expose the functionality you want as a service. Publish the service, exposing it to potential clients. Then, your calls from the web service side can be more succinct and business-focused, while the underlying OScript can handle nuances of the CS engine.

. . . Darrin Tisdale