Creating DFS Services using Documentum Composer
From: http://paulcwarren.wordpress.com/2008/08/11/creating-dfs-services-using-documentum-composer
I’m not sure how many people realize it but when you create a Documentum “artifact” project within composer, it is also a “dfs services” project. If you right click one of your Documentum projects and bring up its properties, then select the Java Build Path, then the Libraries tab you should see something similar to this:-
An if you select Properties->Builders, you should see something like this:-
When an “artifact” project is created it also adds all the necessary DFS resources to allow you to develop Documentum services. It will deploy a copy of the DFS SDK to your core project (incidentally this is why creating the first project in a workspace takes a little longer than you might expect) and add the DFS Services Library to your project’s java build path. And add a DFS Builder for building your services.
Creating a Service Consumer
Just as a quick aside if you do need to create a consumer, select the “DFS Services Library” entry and then select Edit, you should see something like this:-
As you can see there are in fact 4 flavours of DFS services library. The first, and the default, is concerned with developing services (today’s topic). The remaining three are actually concerned with developing service consumers. They are pretty self-explanatory. The only one that perhaps requires a little explanation is the last; “DFS Local Client”. You add this type of library to projects that are acting as “functional tests” for your services projects. Typically, you create one or more of these “functional test” projects in the same workspace as your services projects and configure them with this type of library. This then allows you to debug from the client into the service and back again without having to deploy to a server. A useful feature. I will talk more about developing service consumers in a future articles.
Building a Service
OK, so back to developing the services themselves. As you can see your project is all set up for service development. Now you need to develop a service. As you will probably all be aware there are a couple of flavours of DFS service; one based on a POJO and another based on a BOF SBO (service-based object). They are, in fact, very similar and are just annotated java classes. You can read more about DFS and its annotations from the DFS developer’s guide. I won’t go into these here. We’ll use the POJO variant here. And for convenience we’re going to use one of the samples provided in the DFS SDK; <DFS SDK install dir>/samples/HelloWorldService. All we need to do is navigate to <DFS SDK install dir/samples/HelloWorldService/src/service folder and copy the top level folder of the source tree, “com” in this case. Then paste it into the the /Web Services/src folder of your Documentum project.
Once you drop these sources packages and class files into the Web Services folder, and assuming that you have “automatic build” turned on, then you should see the DFS Builder leap into life and attempt to build the service. In your Console view you’ll get a build report:-
And if you open the standard Navigator view (Window->Open View->Navigator) and navigate to the Web Services/bin/gen-src folder you should also see a set of generated source. This is actually a jax-ws web service that has been generated from your POJO service. And under the classes folder you should see a set of classes and wsdl. These classes are an aggregate compilation of your POJO (and associated classes) and the generated jax-ws web service. The wsdl is obviously just standard wsdl also generated from your POJO:-
If for some reason your service fails to compile then you will of course get all the same familiar productivity tools for dealing with these issues that you have for plain old java development. For example you’ll get errors and warnings reported in your Problem view:-
And just so you know the DFS Builder does support incremental builds and will only rebuild services that have changed since the last build so it should be reasonably efficient.
Testing the service
So now we’ve reached the point where we have a service that needs testing. There are two approaches to this. The first is to create a parallel test project with Junit tests that exercise your service. To facilitate this your test project would be configured with the local client library, as described above, so that it can make local invocations to your service. This project should of course be placed under the same version control as your services project.
The second approach is to export your services as an ear, deploy it to an application server and exercise your service again via another project capable of making remote service invocations. Before you do this though you must remember to set the archive’s context root and module name as both of these affect the eventual URL of your service. This is a one time deal though so just right-click on the project and select Properties->Documentum Project->DFS Module:-
Just so you are aware. Typically all EMC DFS services share a context root of “services” and a module name that describes their general function. Core for core services, bpm for business process, etc. These will then be available via URLs such as http://localhost:8080/services/core… and http://localhost:8080/services/bpm…
Once these settings are made you can export the service. Right-click on the project and select Export->Documentum->Export Service Archive:-
The archive name and context root should be defaulted for you from your DFS Module settings page. Choose an output folder. Uncheck the Generate Publish Manifest. This is only required is you want to publish your services to a UDDI registry using the DFS tools. And click finish. This will produce your ear file. Once you are in possession of the ear you can deploy it onto your app server using the appropriate app manager console or by dropping it into the hot deploy folder. Whichever works for you. Once you have it deployed you can perform a quick sanity check by requesting the service’s WSDL document by requesting something like http://localhost:8080/services/helloworld/HelloWorldService?wsdl. Assuming you get back the WSDL document (that matches the one that was generated by the builder earlier) then you are good to go.
Next you will need to create yourself another test project. But this time configure it with one of the two available Remote Client library options, depending on your content transfer requirements. Again, creating Junit test cases I find is the quickest and easiest. These can be rolled up into test suites and all can be invoked easily enough through the Composer (eclipse) UI. And once again, if you can standardize this process across your development team then you can check this test project into source control right along side your services project.
In Summary
In summary we have walked through the out-of-the-box capabilities of a Documentum project with respect to creating DFS services. Every Documentum project has the capability to host the development and testing of DFS services. There are four libraries that are at your disposal for development and testing. Each project has an incremental builder that is capable of automatically building your services. And finally there is an exporter that can produce an ear file containing your services that is ready for deployment onto any app server.
Looking forward, in future articles I will talk more about another development option which leverages both Composer’s and WTP’s capabilities. This option gives you far greater control over the contents of your ear and brings remote debugging of your services to your IDE.
In the meantime, happy Composing.
Explore posts in the same categories: Documentum Foundation Services, composer, content management, dfs, documentum, documentum composer, ecm
