Q1: What version of IBM WebSphere Portal does DPM work with?
Out of the box, DPM will work with IBM Portal 6.1.x family. Our product makes use of custom workflow actions in order to create workflow looping and branching mechanisms.
If you have IBM Portal 6.0, DPM will work with your platform only with the addition of the IBM "custom actions" patch. This patch is only available directly from IBM and adds custom workflow actions to the WCM 6.0 product. With this patch in place DMP becomes fully functioning with Portal 6.0
We also have a version that works with IBM Portal 5.1 but this is not as fully featued as the product that runs on 6.1lx and 6.0lx (+ IBM patch) and does not provide custom workflow actions.
Q2: Does DPM work with a dedicated authoring and publishing environment to allow specific tuning?
Yes, this model is supported. You can trigger an authoring session from the publishing environment. This means that you can log into the publishing environment, see a content item that needs changing and then trigger the editing of that item on the authoring server. The WCM context of the page from the publishing environment is maintained and the author will be automatically transferred to the corresponding item on the authoring server.
In this use-case, the author gets the impression that they are indeed authoring on the publishing servers.
Q3: Can DPM ease the synchronisation between the authoring and publishing environments (does the WCM syndication and ReleaseBuilder work for portlets/assets behind the scenes)?
DPM dramatically simplifies the process but we do not replace the standard IBM WCM syndication nor the IBM Site Management mechanisms. We do have our own DPM database schema that maintains mapping between Portal pages and content items. The allocation of portal pages to content items is managed automatically by DPM custom workflow actions, which update the DPM database.
Since, the DPM database is shared between authoring and delivery servers both environments are automatically made aware of content-to-page mappings. DPM uses a design pattern of "page stacks". These are portal pages that are pre-created and waiting for allocation to content items (which is done during workflow).
The only synchronisation necessary between authoring and publishing is between the page stacks themselves since the mappings are shared. We do this by leveraging the IBM Portal Site Management tooling which can synchronise the page stack on a scheduled basis.
From an authoring perspective the entire process is transparent and automatic. Content items created; portal pages allocated; portlets added to the portal pages; DRAFT PORTAL PAGE preview and workflow. EVERYTHING is transferred automatically with no "deployment" necessary.
Basically release management happens simply by approving the item, which allows WCM and Portal to be considered as a single entity!
Q4. How does DPM work with the new IBM Portal "content" page?
DPM uses a Page Stack model for the handling of potal pages. This is different to the IBM hierarchical model into which the IBM Web Content Page can be created.
The current IBM model requires the site area to already have been created prior to the configuration and possibly creation of the "Web Content Page", it requires TWO interfaces (content and Portal Admin) and, in addition, syndication can transfer the content item to publishing servers without the corresponding portal page being delivered via a deployment process (since the release database domain of the publishing and authoring servers is not co-ordinated).
The current IBM model needs careful planning and co-ordination to work.
We expect that most of these issues will be solved in a future version of the IBM Portal but there is a much more important difference between the DPM model and the IBM model.
Using the IBM model only ONE Web Content page synchronised site area and all the content maintained in that site area will use the allocated Web content page. This becomes a major issue if the site area contains content created with multiple authoring templates and the customer requires a different presentation per authoring template (or even per content item!). It is not possible to add portlets to specific content items maintained in the same site area.
Domisphere Portal Manager has been designed with two degrees of freedom. We can allocate one portal page to multiple content items or one content item to multiple portal pages.
This allows us to deliver multi-variant presentation (one URL - two portal pages). Our tooling allows a business user to easily allocate "weight" to each of the variants so that real life prototyping is possible.
The two degrees of freedom also allows DPM to deliver DRAFT PORTAL pages. Using multiple content portlets and the drag-and-drop facilities of IBM Portal, business user can use a portal page as a "dynamic presentation template".
Q5: What is the difference between your friendly URLs, compared to the new ones from Portal (e.g. can it hide the parts in the URL that are used for actions in the page)?
DPM processes inbound URLs using our "DPM Context Engine". We can process ANY inbound URL and translate this into something that the portal understands.
The DPM Context Engine has four phases Extraction, Processing, Instanciation and Splitting. Each is extensible using a plug-in architecture. It is therefore possible to develop customer specific URL processing as required.
An example of an inbound URL could be:
http://host_name/news/paris
which will show the portal landing page for news from Paris.
Compare this to a Portal User Friendly URL: The URLs will have the portal context prefix:
http://host_name/wps/portal/news/paris
DPM friendly URLs:
Eliminate the need to create and store a URL mapping in Portal
Remove the portal context from the URL
Can work with a plug-in to allow rules based processing of the URL to delivery any content (e.g. different languages)
Out of the box, we use the site path of the content item (possibly minus the library name) as a URL. This allows the author some control over the friendly URL using the name element in the content item.
DPM also supports the concept of "site framework virtualisation" which allows sites and/or site areas to be grafted onto other sites/site areas. This allows multiple libraries to be presented as a single site structure to the end user. In these cases the friendly URL is simply a concatenation of all the WCM contexts in the virtual framework. The splitting of content creation into separate libraries and the presentation of those libraries into a single site structure allows businesses to use libraries as protected content silos. In any library, only the content authors will have access to the content items providing more flexible authoring configurations.
We have a design pattern that allows a library of link components to be created. These link components act as aliases to content items maintained in the site structure. Our DPM Context Engine can use these link components to provide tiny URLs to the end user, i.e.
http://host_name/CEO
Q6: Can DPM support portlet state in the URL then?
Most definitely.
We can append portlet state to friendly or tiny URLs - which is often needed for portal applications.
This state can be appended dynamically - which allows customers to choose when portlet state will be appended. For example: a friendly URL can be used as the first navigation to a page and when the user changes portlet state, only THEN will the state be appended to the URL.
It is up to the customers requirements exactly which model or models to use (could be a combination of many models in the same site), but please rest assured that DPM Context Engine can deal with such use cases.
Q7: Do you have to build anything special to manage multi-lingual sites?
Every requirement seems to be different for multi-lingual sites. In the context of delivery - our DPM Context Engine can process friendly URLs to delivery language specific content if necessary according to rules supplied in the Context Engine plug-ins.
We are working on a authoring design pattern, but believe this is probably best catered for with the ISSL asset since it synchronises multiple language translations.
Since we support site framework virtualisation, we can support requirements such as the need to have a top level navigation in one language and lower navigation structure in different languages.
Also, our DPM architecture, by supporting two degrees of freedom, allows different language versions of the same content item to be presented with their own portal page. This allows special language specific portlets to be presented only on the relevant language version of the content.
Q8: Do you have anything integrated with the site analytics?
Since site analytics work off URLs, Google site analytics can be used out of the box.
Since we have our DPM Context Engine, and support friendly URLs and tiny URLs, we can modify the URL processing via plug-ins to add additonal logging thereby providing better site analytics.
DPM uses a concept of "syndicated themes" allowing themes to be maintained as HTML components. By having the theme controlled by WCM, content metadata embedded in HTML META tags, can easily be published to the page.
We are currently working on enhancing metadata handling by making use of the DPM database. This will be released in a future version.
With regard to metadata, we can easily provide seed lists to products such as IBM OmniFind.
Q11: How does DPM affect portal scalability?
DPM is built on IBM Portal and so supports the same scalability model as Portal so that horizontal and vertical scaling is supported.
In a similar manner to a shared LDAP between all environments, DPM installations share the DPM database that maps portal pages to content items.
Q12: What is the recommended server set-up for a DPM installation?
This very much depends on the business requirements. DPM can be scale from a single installation (e.g. Portal Express architecture) to a multi environment, multi-server deployment.
Q13: How does DPM affect the architecture relationship between Lotus WCM and WebSphere Portal?
We have found that the relationship between IBM WCM and portal products is getting better - especially with the introduction of Web Content pages with 6.1.0.1 onwards. This standard feature allows a mapping between Lotus WCM site areas and WebSphere Portal pages. However, the mapping is currently only on a site area basis which is not flexible enough for many customer requirements. DPM extends the relationship to allow specific items of content to be mapped to portal pages. This offers the most flexible layout potential for business use cases.
Q14: What is the recommended development/staging/authoring/production environment? (this question is partly answered in the existing Q&A). Is it possible to differ from the recommended approach?
This very much depends on the problem and policy of the customer. WCM does not have a built in "staging" environment in the traditional understanding of staging where it becomes a authorisation platform prior to deployment in a live environment. Content items are typically edited and expected to be live totally automatically. For these environments a production environent comprising an authoring server, and a delivery server normally suffices.
When WCM site areas and navigators need to be authorised prior to "deployment", these can be catered for with the addition of a "preview" server that allows authorised users access to view site hierarchies that are not available to end users in production.
A "TEST / Proof of concept" environment will normally be included to mimic the live environment. This environment is used for testing of upgrades and patches.
A "Development" environment will normally be totally separate from the production ("live" environment). Content can be "reverse syndicated" from the main production server. This allows developers to work with live content. From this environment an integration testing environment can be serviced.
Q15: Would it be possible to apply DPM to an existing intranet/internet and what kind of person effort would be required (in general terms)?
Yes, but a migration process will be necessary if the company wish to make use of the flexibile layout capability of DPM
Q16: From a security and access perspective, what parts of the portal installation do authors need access?
The standard security model of Portal is maintained.
Q17: How are the typical tasks of Portal Administrators and WCM Authors affected by the implementation of DPM
This depends on the complexity of the installation but we effectively decouple Portal Administrators from WCM authors. Typical Portal Adminstration tasks such as URL mapping creation, Portal Page creation, etc are now automatically handled by DPM. Content authors no longer need to wait for Portal release cycles to deploy content, portlet pages and friendly URLs. Deployment of DPM managed items such as content and web pages is totally automatic when using DPM.
Q18: What are the other security implications of a DPM based WCM/portal installation?
DPM can add value to WCM installations with site grafting capabilities. In these cases WCM libraries can act as security domains for content and these can be integrated into a single virutal navigation structure. In this case the security is more flexible than a standard WCM installation, however we do not fundamentally change ANY of the underlying portal security models which of course will still apply.
Q19: What is the recommended approach in terms of Remote and Local Rendering portlets?
We recommend the use of Local Rendering Portlets in all cases.
Q20: DPM provides extra functionality in terms of workflow - how does it do this?
Firstly we supply a set of configurable custom workflow actions and a DPM action controller that triggers the actions. Next, using these custom workflow actions, we adopt a methodology that uses existing WCM workflows as modules in larger, more complex workflows. Our philosphy is to hide workflow from the authors and use business logic to workflow the content. We have found that authors find content creation and processing much easier when they do not need to manually choose workflow.
Q21: IBM are promoting Lotus Connections 2.5 in a portal - how can DPM work with this
Since DPM takes control of the processing of inbound portal requests, Lotus Connections integrates extremley well with DPM installations. Since DPM controls portlets on a per content basis, Lotus Connections integration becomes more flexible than the out of the box platform.
Q22: What are the priorities for the next release of DPM in terms of IBM's planned WCM/Portal 7?
The most important feature of the new version of Portal 7 appears to be content "folders" and "projects". We intend to fully leverage these concepts and improve end user authoring by building on the facilities embedded in IBM Portal 7.
In addition, we hope to be adding value to DPM installations with the addition of WCM management reporting. This is expected for release in the Portal 7 timeframe
