OFBiz service ECA call mode
1. Define the file location
First, we need to understand what ECA is?
During service execution, you can call the service in several steps.
Start transaction
User login authentication (auth)
Verify the input parameters according to the service definition (in-validate)
Run service invoke (invoke)
Verify the output result (out-validate) according to the service definition)
Commit a transaction (COMMIT)
Return the final result (return)
Before performing this step, we define a setting to run other services. This setting is service ECA.
Both service ECA and service. XML are stored in the/servicedef/directory of the corresponding module.
2. ECA Definition
2. Example
<ECA service = "testserviceonsimple" event = "return">
<Action Service = "testserviceonjava" mode = "sync"
Result-to-context = "true" result-to-result = "true"
Result-Map-name = "testserviceonjavaecaname"/>
</ECA>
The preceding example is a simple service ECA call. It means that when the system calls the service testserviceonsimple, it is called until the result is returned.
Testserviceonjava Service
If the value of result-Map-name is set
The result of testserviceonjava is put into the service with the value of result-Map-name as the key
Testserviceonsimple input parameters and overwrite the original.
(That is, context (testserviceonsimple). Put ($ {result-Map-name },
Result (testserviceonjava ));)
And assign the execution result of service testserviceonjava to service testserviceonsimple.
And the output result of service testserviceonsimple.
The output result of testserviceonjava is filtered according to the output definition of service testserviceonsimple ).
2.2.eca
: Service: name of the service that triggers the ECA call.
: Event: the event keyword that triggers the ECA call, that is, the steps for executing the service call. Before calling the steps of ECA, if the event value is commit, the ECA is called before commit.
2.3.condition, condition-service, and condition-field
These are all commands that determine whether to call the ECA service for conditions. If the condition is met, ECA is called. If the condition is not met, the system exits.
Condition: Compare the parameter variables with the fixed values.
<Condition operator = "equals" field-name = "workeffortid" Map-name = "paramap" value = "12345"/>
For details, see the condition-expr of minilang parsing. If map-name is set, the parameter variable is paramap. workeffortid.
Condition-field: Compare the parameter variables with the parameter variables.
To-field-name is the name of the parameter variable to be compared. If to-Map-name is not null, the parameter variable to be compared is $ {to-Map-name }. $ {to-field-name}
Condition-Service
You can call the service to determine whether the condition is not met if the returned result status code is error,
In other cases, the status code returned by the. Java service is error.
Re. Put ("error", errormsg );
Return re;
Or
Return serviceutil. returnerror ();
These three conditions and actions are used in combination.
2.4.set
See set.
The parameter variables used and operated by set, condition, condition-service, and condition-field are all carried out in the ECA input parameter context.
So where does the ECA input parameter context come from?
Assume that the ECA Action B service of Service A is called. The parameter source of Service B determines its source based on the event type. For example, if the event is "commit ",
"," Out-validate "," Global-commit-post-run ", and" return ", the source of parameters B is the context of A and
Result, while the parameters of other event types only come from the context of Service.
2.5.action
ECA trigger service definition.
Result-Map-name, result-to-context, and result-to-Result
In the 2.1 example.
: Mode = "sync": Synchronous execution. Mode = "async" is asynchronous.