Use an existing project as template for a new project

Use an existing project as template for a new project


We came in the situation that we had a number of permit business processes with a lot of similarities.

The overall structure of a permit request is shown below:


Use an existing project as template for a new project

The process is triggered by an incoming request. A part of the request payload is equal for every permit request (like details of the requestor). The rest of it is permit specific. E.g. Event location or dump location.

  1. The process starts with some overall initialization of email addresses, permit specific variables, etc.
  2. After that a new case/file is created and it’s status is initialized.
  3. All case processing starts with a decision.
  4. For rejected request the status is set to ‘Reject’ before closing the case (10).
  5. For approves requests the status is set to ‘Approve’.
  6. Than some permit specific actions follow. E.g. tent usage at a event permit.
  7. The permit document is generated as a PDF document.
  8. The permit document is send to all stakeholders. This differs depending on the permit type.
  9. Perform other permit specific actions like sending a bill or not to the requester.
  10. And finally set status closed and close the case.

As can be derived from the overall structure the process flow is more or less the same for all permit types.

This advocates for one (BPEL) process with some permit specific decision points which makes it a little less straight forward but doable. Complications start when the payload comes into view. Every permit type has it’s one specific payload (with some overlap). This does not really plea for one generic process. In this situation every instance has to deal with some irrelevant data fields (to other permit relates fields).

Things get even more complicated when changes for a specific permit type carry through. A redeploy impacts also the other permit types. This is an undesirable site effect.


Template approach

As an alternative, I choose to create separate (BPEL) processes for each permit type. But did not want to develop the same process structure over and over again. So we developed a template approach. What does that mean:

I created one permit BPEL process using a strict naming conventions. Everywhere the permit name is used I used the following structure: <prefix><permittype><suffix>.

  • Prefix:              WebNext
  • Permittype:       e.g. Event or Dump
  • Suffix               Permit (Vergunning in dutch).

To get the other permit processes, I created an ANT script. After setting some properties, the execution of this script has the following result: a complete project is copied and all permit type references are replaced.

To finish the new permit request Business Process all permit specific changes must be applied.

The remainder of this chapter contains the content of the properties file, the ANT script and some explanation.

# global 

# template


The global part of this file is general and part of almost every ANT script. The template part contains the relevant properties.

  • Root                                        parent folder of permit projects
  • Bron                                        source permit project
  • Bestemming                            destination permit project
  • BronLocatie                             Location of source permit project
  • BestemmingLocatie                 Location of destination permit project
  • BronNaam                               Full source name
  • BestemmingNaam                   Full destination name


<?xml version="1.0" encoding="iso-8859-1"?> 
<project name="createWebNextProces" default="NieuwWebNextProces"> 
    <echo>basedir ${basedir}</echo> 

    <property file=""/>

    <!-- Onderstaande taskdef zorgt ervoor dat je additionele targets krijgt voor sca deployment e.d. -->
    <taskdef resource="net/sf/antcontrib/"/> 
    <import file="${oracle.home}/bin/ant-sca-deploy.xml"/> 

    <target name="NieuwWebNextProces">
        <echo>Create new NieuwWebNextProces '${proces.bestemmingLocatie}' based on existing process
        <delete dir="${proces.bestemmingLocatie}"/>

        <copy todir="${proces.bestemmingLocatie}" filtering="true">
            <filterset begintoken="WebNext" endtoken="Vergunning">
                <filter token="Sloop" value="WebNextEvenementenVergunning"/>
            <filterset begintoken="webnext" endtoken="vergunning">
                <filter token="sloop" value="webnextevenementenvergunning"/>
            <fileset dir="${proces.bronLocatie}"/>

        <move  file="${proces.bronNaam}.bpel"
        <move  file="${proces.bronNaam}.componentType"
        <move  file="${proces.bronNaam}.wsdl"
        <move  file="${proces.bronNaam}.jpr"
        <move  file="${proces.bestemmingLocatie}\xsd\${proces.bron}.xsd"
        <move  file="${proces.bestemmingLocatie}\xsl\ARNSMA_TYPE_To_${proces.bron}RequestElement.xsl"
        <move  file="${proces.bestemmingLocatie}\.designer\${proces.bron}_graphics.xml"
        <move  file="${proces.bestemmingLocatie}\AQWebNextSloop.wsdl"
        <move  file="${proces.bestemmingLocatie}\xsd\WebNextSloop.xsd"


The build file contains the ‘NieuwWebNextProces’ (NewWebNextProcess) target. The target performs the following three tasks:

  1. Delete the destination folder. If the permit type already exists, it is recreated.
  2. Copy the complete source project to the destination. During this copy operation two replacement filters are applied.
    – WebNextSloopVergunning is replaced by WebNextEvenementenVergunning
    – webnextsloopvergunning is replaced by webnextevenementenvergunning
    All occurrences of these word in the file content are replaced.
  3. Finally, also a number of file must be renamed. This happens in al the move operations.