We are just wrapping up a project where there was the need to expose Alfresco Web Scripts via the BEA AquaLogic Service Bus. This was a fairly simple process; however, there were a couple settings we had to tinker with. I will go over the details and hopefully it will save someone else some time down the road.
First some background for those who are not familiar. Alfresco is a professionally supported, open-source enterprise content management system (ECM). For this project, we used Alfresco as the ECM framework for a custom application that was based on document management and workflow. We were using the 2.1 Enterprise version of Alfresco, but this should also work for the 2.1 Community Editions as well. You can read more about Alfresco at: http://www.alfresco.com
AquaLogic Service Bus (ALSB) is a commercial product from BEA that serves as the ESB implementation for an SOA solution. The ALSB can be used to route, proxy, and orchestrate services. It also provides for centralized monitoring and governance of these services. The steps and screenshots I describe below are for ALSB v2.5. I suspect the steps would be the same with the new v2.6, but I have not had the chance to try. More info can be found at: http://www.bea.com
On with the details…
We leveraged the “Web Script†functionality available with Alfresco 2.1. This is a framework within Alfresco that allows you to create RESTful web services based on Alfresco content. In our case, we wrote a custom web script backed by a Java bean. That Java bean was responsible for pulling together several pieces of discreet content along with their properties and generating a single PDF summary document. Using the web script framework, we were able to expose this as an HTTP GET method and it returned a PDF document (CONTENT-TYPE = “application/pdfâ€).
As I go through the steps on ALSB, I will assume you have used this product before so I will only cover details specific to this use case. I also assume you have signed into the ALSB console and have created a project.
Step 1:
The first thing to do is to create a Service Account object. The Service Account determines how security credentials are used for the service. For simplicity in this example, select a “Static†type and enter your Alfresco credentials where provided. Note that in production, you would select “Pass Through†if both Alfresco and ALSB authenticate against the same directory. If they did not use the same directory you would select “Map†and map the ALSB credentials to the appropriate Alfresco credentials. Note that I am using the default HTTP Basic Authentication within Alfresco.
Step 2:
Next, create a Business Service object in this project:
- Service Type = Messaging Service
- Request Message Type = None (in my case the HTTP get as no request params.)
- Response Message type = Text (note that this not truly the case, but we will take care of later)
- Protocol = http
- Endpoint URI = the Alfresco URL used to call your service. For example: http://127.0.0.1:8080/alfresco/service/ui/mycustomscript
- HTTP Request Method = GET (In my case. POST should also work if your web script was setup for that)
- Basic Authentication is Required – Checked (Note that unless your Alfresco web script allows guest access you will need to send in credentials.
- Service Account – browse to the Service Account object that we created in the first step.
- Follow HTTP redirects - Checked
Before clicking Save, your settings should look like this:
Step 3:
Next, we need to create a Proxy Service object based on the Business Service object created above. Select the Same Request and Response Message Types and the same Protocol. Enter an Endpoint URI that the client will call. For example: /alfservice.
Since we used a Static Service Account type for the business service, leave the Basic Authentication Required unchecked. Note if you used a Map or Pass Through Service Account type, you would need to enable this option so that the proxy expected credentials to be passed from the client.
Your settings should look something like this:
If you tried to test the Proxy Service now, it would fail because your web script is most likely not returning a Text content type (text/plain) as we indicated in the Business Service object. We set this to Text because ALSB does not have a application/pdf response type option and also because we do not want to tie ALSB to the web script’s response type if we have a choice.
Instead, we will instruct the Proxy to dynamically set the Content-Type within the HTTP Header to match the Content-Type coming from Alfresco. This way, your Alfresco web script can change content types without impacting the ALSB.
Step 5:
To do this, edit the proxy’s message flow and add a Pipeline Pair element. In the Response flow, add a Stage to handle this logic. Your message flow should now look something like this:
Next, edit the stage and add a Transport Headers Action. Select to set for the Inbound Response (inbound to the client, that is). Select the option to Pass all Headers thru the Pipeline.
Finally, select the HTTP Content-Type Header and the Action is Copy Header from Outbound Response. Before you click Save button, your screen should look like this:
Once the ALSB session is Activated, you can test the Alfresco web script via the ALSB by calling the Endpoint URI you indicated in the Proxy Service configuration. Make sure you are pointing to the ALSB server and port and not the Alfresco server. For example, if ALSB is running locally on port 7001 use:
http://127.0.0.1:7001/alfservice
That’s it. A simple example, but you now have the option to do other actions in the proxy’s message flow as your requirements demand. You can also now monitor and set SLA targets and alerts for Alfresco services the same as you may already be doing for SOAP web services.