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; } } }

Multilingual Metadata

Paulo_Preto

Is it possible to set an object's Multilingual metadata via the LAPI ?

In my case, I want to set the French Name field of a Folder, in Content Server 10.

Find more posts tagged with

Comments

Kyle_Swidrovich

Hi Paulo,

No, it’s not possible.

As noted in the CS 10 SDK release notes, LAPI 9.7.1 is the last available version of LAPI, which has no support for any CS 10-specific features.

If you wish to manipulate multilingual metadata, you will need to use the Content Web Services API which is a core component of Content Server.

Cheers,

Kyle

Paulo_Preto

Thanks for the confirmation, Kyle.

Chris Meyer

Quoted Paulo Preto on 2013-01-24 07:40:

Is it possible to set an object's Multilingual metadata via the LAPI ?

It's possible to use LAPI to set the multilingual names on a node. Normally you'd use the UpdateObjectInfo function and set the "Name" key to a string. However, you can also pass in a dictionary with key-value pairs of the language code and the language specific value. For example:

LLValue names = new LLValue().setAssoc();
names.add("fr", "Value in French");
names.add("en_US", "Value in US English");

objectInfo.add("name", names)

// call UpdateObjectInfo with objectInfo

I don't think a similar workaround exists for other multilingual attribute types. However, since WebServices is actually a LAPI call in disguise, you might be able to hack together a workaround to call the WebServices code via LAPI. Attached is the com.opentext.api.LAPI_APISERVICE stub that you can use to invoke WebServices from LAPI.

LAPI_APISERVICE.java

Kyle_Swidrovich

Hi Chris,

CS 10 Web Services is not a LAPI call in disguise. 9.7.1 Web Services used to use LAPI binaries to issue a call into Content Server, however, 10 no longer does so.

Although it uses an APIHandler for unmarshalling an inbound request, it should not be treated as a “LAPI” call.

Please keep in mind that LAPI 9.7.1 is and continues to be the last release of LAPI.

At some point in the future, when appropriate, LAPI support from the Content Server side will cease to be.

Any new development should not rely on LAPI.

Best regards,

Kyle

Chris Meyer

Hi Kyle,

Perhaps my choice of words isn't right, but most WebServices methods can be called as if it were a LAPI function. I've used this workaround on occasions when the target system didn't have WebServices configured (i.e., no servlet engine). It's sometimes easier to implement a hack than ask an administrator to add a new piece of software to their system (which also has to be configured and maintained). I hope OpenText considers this in the future and makes WebServices visible without requiring a servlet engine.

Thanks for the reply.

Kyle_Swidrovich

Hi Chris,

To clarify, you are making LAPI calls to InvokeService directly?

Again, LAPI is going away so any solution you have written in this fashion will be relatively short-lived.

When you say that you hope we “make WebServices visible without requiring a servlet engine” what are you envisioning?

A web service is a service deployed on the web server, so you need to have something to execute that service, hence the servlet and/or IIS .NET infrastructure.

The nature of web services, even outside the context of Content Server, requires the deployment of a web service within the web environment.

Perhaps what you are suggesting is you would like to be able to issue requests to Content Server, maybe not necessarily called “WebServices” per se, but some API, that does not require a middleman application?

Are you suggesting a RESTful API?

Thanks,

Kyle

Chris Meyer

Hi Kyle,

Quoted Kyle Swidrovich on 2013-01-25 04:29:

To clarify, you are making LAPI calls to InvokeService directly?

Not on a regular basis or anything, but I've done this for short-term workarounds.

Quoted Kyle Swidrovich on 2013-01-25 04:29:

When you say that you hope we “make WebServices visible without requiring a servlet engine” what are you envisioning?

A web service is a service deployed on the web server, so you need to have something to execute that service, hence the servlet and/or IIS .NET infrastructure.

The nature of web services, even outside the context of Content Server, requires the deployment of a web service within the web environment.

Are you suggesting a RESTful API?

