THIS IS A TEST INSTANCE. ALL YOUR CHANGES WILL BE LOST!!!!
...
Related Documents:
| Anchor | ||||
|---|---|---|---|---|
|
Introduction
| Anchor | ||||
|---|---|---|---|---|
|
...
Services are defined with a unique name, associated to a specific service engine and the input and output parameters are defined explicitly. Below is an example of a service definition:
| Code Block |
|---|
<service name="userLogin" engine="java" location="org.ofbiz.commonapp.security.login.LoginServices" invoke="userLogin">
<description>Authenticate a username/password; create a UserLogin object</description>
<attribute name="login.username" type="String" mode="IN"/>
<attribute name="login.password" type="String" mode="IN"/>
<attribute name="userLogin" type="org.ofbiz.entity.GenericValue" mode="OUT" optional="true"/>
</service>
|
...
Internal Usage of the Services Framework is quite simple. In a Web Application the LocalDispatcher is stored in the ServletContext which can be accessed via the Session object in an Event. For non-web based applications you simply create a GenericDispatcher: GenericDelegator delegator = GenericDelegator.getGenericDelegator("default");
LocalDispatcher dispatcher = new GenericDispatcher("UniqueName",delegator);
Now we have a dispatcher which we can use to invoke services. To invoke the test service create a Map for the context which contains the IN parameter message *then invoke the service:*
| Code Block |
|---|
Map context = UtilMisc.toMap("message","This is a test.");
Map result = null;
try {
result = dispatcher.runSync("testScv", context);
} catch (GenericServiceException e) {
e.printStackTrace();
}
if (result != null) {
System.out.println("Result from service: " + (String) result.get("resp"));
}
|
...
To schedule a service to run at a later time or to repeat use this:
| Code Block |
|---|
// This example will schedule a job to run now.
Map context = UtilMisc.toMap("message","This is a test.");
try {
long startTime = (new Date()).getTime();
dispatcher.schedule("testScv", context, startTime);
} catch (GenericServiceException e) { e.printStackTrace();
// This example will schedule a service to run now and repeat once every 5 seconds a total of 10 times.
Map context = UtilMisc.toMap("message","This is a test.");
try {
long startTime = (new Date()).getTime();
int frequency = RecurrenceRule.SECONDLY;
int interval = 5;
int count = 10;
dispatcher.schedule("testScv", context, startTime, frequency, interval, count);
} catch (GenericServiceException e) {
e.printStackTrace();
}
|
...
The interface service engine has been implemented to help with defining services which share a number of the same parameters. An interface service cannot be invoked, but rather is a defined service which other services inherit from. Each interface service will be defined using the interface engine, for example:
| Code Block |
|---|
<service name="testInterface" engine="interface" location="" invoke="">
<description>A test interface service</description>
<attribute name="partyId" type="String" mode="IN"/>
<attribute name="partyTypeId" type="String" mode="IN"/>
<attribute name="userLoginId" type="org.ofbiz.entity.GenericValue" mode="OUT" optional="true"/>
</service>
|
...
Now that we have an interface we need to define a service which implements this interface
| Code Block |
|---|
<service name="testExample1" engine="simple" location="org/ofbiz/commonapp/common/SomeTestFile.xml" invoke="testExample1">
<description>A test service which implements testInterface</description>
<implements service="testInterface"/>
</service>
|
...
ECA (Event Condition Action) is much like a trigger. When a service is called, a lookup is performed to see if any ECAs are defined for this event. Events include before authentication, before IN parameter validation, before actual service invocation, before OUT parameter validation, before transaction commit, or before the service returns. Next each conditionin the ECA definition is evaluated and if all come back as true, each actionis performed. An action is just a service which must be defined to work with the parameters already in the service's context. There are no limit to the number of conditions or actions each ECA may define.
| Code Block |
|---|
<service-eca>
<eca service="testScv" event="commit">
<condition field-name="message" operator="equals" value="12345"/>
<action service="testBsh" mode="sync"/>
</eca>
</service-eca>
|
A tip from Parimal Gain : Note that you may use the set operation to rename a parameter for the triggered service or insert values for instance...
| Code Block |
|---|
<eca service="setCustRequestStatus" event="commit">
<condition field-name="oldStatusId" operator="not-equals" value="CRQ_ACCEPTED"/>
<condition field-name="statusId" operator="equals" value="CRQ_ACCEPTED"/>
<set field-name="bodyParameters.custRequestId" env-name="custRequestId"/>
<set field-name="bodyParameters.custRequestName" env-name="custRequestName"/>
<set field-name="partyIdTo" env-name="fromPartyId"/>
<set field-name="emailTemplateSettingId" value="CUST_REQ_ACCEPTED"/>
<action service="sendMailFromTemplateSetting" mode="sync" />
</eca>
|
...
The group definition is very simple, it contains a group elements along with 1 or more service elements. The group element contains a name attribute and a modeattribute used to define how the group will function. The service element is much like the actionelement in an ECA, the difference being the default value for result-to-context.
| Code Block |
|---|
<service-group>
<group name="testGroup" send-mode="all">
<invoke name="testScv" mode="sync"/>
<invoke name="testBsh" mode="sync"/>
</group>
</service-group>
|
...