[
https://issues.apache.org/jira/browse/OFBIZ-4274?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16483595#comment-16483595
]
Scott Gray commented on OFBIZ-4274:
-----------------------------------
Hi Taher,
Here's an cut-down example of what a "shipment" resource might look like, based
on some POC work I did a while back.
{code:xml}
<?xml version="1.0" encoding="UTF-8" ?>
<resource-model name="shipment" entity-name="Shipment">
<many-relation field-name="items">
<entity-relation name="ShipmentItem" />
<link-relation field-name="product" resource-name="Product">
<entity-relation name="Product" />
</link-relation>
<many-relation field-name="orderShipments">
<entity-relation name="OrderShipment" />
<many-relation field-name="issuances">
<virtual-relation entity-name="ItemIssuance">
<key-map field="orderId" />
<key-map field="orderItemSeqId" />
<key-map field="shipGroupSeqId" />
<key-map field="shipmentId" />
<key-map field="shipmentItemSeqId" />
</virtual-relation>
</many-relation>
</many-relation>
</resource-model>
{code}
So that file defines how a shipment resource document might map to the database
which in turn allows for your basic CRUD operations. Basic CRUD isn't much use
for a web API though because we need business logic to be triggered (generate a
UPS shipping label when the shipment status changes to packed for example, or
create an invoice, or set default shipment details on creation) or we might
need to modify the resource before it gets processed any further (e.g. derive a
productStoreId for an order resource from the servlet context, or set an order
item price).
I had pictured that all of the business logic involved processing data sent
from a client as being attached to the resources via ECAs, so rather than
having the complex chain of service calls we live with in our current
architecture, we'd have a series of discrete ECA services that would interact
with the resource or trigger the creation of other resources. Reorganizing the
business logic into these ECA services is what I mean by the need to "rewrite
everything".
A RECA would be just like a Service-ECA/Mail-ECA/Entity-ECA in that it is just
a conditional trigger that gets fired at some point during the various
processing phases of the Resource. The target services would take the resource
as the sole in/out parameter and modify the resource if needed (e.g. by adding
shipment billing details to the resource when the shipment is invoiced).
> Implement a REST Servlet
> ------------------------
>
> Key: OFBIZ-4274
> URL: https://issues.apache.org/jira/browse/OFBIZ-4274
> Project: OFBiz
> Issue Type: New Feature
> Components: framework
> Affects Versions: Trunk
> Reporter: Adrian Crum
> Priority: Minor
> Labels: REST
> Attachments: RestExampleSchema.xsd, RestXmlRepresentation.xml,
> rest-conf.xml, swagger-pos-openapi.png
>
>
> Implement a REST servlet that will map REST requests to OFBiz services.
> Details are in the comments.
> [here is the discussion which took place on the dev
> ML|http://markmail.org/message/ai6q2fbksowaayn4]
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