Exactly. I'm not looking to change how WebServices work, so I agree that a servlet engine remains in place for that purpose. However, many of the methods would form a great basis for a RESTful-style (doesn't have to be REST per se) API for accessing these functions. The usefulness of this can't be understated: Often when developing a customization or even just a customview you want to access some content via AJAX. Leveraging these functions would open a lot of possibilities, but also follow the DRY-principle. I've written a few LAPI wrappers in the past to allow calling from a URL (I think it was once installed on KC, but I can't recall the syntax anymore), but a supported solution would be really great.

Thanks!

Ossie_Moore

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">

Chris,

Just to clarify, Web Services do not absolutely require a servlet container for those servers running on Windows. The servlet container is required for the Java hosted implementation of Web Services, however both .NET and Java hosted implementations are provided. If you elect to enable the .NET version of the Web Services, you don't need a servlet engine. From the client perspective, it doesn't matter which one is enabled because clients from any language that supports Web Services should be able to consume them. For example, I regularly develop Java client side code that connects to the .NET hosted implementation of the Web Services on a regular basis.

I do agree a RESTful API would not be attractive, but the current Web Service implementation meets your stated desire to be able to enable Web Services without having to install and configure a servlet container.

Ossie.

From: eLink Entry: LAPI Forum [mailto:lapi@elinkkc.opentext.com]
Sent: Thursday, January 24, 2013 9:53 PM
To: eLink Recipient
Subject: [EXTERNAL]RE RE Multilingual Metadata

RE RE Multilingual Metadata

Posted by chris.meyer@kwe.li (Meyer, Chris) On 01-24-2013 22:29

Hi Kyle, Quoted Kyle Swidrovich on 2013-01-25 04:29: To clarify, you are making LAPI calls to InvokeService directly? Not on a regular basis or anything, but I've done this for short-term workarounds. Quoted Kyle Swidrovich on 2013-01-25 04:29: When you say that you hope we “make WebServices visible without requiring a servlet engine” what are you envisioning? A web service is a service deployed on the web server, so you need to have something to execute that service, hence the servlet and/or IIS .NET infrastructure. The nature of web services, even outside the context of Content Server, requires the deployment of a web service within the web environment. Perhaps what you are sugg! esting i s you would like to be able to issue requests to Content Server, maybe not necessarily called “WebServices” per se, but some API, that does not require a middleman application? Are you suggesting a RESTful API? Exactly. I'm not looking to change how WebServices work, so I agree that a servlet engine remains in place for that purpose. However, many of the methods would form a great basis for a RESTful-style (doesn't have to be REST per se) API for accessing these functions. The usefulness of this can't be understated: Often when developing a customization or even just a customview you want to access some content via AJAX. Leveraging these functions would open a lot of possibilities, but also follow the DRY-principle. I've written a few LAPI wrappers in the past to allow calling from a URL (I think it was once installed on KC, but I can't recall the syntax an! ymore), but a suppo rted solution would be really great. Thanks!

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

Ossie_Moore

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">

"I do agree a RESTful API would not be attractive" should have read "I do agree a RESTful API would be attractive"

From: eLink Entry: LAPI Forum [mailto:lapi@elinkkc.opentext.com]
Sent: Friday, January 25, 2013 8:53 AM
To: eLink Recipient
Subject: [EXTERNAL]RE RE RE Multilingual Metadata

RE RE RE Multilingual Metadata

Posted by ossie.moore@contractor.p66.com (Moore, Ossie) On 01-25-2013 09:52

Chris, Just to clarify, Web Services do not absolutely require a servlet container for those servers running on Windows. The servlet container is required for the Java hosted implementation of Web Services, however both .NET and Java hosted implementations are provided. If you elect to enable the .NET version of the Web Services, you don't need a servlet engine. From the client perspective, it doesn't matter which one is enabled because clients from any language that supports Web Services should be able to consume them. For example, I regularly develop Java client side code that connects to the .NET hosted implementation of the Web Services on a regular basis. I do agree a RESTful API would not be attractive, but the current Web Service implementation meets your stated desire to be able to enable Web Services without having to install and configure a servlet container. Ossie.
From: eLink Entry: LAPI Forum [mailto:lapi@elinkkc.opentext.com]
Sent: Thursday, January 24, 2013 9:53 PM
To: eLink Recipient
Subject: [EXTERNAL]RE RE Multilingual Metadata

RE RE Multilingual Metadata

Posted by chris.meyer@kwe.li (Meyer, Chris) On 01-24-2013 22:29

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

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

Chris Meyer

Quoted Ossie Moore on 2013-01-28 19:08:

Interesting. I didn't know that was possible. Is there a simple way to enable the WebServices server with .NET? thanks

Kyle_Swidrovich

Hi Chris,

You don’t need to do anything special to get it going under IIS as it’s hosted as a .NET application.

I believe Jason Smith has posted a getting started guide in the Sample area of this community.

Kyle

Ossie_Moore

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">

The documentation in [livelink_install_dir]\webservices\sdk\docs\index.html will also get you started. I have found the installation instructions lacking a bit as you may find that you have to do a bit more coaxing of IIS to get them running successfully. I have seen the getting started guide before and it does help too. Just be prepared to tweak IIS or your web.config a bit if things don't "just work".

For example, one particular thing we had an issue with was load balancing. We have multiple host names configured in IIS to support the load balancer used. Limitations in the version of WCF used by (at least 9.7.1) Enterprise Web Services mean that only one hostname can be used when accessing them. Further, if you have multiple hostnames configured for your IIS website, you need to specify which hostname will be used in the web.config file. I attached a snippet of my development machine's web.config that has the section we had to add and was not in the instructions. The instructions assume the website is a traditional one hostname per website configuration.

Ossie

From: eLink Entry: LAPI Forum [mailto:lapi@elinkkc.opentext.com]
Sent: Monday, January 28, 2013 12:31 PM
To: eLink Recipient
Subject: [EXTERNAL]RE RE RE RE Multilingual Metadata

RE RE RE RE Multilingual Metadata

Posted by kswidrov@opentext.com (Swidrovich, Kyle) On 01-28-2013 13:30

Hi Chris, You don’t need to do anything special to get it going under IIS as it’s hosted as a .NET application. I believe Jason Smith has posted a getting started guide in the Sample area of this community. Kyle

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

webconfig.txt

Chris_Morley

Here's the truth about LAPI.

Open Text has been saying that 9.7.1 was the last release since 9.7.1 came out, I believe in 2006. Clearly, they are not in any particular hurry to retire it, however it poses some risks for them so the party line has to be that we're all on our own.

Those risks include the fact that the .Net version is built on top of J#, which Microsoft has backed away from (not supported by a CLR > 3.5.1) and which, if any of you has tried to install recently has some serious GAC problems.

If J# won't work, Open Text can't do anything about it; meaning they can't support anything you do with LAPI while that risk is out there. That's why there is no 64 bit version and why no new Content Server features are being added... Those DLLs are staying as-is and anything we can get them to do properly is a bonus.

On the other side, Open Text is also between a rock and a hard place because they still have some modules that depend on .Net LAPI (AGA/SharePoint Web Parts for one) and by their own admission the support for Categories and Attributes is not neary as robust in the current Web Services offering.

So, my advice: If you can do what you need to do using EWS (or whatever they call it now), use EWS. If you can't or have other code that already works with LAPI; don't panic quite yet... do what you have to do. Just remember, your .Net LAPI solutions will be 32 bit and must be targeted for .Net versions lower than 4.0. Content Server can be 64 bit; it's the LAPI client you build that will have to be 32.