Complete the Group definition
Last time we only created the aml class, but we did not define some groups in the class properties that will be used for details view or search view for example, so we’ll need to complete this. As eForm extends Approvable, they inherit a Name field (which is defaulted by Ariba) which we do not want to see here so the group definition will look as below:
<inModule name="ariba.common.meta.Requisition">
<group name="HeaderDetailsEditable">
<groupClass name="config.sandbox.supplier.eform.SupplierEForm">
<remove>
<groupField name="Name"/>
</remove>
</groupClass>
</group>
<group name="HeaderDetailsNoneditable">
<groupClass name="config.sandbox.supplier.eform.SupplierEForm">
<groupField name="SupplierName"/>
<groupField name="SupplierDUNSId"/>
</groupClass>
</group>
<group name="SupplierEFormDetailsGroup">
<groupClass name="config.sandbox.supplier.eform.SupplierEForm">
<groupField name="SupplierName"/>
<groupField name="SupplierDUNSId"/>
</groupClass>
</group>
<group name="SupplierEFormSearchGroup">
<groupClass name="config.sandbox.supplier.eform.SupplierEForm">
<groupField name="SupplierName"/>
<groupField name="SupplierDUNSId"/>
</groupClass>
</group>
</inModule>
Wizard : make it nice
By default, we’ve seen that Ariba creates the eForm and associates the standard “3-steps” wizard. Actually as we have little information to enter, we can get rid of the first screen. Copy the file ariba/variants/Plain/wizards/Eform/Eform.awz to config/variants/Plain/wizards/Eform/SupplierEForm.awz (see wizardFile property in previous post) and remove the 2 lines that declares the first screens
<step name="TitleFrame" file="Title.afr"/>
<step name="FormFrame" file="Form.afr"/>
Now when you open the eform, there’s only 1 screen with everything (summary and approval flow tab) :
Approval Rules : lets the eForm be approved
Create a new rule for the eForm we created (Go to the Administration Manager, then under Customization Manager click on Rule Editor and click on the Create New Rule Set (top left button))
- give a name to your file, generally JavaScript
- Select your variant (Plain, you can define at a variant level if you want to have variant specific rule)
- From the Approvable drop down, select the class name
- Make it active and to be loaded at loaddb 9r1 has really simplified the creation of new rules, Before you would have add a simple rule and write in code both condition and action, something like:
function suppliermanager_condition (r)
{
return true;
}
suppliermanager_condition;
var SupplierManagerGroup = Group.getGroup("Supplier Manager");
function suppliermanager_action (r)
{
return ApprovalRequest.create(r,
SupplierManagerGroup,
true,
"ruleReasons", "SupplierManagerApproves");
}
suppliermanager_action;
Now you can do it via UI and it looks something like:
Again, you can create a new Edit Rule by UI
This Edit Rule tells the system that any user of the Supplier Manager group can edit the eForm and approval is not regenerated.
Workflow : let the supplier be created
The eForm workflow is like a state diagram; it describes the possible state of the eForm and declares action which will take place at the different state of the eForm. In our example, we want a supplier to be created once the eForm is approved, so we need to add a workflow file under config/variants/Plain/workflows/ SupplierEFormWorkflow.efm and define it as
<!DOCTYPE workflow SYSTEM "../../../../ariba/server/workflowserver/workflow.dtd">
<workflow name="SupplierEForm"
workflowClass="config.sandbox.supplier.eform.SupplierEForm"
description="This is our supplier eForm workflow - create suppliers once request is approved">
<beginState name="BEGIN">
<transition name="BEGIN_TO_APPROVED">
<fromState name="BEGIN"/>
<event type="SupplierEForm:Approved"/>
<toState name="APPROVED"/>
</transition >
</beginState>
<state name="APPROVED">
<entry>
<action implementation="config.sandbox.supplier.action.SupplierEFormApproved"/>
</entry>
</state>
</workflow>
From the workflow definition : You can name your workflow as you want but it is important (we’ll see in a minute) The workflow class must match our supplier eForm class so the system knows this workflow will act on this class Now you define the state. Here we say that the approval starts with state BEGIN; and we have a transition from BEGIN to APPROVED, note the event type is SupplierEForm:Approved, this is the name of the workflow with the new state, so you can reference other workflows. For example if you look at more advanced workflow like Purchasing or Invoicing workflows, the transition occurs when other workflow are triggered. We tell the system that when he enters the APPROVED state, it must run a given action. This action is a java class and will create our supplier. The action class is defined as following:
public class SupplierEFormApproved extends Action
{
public static String className = SupplierEFormApproved.class.getName();
/**
* Entry point of the Action
*
* @param object
* @param params
* @see ariba.base.fields.Action#fire(ariba.base.fields.ValueSource, ariba.util.core.PropertyTable)
*/
public void fire (ValueSource obj, PropertyTable arg1)
throws ActionExecutionException
{
ClusterRoot eform = (ClusterRoot) obj;
createSupplier(eform);
}
private void createSupplier (ClusterRoot cr) {
// create a new partitioned supplier
Supplier supplier = createPartitionedSupplier(cr);
// use post load integration event to link with common supplier
IntegrationPostLoadSupplier updateSupplier = new IntegrationPostLoadSupplier();
updateSupplier.fire(supplier, null);
}
/**
* This method creates a new partitioned supplier with the minimum necessary values
* based from values in eform and link to a common supplier.
* @param eform the eform which contains the supplier values
* @return a new partitioned supplier
*/
private Supplier createPartitionedSupplier (ClusterRoot eform) {
// ---------------------------------
// create the new supplier
// ---------------------------------
Supplier supplier = new Supplier (eform.getPartition());
// set header supplier values from eForm
supplier.setUniqueName(eform.getUniqueName());
supplier.setName((String)eform.getFieldValue("SupplierName"));
supplier.setSupplierIDDomain(Organization.BuyerSystemID);
supplier.setSupplierIDValue(eform.getUniqueName());
// add the duns as a new organizationIdPart
// ---------------------------------
// save object
// ---------------------------------
supplier.save();
return supplier;
}
/**
* allowed types for the value
*/
protected ValueInfo getValueInfo ()
{
return new ValueInfo(IsScalar, Approvable.ClassName);
}
}
Okay, we’re done, when the eform will be approved a new supplier will automatically be created.
