# JD Edwards Orchestrator Design Template > Source: https://netray.co/tools/jde-orchestrator-design-template > Publisher: Netray (netray.co), AI and integration engineering for ERP and manufacturing systems. > Section: Free Tools ## Short answer A fill-in design document for a JD Edwards Orchestrator orchestration: purpose, inputs, steps, rules, outputs, security and test cases. ## Category oracle ## Erp Oracle JD Edwards EnterpriseOne ## Audience - JDE developer - JDE functional consultant - Integration architect ## Tool **Kind:** template **Output:** document **Fields:** #### Orchestration name **Key:** name **Type:** text **Default:** CreateTransferRequest #### Business owner **Key:** owner **Type:** text **Default:** Warehouse manager #### Author **Key:** author **Type:** text **Default:** Integration developer #### Date **Key:** date **Type:** date **Default:** 2026-10-20 #### Business purpose **Key:** purpose **Type:** textarea **Default:** Allow a handheld app to request an inventory transfer between two locations without opening JDE forms. #### Calling system **Key:** caller **Type:** text **Default:** Warehouse handheld app #### Input fields **Key:** inputs **Type:** textarea **Default:** item_number (string), from_location (string), to_location (string), quantity (number), branch_plant (string) #### Steps **Key:** steps **Type:** textarea **Default:** 1. Form request to inventory transfer application 2. Rule to reject quantity of zero or less 3. Form request to commit the transfer 4. Return confirmation or error text #### Output fields **Key:** outputs **Type:** textarea **Default:** status (string), document_number (number), message (string) #### Expected volume **Key:** volume **Type:** text **Default:** 200 calls per day, peak 20 per hour #### Environments **Key:** env **Type:** select **Options:** - Development only - Dev and test - Dev, test and production **Default:** Dev, test and production **Blocks:** #### Document control **Body:** Orchestration: {{name}} Business owner: {{owner}} Author: {{author}} Date: {{date}} Target environments: {{env}} #### Purpose **Body:** {{purpose}} Called by: {{caller}} Expected volume: {{volume}} #### Inputs **Body:** {{inputs}} For each input record the data type, whether it is required and a sample value. Align names with the calling system's schema. #### Steps **Body:** {{steps}} #### Step detail **Table:** **Columns:** - Step - Type - JDE application or rule - Inputs mapped - On error **Rows:** **0:** 1 **1:** Form request **4:** Return error message **0:** 2 **1:** Rule **4:** Stop and return **0:** 3 **1:** Form request **4:** Return error message **0:** 4 **1:** Output mapping #### Outputs **Body:** {{outputs}} #### Security and access **Body:** Describe how the caller authenticates to the AIS server, which JDE user or role runs the orchestration, and which application security applies. Confirm the service user has only the permissions the steps need. Record who may see the orchestration in Orchestrator Studio and who may change it. #### Error handling and logging **Body:** List expected errors, the message returned to the caller and who is alerted. State how failed calls are logged and for how long. Define behaviour on timeout and whether the caller may retry safely without creating a duplicate transaction. #### Test cases **Table:** **Columns:** - Case - Input - Expected result - Actual - Pass **Rows:** **0:** Valid request **0:** Missing required field **0:** Invalid location **0:** Quantity of zero **0:** Duplicate submission #### Approvals **Signatures:** - Business owner - JDE technical lead - Security reviewer - Operations **Notes:** The example is illustrative. Orchestrator capabilities depend on your tools release, so check which step types and features your release supports. This template is a starting point for your own design review. ## Content **Intro:** JD Edwards Orchestrator lets you expose a business process, such as a transfer or an order inquiry, as a REST service that other systems can call through the AIS server. A short design document before you build in Orchestrator Studio saves rework. This template covers purpose, inputs, steps, outputs, security and tests. **Sections:** #### How to use the template **Body:** Fill in the fields about the business purpose, the calling system, the input and output fields and the steps. The generated document includes tables for step detail and test cases that you complete by hand after export. Share it with the business owner and your security reviewer before building, then update it when the design changes during testing. **Bullets:** - Name the orchestration clearly, since the name appears in the service URL - List inputs with type and whether required - Describe each step, rule and the error path - Define the output exactly as the caller expects it #### How an orchestration is built **Body:** An orchestration is a defined sequence that receives inputs, calls JDE applications through form requests or other connectors, applies rules and returns outputs. It is developed in Orchestrator Studio, run through the AIS server and called over REST, typically at an address under the AIS path followed by the orchestrator name. Because it can run real JDE forms, it can change data, so design it as carefully as any interface. #### Security and idempotency **Body:** Decide which JDE profile executes the orchestration and keep its permissions narrow. Think about repeats: if a caller retries after a timeout, can the same transfer or order be created twice? Add a reference field from the caller and check for it, or design the step so a repeat is harmless. Test with invalid and missing data, not only the happy path. #### Common mistakes **Body:** Teams often map too many fields, embed business rules in the calling app rather than the orchestration, or run everything under an administrator profile. Others forget to document the version of the tools release the design was built on, which matters when features differ. Keep a record of changes for audit. **Cta:** If you are connecting JDE to AI agents or mobile apps, Netray can help design the orchestrations and the guardrails, including human approval before any write-back. **Faq:** #### What is JD Edwards Orchestrator? **Answer:** It is the JDE tool for building REST based services from business processes without custom code in the calling system. You design orchestrations in Orchestrator Studio and run them through the AIS server, calling JDE forms and other steps. #### Does an orchestration need custom code? **Answer:** Many do not, because they use form requests and rules available in Orchestrator Studio. More complex logic may need custom Java or business functions. Check what your tools release supports before you design. #### How do I secure an orchestration? **Answer:** Use authenticated calls to the AIS server, run under a service profile with narrow JDE security, and restrict who can change orchestrations in Studio. Test with a profile that lacks access to confirm it is blocked. #### Should I use Orchestrator for bulk data loads? **Answer:** Usually not. It suits transactional, real time requests. For large batch loads use UBEs, Z-file interfaces or database level conversion tools designed for volume. ## Search terms jde orchestrator design, jd edwards orchestrator template, jde orchestration design document, orchestrator studio documentation, jde rest orchestration, jde ais orchestrator, jde orchestrator specification, jd edwards integration design --- Talk to an engineer: https://netray.co/contact?intent=erp_ai | Machine catalog: https://netray.co/agent/catalog.json