Archive for September, 2011

Publishing assets in the Correspondence Management Solution 3.0

The Correspondence Management Solution 3.0 introduces the concept of publishing assets, and deprecates the concept of activation (which was used in the 2.5.x version of the solution).

The solution is typically configured on two separate (ADEP Experience Server) instances – an Author instance and a Publish instance (see the installation and configuration documentation on how to configure the solution over the two instances).

The Author instance is one on which assets/templates are created and managed (using the Manage Assets interface). One can also Preview the Letter templates created on the Author instance, which launches the Create Correspondence interface in a document preview mode.

The Publish instance is one on which the final correspondence is created by agents (using the Create Correspondence interface), using the designed letter templates and published assets. The Manage Assets interface is also available on this instance, but with restricted actions.

Once done with the asset authoring, they must be marked Ready to Publish, indicating the same to the persona (which would typically be different from the one creating/editing the asset) responsible for publishing the asset, who can then go ahead and publish the asset. Note that when publishing an asset, all assets related to this asset should be in Published or Ready To Publish state. Assets that are in Ready To Publish state are published automatically, while the ones that are already Published, are ignored. If any related asset is in a Modified state, the publish operation is aborted, and hence cannot proceed until all related assets are marked Ready to Publish. The understanding behind this behavior is that there could be different persona involved in creation of various related assets, and it is essential that each one of them marks the respective asset ready to publish (indicating completion) before they can really be published.

Here’s a state diagram for various asset states, and how they transition on various actions:

On publishing an asset, a new version of the asset gets created on the Author instance, and the asset is immediately ‘replicated’ over to the Publish instance, which always has a single (head) version of an asset.

Also note that any related Data dictionaries are not published automatically when assets that use it are published. You are required to explicitly publish data dictionaries.

Read more on asset publishing and versioning here.

Common ADEP URLs

As part of your journey into the Adobe Digital Enterprise Platform (Experience Server), there are certain parts/applications of the platform that you may need access to quite frequently.

Here is a list of some of those with a short description of what they can be used for (assuming that your Experience Server is running on localhost and port 4502 – if you have a different server URL, the links should change accordingly):


Bookmark the above links and enjoy development over ADEP!

Building OSGi bundles for ADEP

When building custom enterprise applications and solutions over the Adobe Digital Enterprise Platform, there is often a need to build custom OSGi bundles that deploy/expose services to be used within the application (typically by the UI layer). Such bundles are deployed in the platform’s OSGi container (Apache Felix).

Here’s a sample Java project, that can be used as a reference or a template to help you build your own OSGi bundle within minutes.

The project essentially consists of the following:

  • Sample Service (com.adobe.adep.sample.ADEPSampleService), and its implementation, that is exposed by this bundle.


  • osgi-context.xml – configuration file (snippet below) that defines the service bean, and uses Spring (Blueprint) to expose it as an OSGi service, available over Flex and HTTP remoting.


  • BND tool/library and the supporting configuration file (snippet below) – to help generate an OSGi bundle.

  • ANT based scripts – to build the final deployable bundle.


To build the above project and generate your OSGi bundle, simply import the project in Eclipse and run the associated build.xml file. Or, use ANT over command line to do the same. The final deployable bundle archive (JAR) is generated in the dist directory of your project root directory.

This can now be deployed over the ADEP OSGi container, the URL of which would typically be http://server:port/system/console/bundles. Your deployed bundle would be listed on the console as shown below, once deployed successfully:


Of course, this is just a sample that illustrates how easy it is to build your OSGi bundles for ADEP. You could extend this to define more complex, real life services within the bundle and get yourself going in minutes…

ADEP Solutions and Document Server

The Adobe Digital Enterprise Platform consists of two technology stacks – the Experience Server and the Document Server. The combined architecture provides services required for various Customer Experience Solutions.

The Experience Server needs to be integrated (configured) with the Document Services to leverage services that address multiple enterprise applications requirements around content creation, management, protection, distribution and enterprise workflows. The below video not only shows the steps to configure your Document Server instance with your Experience server, but also talks about building web applications that use Document Services.



You may also check out the published documentation on the exact steps to be performed.