ALUI / WebCenter Interaction: Introduction to Native API development (Part 1)

Most of the time, creating a remote portlet application using the standard IDK is enough. Indeed, commonly, you just need to access user profile information, portlet ID, page ID etc... or perform simple operations exposed by the IDK PRC API.

But if you hit the limits of the IDK, it is not the end of the road. In the ALUI/Webcenter development documentation, they explain how to perform various UI customizations such as view replacement, PEI development, Activity Spaces creation or extensions, etc... All these are created within the portal application itself...Another option is to create what I call a "Native API Portlet Application". As its name indicates, this portlet application accesses directly the portal API and can perform virtually any operation that the portal can do...very powerful (but non supported :) so make sure your application is well written so that you can change the portal API access layer easily if you upgrade the portal version for example)

First, the 2 main requirements in order to create a Native API application are:

• The application needs to be on the same server as Portal, or Automation, or API service
• The application needs to reference various portal DLLs (located in /ptportal/6.1/bin/assemblies for dotnet, or /ptportal/6.1/lib/java for java). You don’t need them all. Here is the minimum list:
  
  
  
  ptportal\6.1MP1\bin\assemblies\opencache.dll
  
  ptportal\6.1MP1\bin\assemblies\openconfig.dll
  
  ptportal\6.1MP1\bin\assemblies\opencounters.dll
  
  ptportal\6.1MP1\bin\assemblies\openfoundation.dll
  
  ptportal\6.1MP1\bin\assemblies\openhttp.dll
  
  ptportal\6.1MP1\bin\assemblies\openkernel.dll
  
  ptportal\6.1MP1\bin\assemblies\openkernelsearch.dll
  
  ptportal\6.1MP1\bin\assemblies\openkernelsearchimpl.dll
  
  ptportal\6.1MP1\bin\assemblies\openlog-framework.dll
  
  ptportal\6.1MP1\bin\assemblies\openprocman.dll
  
  ptportal\6.1MP1\bin\assemblies\opensharedcache.dll
  
  ptportal\6.1MP1\bin\assemblies\opentempfile.dll
  
  ptportal\6.1MP1\bin\assemblies\openusage.dll
  
  ptportal\6.1MP1\bin\assemblies\openusage-api.dll
  
  ptportal\6.1MP1\bin\assemblies\openusage-impl.dll
  
  ptportal\6.1MP1\bin\assemblies\plumtreeserver.dll
  
  ptportal\6.1MP1\bin\assemblies\portal.dll
  
  ptportal\6.1MP1\bin\assemblies\pthome.dll
  
  ptportal\6.1MP1\bin\assemblies\ptportalobjects.dll

Important note: It is perfectly allowed to also include the IDK Dlls here too... and I find it particularly recommended if you are writing a native API portlet (for instance getting the current login token for example is fairly easy using the IDK API)

Second, you need to create the native session (everything starts from here, really):

1: String strServerConfigDir = ConfigPathResolver.GetOpenConfigPath(); 

2: IOKContext configContext = OKConfigFactory.createInstance(strServerConfigDir,"portal");

3: PortalObjectsFactory.Init(configContext);

4: IPTSession ptsession = PortalObjectsFactory.CreateSession();

From there you actually need to connect this session with a particular user identity. That way, the session object will be aware of your identity and especially the security and permission associated with your identity. In other words, even if you are using the native API, you cannot do more than you are allowed to.

To connect, 2 main options:

• Use the login token that you can simply get from the IDK API (that is prefered option if you can)

1: String loginToken = m_portletRequest.GetLoginToken(); //IDK call

2: ptsession.Reconnect(loginToken);

• Use explicit Username (or user ID) / Password to connect.
  

1: String username = "myusername";

2: String pwd = "mypassword";

3: ptsession.Connect(username, pwd, null);

Third (and Final), you access the right ObjectManager Class depending on which type of portal object you want to interact with.

When the session is created (that was pretty easy, right?), that is when you can actually start interacting with the portal internals...and a majority of actions goes through the PTObjectManager objects (IPTObjectManager interface). For instance:

1: IPTCommunityManager ptCommManager = ptSession.GetCommunities(); //for community objects

2: IPTPageManager ptPageManager = ptSession.GetPages(); //for community page objects

3: IPTObjectManager ptGadgetManager = ptSession.GetGadgets(); //for portlet objects

4: //etc...

You noticed that for portlets, there is not a IPTGadgetManager insterface....that’s ok as all the "Manager" interfaces are children of the base IPTObjectManager interface.

Although the vast majority of manager objects are accessible through a direct ptsession.Get() call, you can also get the right manager using the generic call below (using the classID of the object type you want)

1: IPTObjectManager ptCrawlerManager = ptSession.GetObjectManagers(PT_CLASSIDS.PT_CRAWLER_ID); 

2: //using     the class id of the object type you want

From there, the freedom is yours... and various operations will be available depending on the manager you called. One call for instance that all managers have is the open object:

1: ptObjectManager.Open(objectid, lockObject);

With this call, you get directly access a particular object in the portal, and interact with it as if you were in the UI

In the next article, I will show you how I package these API call in a standalone library to minimize as much as possible any API call within the presentation layer code...