[
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)
Locked
