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

TeamPortal 2.0 and 3.0

bturns

Hello, I'm interested in finding out more about TeamPortal 2.0 and 3.0

We are currently running TS 6.5 sp3 on Solaris 8

Has anyone used either of these products. How easily do they integrate with IBM's personalization server, LDAP and security model.

Can TeamPortal 3.0 be used apart from LiveSite 3.0?
Does TeamPortal 3.0 offer a content display portlet? What does the architecture look like?

Find more posts tagged with

Comments

smenon

TeamPortal 2.0 will work only with TS 6.5 SP2 and SP3, and TeamPortal 3.0 which just shipped a couple of weeks ago will work with only TS 6.7.1.

TeamPortal primarily consists on a set of portlets that expose TeamSite (ContentCenter Std) functionality from within the portal - such as MyTasks, My Work-in-Progress, Adding/Editing content etc. In TeamPortal 3.0, we also shipped a content delivery portlet that will be able to serve/render SitePublisher/LiveSite pages in the portal. Create/Manage the microsite (and its pages) in TeamSite using SitePublisher and then deploy the microsite to the portal server (to a sites folder in the app-root) and use this new portlet to render the entire microsite including the resolution of links within the pages. This however, will not leverage portal security OOTB on the links within the pages or for the pages themselves. We do leverage the Portal User Profile for simple user management functions although because of the OS user requirement for TeamSite, currently, we only support pseudo single-sign on to map the portal user to the TeamSite user. For the content delivery portlet that serves up SitePublisher pages, you do not need a LiveSite runtime server in addition to the portlet.

When TS 6.7.1 SP1 ships and we have support for non-OS users and better SSO over SOAP, then we will be able to leverage those services to provide true SSO between the portlets and TeamSite and complete the round-trip content management use case from the portal. We can support that use-case today, but with the current SSO capabilities and using the OS user requirement.

I hope this clarifies things..

thanks

bturns

Is TeamPortal 3.0 available? I can't find it on the support site for download.

Also, will the content rendering portion of TeamPortal 3.0 only be available with Livesite/SitePublisher. Or will you be able to configure it for use with some other datasource?

Thanks,

BT

LooseCannon

When will your engineers get serious about integrating TeamSite authored content with IBM Portal?

Our shop has leveraged TeamSite and OD over the past several years for an ECM solution. TeamSite is the best of the best when it comes to managing Web content and we’ve been very pleased with the product.

Although, like many corporations we brought in IBM Portal technology (that comes with a integrated WCM product) and were faced with a dilemma: we now have two WCM products, so which one do we use?

After completing a comparative analysis it become apparent that TeamSite was far superior to WWCM (IBM’s WCM product). Even though TeamSite is more feature rich, our strategic direction is to use WWCM over TeamSite for an ECM solution.

How come? It’s simple - Lack of Portal integration.

Sunil, are there any plans to providing a means (Open Deploy adapter perhaps) to deploy TeamSite content to the IBM Portal JCR? This is the ONLY way to truly integrate TeamSite and Portal.

I patently await your reply. Thanks.

smenon

When you talk about portal integration - there are 2-3 aspects to it.

1) Moving content into the portal repository
2) Making content available to the portal apps via a virtual content repository
3) Exposing content management functions to portal users

For (1), you can absolutely use OD as a means of moving content into the portal repository. We have been waiting for IBM to convert its portal repository into a native JCR and once that is available, the plan was to build an OD adapter that can deploy to a JCR.

For (2), we have a solution today with the TeamPortal module. With TeamPortal 3.0, we have implemented a VCR using IBM's IICE. A TS workflow can upon approval move the content from TS to a file-system location on the portal server and that file-system location can act as a virtual repository to the portal. We have implemented the virtual repository using IICE and this virtual repository can be registered with the portal and the content that is deposited here is available for consumption by the portal apps.

For (3), this is also available via the TeamPortal 3 module and we have 6 different JSR-168 compliant portlets that expose a number of TeamSite functions to the portal user.

