Service Definitions Part 2: Exposing Projection Entities as a Business Service

📌 KEY POINTS
✅ A service is a business capability: "maintain purchase requests" — expose everything it needs, nothing more.
✅ Always expose the root and all composition children used by the app.
✅ Aliases become entity set names in OData and in client code.
💡 After activation, check the binding's entity list and $metadata.

━━━━━━━━━━━━━━━━━━━━
▶ WHERE WE ARE
Part 1 introduced the object. Now: how to decide what goes into one service.

━━━━━━━━━━━━━━━━━━━━
▶ 1. THINK IN CAPABILITIES
A service supports one business capability for one consumer type:

• ZUI_PURCHREQ — buyers maintain purchase requests in a Fiori app.
• ZUI_PURCHREQ_APPROVE — approvers review and approve.
• ZAPI_PURCHREQ — external systems create and read requests.

Each has its own projections and service definition. A "one service for everything" approach makes every change risky for all consumers.

━━━━━━━━━━━━━━━━━━━━
▶ 2. WHAT TO EXPOSE FOR A TRANSACTIONAL APP

• The root projection (ZC_PurchReq).
• All composition children the app shows or edits (ZC_PurchReqItem).
• Entities needed for navigation from the object page (e.g. a read-only supplier projection, if you want navigation, not just a value help).
• Value-help entities, when they are not reachable otherwise (Part 6).

━━━━━━━━━━━━━━━━━━━━
▶ 3. ALIASES

• The alias becomes the entity set name: /PurchaseRequest, /PurchaseRequestItem.
• Use singular business nouns in CamelCase; avoid prefixes like ZC_.
• Once consumers use a service, aliases are part of the contract (Part 3).

━━━━━━━━━━━━━━━━━━━━
▶ 4. VERIFY
After activation and binding:

• The binding editor lists the entity sets and their navigation.
• $metadata shows EntityTypes, EntitySets, NavigationProperties and actions.
• The preview shows whether the app works end to end.

━━━━━━━━━━━━━━━━━━━━
▶ STEP BY STEP

1. Write down the capability and the consumer.
2. List the entities the app needs (root, children, navigation targets).
3. Write the service definition (code example).
4. Activate, bind (V4 – UI), publish, and check entity sets and navigation in $metadata.

✅ CHECKPOINT: your service contains exactly what the capability needs.

A project had one large service exposing purchase requests, orders, suppliers, approvals and reports for five apps. Every change to one app required regression tests of all five, and the $metadata was so large that apps started slowly.
The team split it by capability: a buyer service, an approver service and a reporting service, each with dedicated projections. Changes became local, metadata shrank, and app start times improved noticeably.

• One huge service for many apps.
• Forgetting composition children, so object pages cannot show items.
• Exposing entities "just in case".
• Technical aliases that leak object names into client code.
• Not verifying entity sets and navigation after activation.

• One service per capability and consumer type.
• Expose root, children and required navigation/value-help targets.
• Use stable business aliases.
• Verify in the binding and $metadata every time the service changes.
• Keep services small for fast metadata loading.

Questions: "How do you decide what goes into a service definition?", "Why not one service for everything?"
Strong answer: design services per business capability and consumer type; expose the root, the composition children and required navigation/value-help targets; use business aliases; verify via binding and $metadata. Explain the cost of monolithic services: coupling, regression effort and large metadata.