This documentation is for WSO2 API Manager 1.6.0 View documentation for the latest release.
Customizing a Workflow Extension - API Manager 1.6.0 - WSO2 Documentation
||
Skip to end of metadata
Go to start of metadata

Each workflow executor in the WSO2 API Manager is a child of the org.wso2.carbon.apimgt.impl.workflow.WorkflowExecutor abstract class. This has two abstract methods which are getWorkflowType, which returns a String and getWorkflowDetails(String workflowStatus) which returns a list of WorkflowDTO objects. The first method should return the Workflow type. The second method is not used at the moment and its implementation can just return null for the time being.

The two most important methods in this class are the execute and complete methods. The execute method contains the implementation of the workflow execution and the complete method contains the implementation of the workflow completion. If your workflow executor intends to customize the default workflow execution, it should override these two methods and provide its own implementation. This is exactly what we will be doing shortly.

The following class is a sample implementation of the Subscription Creation workflow. This will fire an email (to an address provided through the configuration) on each subscription creation.

SubsCreationEmailSender.java

Have a look at the execute method. This takes in a WorkflowDTO object which contains all the necessary information of the Subscription that is being created. In this case it is an instance of the SubscriptionWorkflowDTO class.

The adminEmail, emailAddress and emailPassword are private String variables with public getter and setter methods. The values of these variables are populated through the server configuration. These will be described when explaining how to configure the new workflow executor.

After sending the email, we make a call to the super class' execute method. This is so that we create a reference entry in the database. This entry is used to look up the workflow when the complete function of the workflow happens asynchronously (via a human approval). However in this sample we immediately call the complete function so that the subscription becomes active immediately. If the complete action of your workflow happens asynchronously you should not call the complete function from within the execute function.

It is also important to throw a WorkflowException in case of a failure. Throwing this exception will cause the subscription create action to roll back.

The complete function contains the code to mark the subscription as 'Active'. The subscription will be in the 'ON_HOLD' state until this is done.

After the implementation is done, you need to compile this class and export as a jar file. You need the following jars in your classpath to get this compiled.

i) org.wso2.carbon.apimgt.impl_1.2.1.jar
ii) org.wso2.carbon.apimgt.api_1.2.1.jar
iii) javax.mail.jar

The firt two jars can be found in the <AM_HOME>/repository/components/plugins directory and the third can be downloaded from here.

Once you export the jar file, copy it to the <AM_HOME>/repository/components/lib directory. Now open the <AM_HOME>/repository/conf/api-manager.xml file and navigate to the <WorkFlowExtensions> section. Comment out or remove the existing <SubscriptionCreation> section(s) and configure the new workflow executor as below.

<SubscriptionCreation executor="org.wso2.sample.workflow.SubsCreationEmailSender">
<Property name="adminEmail">[email protected]</Property>
<Property name="emailAddress">from [email protected]</Property>
<Property name="emailPassword">from_user_password</Property>
</SubscriptionCreation>

Note the adminEmail, emailAddress and emailPassword properties. These will be assigned to the appropriate variables in the class through the public setter methods of those variables.

Save and close the file and restart the server for this to take effect.

Note

If you are using the same or similar sample to fire an email, you need to remove the org.jaggeryjs.hostobjects.email_0.9.0.ALPHA4_wso2v1.jar file from the <AM_HOME>/repository/components/plugins directory. Removing this will result in a ClassNotFoundException being thrown at server startup, but that will not affect the server's functionality.

 

 

 

  • No labels