Portal integration is an important area for us and if you look at all the investments we have made with TeamPortal 3.0 or the next generation of OD adapters, I hope you can see that. Obviously we will continue to invest here and if you have other suggestions or ideas for improving upon our current integrations, please do send them to me.

thanks

bturns

Thanks Sunil!

We are going to be implementing #3 and we are looking forward to #1.

Just curious. Have you seen anyone implement #1 on another JCR (Apache's Jackrabbit for example)?

bturns

Also, it seems like my original post was overlooked. I'll post it again for discussion.

Is TeamPortal 3.0 available? I can't find it on the support site for download.

Also, will the content rendering portion of TeamPortal 3.0 only be available with Livesite/SitePublisher. Or will you be able to configure it for use with some other datasource?

Thanks,

BT

smenon

TeamPortal 3.0 is available.. Not sure why you are not seeing it on the Support Site. I presume that you are licensed to use it - right?

the only content delivery portlet is the LS/SitePublisher page rendering portlet. Can you elaborate on what you mean when you ask about configuring it for any other data source?

LooseCannon

Thanks for the reply, Sunil.

Our interest regarding integration lies on the consumption side, so item three is of little interest.

It was my understanding that Portal 6 was fully JSR 170 compliant, so I’ll follow-up with our IBM lab advocate.

I do have a question about the second solution, what’s different about it and say a process that deploys content (as XML) from TeamSite to a HTTP server, where it’s then rendered via a content portlet?

This seems about as useful as making an application available on a portal page with an iframe portlet. There’s no integration just exposure…

Thanks for your time.

smenon

The big difference is with the VCR approach, we are exposing TeamSite asset properties such file attributes, EAs etc. You can then use this information in your portlet to provide content management hooks if you so desire..

Of course, if all you care about is the rendering of the content and don't need any of the asset properties, then you could deploy the content to an HTTP server and either using an iFrame or deploy as RSS compliant XML to the HTTP server and use RSS as a means of pulling content into the portal repository.

LooseCannon

Simply rendering the content on a portal page is NOT desired, but even exposing the EAs, which can easily be achieved by embedding them in the content XML record or managing in a DB, does not achieve integration on the consumption side.

Just curios, are you having any conversations with large corporations on what's needed to integrate TeamSite authored content with IBM portal? It looks like all the focus is on the authoring side not consumption...

Something is still unclear and maybe you can help. The JSR 170 has been released and is now an industry standard for storing Web content, right? Which means that IBM will use the same standard, so even if IBM is not yet fully compliant, which I'm not sure is an accurate statement, why not go ahead and build the adapter? I mean, the adapter should be built to the JSR 170 spec, which is available, so what are you waiting for?

It just makes sense to be proactive and get the thing built and tested, ready for GA.

Thanks.

smenon

To your point about whether we have conversations with large customers about publishing to IBM portal - Yes, we are and which is why you are seeing the IICE VCR implementation or the SPI implementation for BEA.

About why we haven't built a JSR-170 adapter yet - it is purely based on customer demand. While I agree that it is good to be pro-active and build it before the market is ready, we are also need to look at how to prioritize that request against other more pressing needs from our customer base. If we had unlimited resources to build all the requests we get, it would have been done by now Smiley Happy

It is something we are tracking and don't want to minimize it's importance, but I hope you understand that in the order of things we have to do, we are focusing on items that have a larger demand from our customers first before getting to this one. We have a workable solution today and will continue to extend it and enhance it in the coming releases.

I also want to distinguish between IBM's support for JSR-170 in the context of accessing a JCR vs making their own repository a JCR. My information might be a little out-of-date, but when I last checked, their portal repository wasn't yet a native JCR. The plan was to make it a JCR with Websphere Portal 6.1. However, they do support accessing content from a JCR (external repository) in their portal apps.

Please let me know if you want to discuss in more detail about how we integrate today or provide feedback or suggestions.. Send me an email at smenon@interwoven.com

thanks

LooseCannon

I really appreciate you taking the time to discuss this topic. I'll continue the conversation via e-mail.