Building a REST-Based Parameter Integration in Oracle Integration Cloud (OIC)

Integrations play a vital role in connecting applications, automating processes, and enabling real-time data exchange across enterprise systems. Oracle Integration Cloud (OIC) provides a powerful, user-friendly platform that allows developers, analysts, and integration specialists to design and deploy integrations using prebuilt adapters, visual tools, and guided configuration wizards. In this project, we walk through the complete process of building a simple yet functional REST-based integration that accepts input parameters, processes values through assignments and loggers, and returns a structured response to the caller.

This tutorial is designed for beginners and intermediate users who want to understand how REST triggers work inside OIC and how different components—such as request parameters, mapping activities, logging, and tracking identifiers—fit together within an integration flow. Through a step-by-step approach, you will learn how to configure a REST endpoint, define URI parameters, create operational logic, add diagnostic logging, and validate your integration using the built-in testing console. Each step mirrors the real development workflow in OIC, ensuring that you gain practical experience that can be applied to real-world integration projects.

By the end of this guide, you will not only understand how to design a working REST integration but also how to activate it, test it, and monitor its execution. This foundational knowledge serves as a strong starting point for more advanced OIC capabilities, including connecting to SaaS or on-premise systems, performing data transformations, handling errors, and orchestrating multi-step business processes. Whether you are learning OIC for the first time or strengthening your integration skills, this project will give you a solid understanding of how to build reliable, traceable, and maintainable REST-based integrations in Oracle Integration Cloud.

Oracle Integration Cloud (OIC) Account

Access to an Oracle Integration instance where you can create and deploy integrations.

Web Browser

A modern browser such as Google Chrome, Microsoft Edge, or Firefox to access OIC.

OIC Access Credentials

Valid username and password with permissions to design, activate, and test integrations.

Basic Understanding of REST APIs

Helpful for understanding request methods, parameters, and responses.

Internet Connectivity

Required to access the cloud environment, run integrations, and view logs.

Optional: API Testing Tool

Tools such as Postman or cURL for additional testing outside the OIC tester console.

The first step begins on the main Integrations Dashboard within the Oracle Integration Cloud (OIC) platform. This is the central workspace where users create, manage, and monitor all integration flows. The interface shown in this step provides a clear overview of existing integrations as well as the tools needed to start building a new one.

On the left-hand side of the screen, the Design section is highlighted. This section is dedicated to development activities, including building integrations, configuring connections, managing lookups, working with libraries, assembling packages, and administering agents. By selecting Integrations from the menu, the system opens the area where all existing flows are displayed and where new integrations can be initiated.

The main panel in the center displays the header Integrations, confirming that the user is inside the correct development module. Just below the header, you can see a count indicating how many integrations currently exist in the environment. These integrations are listed in a structured table format with columns such as Name, Version, Style, Last Updated, and Status. This table provides a comprehensive overview of the integration landscape and helps developers quickly assess which flows are active, which ones are new, and which ones may require updates or troubleshooting.

Each integration listed typically includes its version number, showing how many updates or iterations it has undergone. The Style column indicates whether the integration is application-triggered, schedule-based, or event-driven. Application-based integrations are activated by external events or connections, while scheduled integrations run automatically based on predefined time intervals. The Status column indicates whether each integration is currently active, inactive, or under development. An “Active” label means the integration is deployed and functioning, whereas other statuses may indicate that it is disabled, paused, or awaiting deployment.

At the top-right corner of this dashboard, two important buttons are visible: Create and Import. These options are crucial for starting new development activities. The Create button, specifically highlighted in this step, is the main action that allows users to initiate the creation of a brand-new integration. Clicking this button opens a configuration window where users can choose the integration style they want to build—such as Application, Scheduled, or other available patterns depending on what the environment supports. This choice determines how the integration will be triggered and how it will behave during execution.

Next to the Create button is the Import option. This feature allows developers to upload integration archive files exported from other environments. It is commonly used during migration processes, such as moving integrations from development to testing or production environments. Importing ensures that integration flows remain consistent across various stages of deployment.

The dashboard also displays utility icons such as Refresh, List View, and Grid View. The Refresh option updates the screen to show the latest status of all integrations, ensuring developers always see the most current data. The List and Grid view options allow users to switch between different display formats, depending on preference and the number of integrations present.

This entire screen functions as the command center for integration lifecycle management. From here, users can open existing integrations, deactivate or activate them, view details, analyze triggering patterns, or examine logs and tracing information. It simplifies the administrative workload by consolidating everything into one clear, organized view.

Step 1 focuses specifically on recognizing the layout of this dashboard and understanding its purpose. Before creating any new integration, it’s essential to know where everything is located and what tools are available. By identifying the Create button, the user prepares to move forward with building a custom integration that will automate business processes, transfer data between applications, or orchestrate workflows.

In Step 2, the user has clicked the Create button, which opens the Create Integration panel on the right side of the screen. This panel is where the foundational details of the new integration are defined. These initial fields are extremely important because they determine how the integration will be identified, managed, versioned, and organized throughout its lifecycle.

At the top of the panel, the system displays the type of integration being created. In most cases, this will either be an Application integration or a Scheduled integration, depending on what the user selected in the previous step. An Application integration typically responds to triggers such as REST calls, events, or application requests. A Scheduled one runs at predefined intervals. In this step, the user is working on an Application-style integration.

Right below the integration type, Oracle provides a recommendation: to group integrations using projects for better manageability and observability. This is a best practice, especially when multiple integrations belong to the same functional module or business process. While creating a project is optional at this stage, following this structure helps organizations categorize and track their automation components.

The first field displayed in the panel is the Name field. This is where the user provides a descriptive title for the new integration they are about to build. The name must follow certain rules—only letters, numbers, spaces, and specific allowed characters can be used. Additionally, the name must begin with a letter and cannot exceed a certain character limit. This ensures that naming conventions remain consistent across the environment, which is essential for maintaining clarity when managing dozens or hundreds of flows.

Under the Name field, the Identifier is automatically generated by Oracle Integration Cloud. The identifier is a system-defined value based on the integration's name. While the name is user-friendly and readable, the identifier is used internally by OIC for tracking, referencing, deployments, and export activities. It typically transforms the name into uppercase, removes spaces, and replaces them with underscores. Users can modify it if needed, but many choose to keep the system-generated version unless they have strict organizational naming requirements.

Just below the identifier, the next field is Version. Versioning is one of the most crucial aspects of integration development. The version number (commonly in a format like 01.00.0000) helps track updates and iterations as the integration evolves. Every time changes are made, developers can either revise the current version or create a new one, depending on their deployment strategy. Good version control ensures smooth migration between development, test, and production environments. At this initial stage, the system assigns a default version number, and the user can choose to accept it or update it as needed.

Following the version field is the section for Documentation URL. This field is optional but highly beneficial for teams working in collaborative or large-scale environments. Developers can provide a link to external documentation—such as a functional design document, process flow, Confluence page, or a requirements document. This helps other team members quickly understand the purpose and functional behavior of the integration without searching through multiple systems. Adding documentation improves long-term maintainability and provides context for future enhancements.

Throughout the panel, the design remains clean and structured, helping the user focus solely on supplying accurate details. Once all fields are filled out correctly, the user can proceed by clicking the Create button located at the bottom-right corner of the panel. There is also a Cancel button that allows the user to exit the creation process without saving anything.

This step is foundational because it establishes the identity of the integration. The name, identifier, and version form the basis for all future development. They influence how the integration appears in the dashboard, how it's exported or imported, and how logs and monitoring information are organized. Selecting accurate and consistent values at this stage saves substantial time during later maintenance, troubleshooting, and team collaboration.

In summary, Step 2 focuses on filling out the core details required to initialize a new integration within Oracle Integration Cloud. The user provides a meaningful name, verifies or updates the system-generated identifier, confirms the initial version number, and optionally includes a documentation link. Once these details are confirmed, the integration is ready to be created, leading to the designer canvas where triggers, actions, mappings, and orchestrations will be built in the next steps.

the integration has been successfully created, and the system now opens the Integration Designer Canvas. This is the primary workspace where the logic of the integration flow will be built. Everything that happens in the integration—from the trigger activity to the orchestration steps, actions, data mappings, and endpoints—is configured on this canvas. Understanding this layout is crucial before adding any components.

At the top of the screen, the title bar displays the integration’s name and version, followed by its current state. At this stage, it is shown as a Draft with Unsaved changes, indicating that the integration has been created but nothing has been configured yet. This is normal because every newly created integration begins in draft mode, giving developers a clean slate to design the process.

Below the title bar, the toolbar provides a set of essential controls. These include options to cut, copy, paste, undo, and redo changes. There are also zoom controls and icons that allow switching between different layout views. These toolbar options help developers work efficiently, especially when the integration becomes more complex. Having quick access to commands like zoom in, zoom out, or fit-to-screen ensures the flow is visually manageable.

The central area of the screen displays the canvas, which is currently empty except for a default Start node positioned vertically above an End node. These two nodes represent the beginning and end points of the integration flow. Every integration must start with a trigger—this could be a REST adapter, SOAP adapter, scheduled configuration, or an event-based trigger. When the integration type is an Application-style integration, the trigger is mandatory and must be configured at the Start node.

The Start icon is shown with a plus symbol, indicating where the developer can click to add the trigger connection. This is the first and most important step in designing the integration because the trigger determines how the integration will receive input and how it will be executed. For example, if a REST trigger is chosen, the integration will begin when a REST API call is made. If a scheduled trigger is selected, it will run based on predefined timing intervals. Therefore, choosing the correct trigger adapter is essential for aligning the integration with business requirements.

Directly beneath the Start node is the End node, representing where the integration will terminate. The dotted line between them indicates that no actions or logic have been added yet. As the flow develops, various actions—such as invokes, assign activities, switch branches, JavaScript functions, map actions, or integration calls—will fill the space between Start and End. Each action moves the data, transforms it, or interacts with external systems.

On the upper-right side of the canvas, the Save button is prominently displayed. This button is important because the integration designer does not autosave by default. Developers must manually save the changes they make. Regular saving prevents accidental loss of work and ensures the integration moves from Draft status to a usable state.

Next to the Save button is the Share dropdown. This option allows the integration to be shared with other users for collaboration. Sharing is especially useful in multi-developer environments where multiple team members work on different parts of the same integration or need to review the development progress.

To the far right, there is a collapsible panel that contains error notifications, validation messages, or system warnings. At the moment, no errors are displayed, which is expected because the integration is still empty. As soon as components are added—such as endpoints or mapping activities—this panel helps ensure that the design is structurally correct and free of configuration issues.

The left portion of the canvas also includes icons for switching views, enabling or disabling design gridlines, and controlling the alignment of elements. These features help keep the flow organized, especially when multiple branches or parallel actions are added.

This step is essential because it introduces the designer to the full development environment. Before adding any technical components, the developer needs to recognize where triggers will be placed, how actions will be arranged, how the layout behaves, and where to find important controls such as Save, Share, and validation messages.

In summary, Step 3 marks the beginning of the integration-building process. The designer opens with a clean Start-to-End layout, giving the developer full control over how the flow will be constructed. By understanding the canvas, toolbar, and navigation elements, the user is fully prepared to add triggers, define actions, apply logic, and transform data in the steps that follow.

In Step 4, the user begins the process of adding a REST trigger to the integration. This is a crucial stage because the REST adapter determines how external systems will initiate or interact with the integration. The moment the user clicks the plus (+) icon at the Start node, the system opens the REST Adapter configuration panel, which appears on the right side of the screen. This panel contains multiple guided steps that help define the behavior, structure, and technical specifications of the endpoint.

The REST configuration wizard is divided into sequential steps, represented at the top of the panel by numbered circles. Each circle corresponds to a particular configuration area—such as Basic Info, Resource Configuration, Request and Response structures, Headers, CORS options, and Summary details. In this stage, the wizard is currently positioned at Step 1: Basic Info, the foundational section where the user provides essential information about the endpoint.

At the very top, the REST adapter icon is displayed, indicating that this configuration specifically deals with RESTful communication. The UI shows navigation controls such as Cancel and Done, giving the user the ability to stop the configuration or proceed with the adapter setup once all steps are completed. While only Step 1 is active right now, the remaining steps will become accessible after the basic information is filled in.

The Basic Info section begins with a required field: “What do you want to call your endpoint?” This is where the user assigns a meaningful and descriptive name to the REST endpoint. The system provides an example format to guide users toward a good naming practice, usually following a verb-noun combination. The name should reflect the purpose of the service—for example, retrieving data, submitting information, updating a resource, or triggering a business action. This name becomes important for identification within the integration and may also form part of the auto-generated identifier.

Below the endpoint name field is the question: “What does this endpoint do?” This field invites the user to enter a description of the endpoint’s purpose. While it is optional, adding a detailed description is considered a best practice. It helps future developers, administrators, or support teams understand the functionality without reviewing the entire integration flow. The description should highlight what the REST endpoint is meant to accomplish, the type of data it handles, its expected behavior, and any relevant business context. This supports proper documentation and enhances long-term maintainability.

The panel itself is structured in a clean, intuitive way to guide users through the configuration process. All required fields are clearly marked, ensuring nothing essential is missed. The multi-step wizard keeps the user on track, preventing confusion and helping maintain clarity during configuration.

As the user works through this step, the main integration canvas is visible behind the panel. The Start node remains the focal point, indicating where the REST trigger will attach once configuration is complete. At this stage, no visual elements have been added to the flow, but after the REST adapter is fully configured, the canvas will update automatically to reflect the new trigger.

The Save button remains available at the top right of the main interface, but it's important to note that the REST configuration must be completed and validated before the integration can be saved successfully. If the configuration is incomplete, the system will highlight any errors or missing fields when attempting to move to the next step.

The presence of multiple numbered steps at the top of the wizard reflects the detailed nature of REST configuration within Oracle Integration Cloud. Each of these steps will allow the user to define request parameters, configure the resource URI, specify query or path parameters, set request and response payloads, and apply optional headers or CORS policies. However, all of this begins with Step 1—the foundation where the identity and purpose of the endpoint are established.

What makes Step 4 critical is that it sets the overall tone for how the REST request will be recognized and processed by the integration. The endpoint name and description influence readability, clarity, and usability. Clear, consistent naming also helps during testing, debugging, and monitoring once the integration goes live.

To summarize, Step 4 involves opening the REST Adapter wizard and entering the essential basic information required to define the REST endpoint. This includes assigning a clear, descriptive endpoint name and documenting its purpose. Completing this step correctly ensures the integration begins with a well-structured and understandable trigger, setting the stage for more advanced configuration in the steps that follow.

In Step 5, the REST Adapter configuration moves from basic endpoint details to the more detailed Resource Configuration phase. This is the second step within the REST configuration wizard and plays a critical role in determining how external clients interact with the REST service you are creating. The focus now shifts from defining the endpoint’s general purpose to specifying the actual operation, including its name, description, and resource path.

At the top of the configuration panel, the system highlights Step 2, marked as Resource Configuration. This step appears right after Basic Info and before parameters, request payloads, headers, and other advanced components. The numbered navigation bar at the top clearly shows the progression through the configuration steps, helping the user move systematically and avoid missing important sections.

The panel begins with the field “Provide an operation name”, which is mandatory. Oracle Integration Cloud assigns a default operation name initially, but users are expected to replace it with a more meaningful and descriptive name. This name reflects the action the operation performs—such as retrieving data, creating a resource, updating information, or processing a specific transaction. Choosing a meaningful operation name is important because it appears in the integration structure, logs, monitoring dashboards, and documentation. Over time, as integrations evolve or expand, clear naming practices ensure easy maintenance and faster troubleshooting.

Below the operation name, the wizard presents a field labeled “What does this operation do?” This description box helps document the functional purpose of the operation. Although not strictly required, it is considered a best practice to fill this section with a clear explanation. Developers, testers, or administrators reviewing the integration later will appreciate having immediate context about what the operation is intended to accomplish. This description could include details such as the business scenario supported, the type of data expected, and any critical information the operation processes.

Further down is one of the most important fields in the REST configuration: “What is the endpoint’s relative resource URI?” This is a required field, indicated by the asterisk symbol. The relative resource URI defines the precise path that external systems will use to access this REST operation. It must follow RESTful design principles and can include static text as well as dynamic path parameters.

For example, resource paths may resemble standard REST patterns such as /items, /employees/details, or /orders/{orderId}. The inclusion of dynamic segments—enclosed in curly braces—enables clients to pass values directly through the URI. This flexibility allows integrations to handle personalized or context-specific requests, such as retrieving details for a specific identifier. The system even displays a guiding example beneath the field (e.g., /orders/{order-id}/items/{item-id}), helping users understand correct formatting.

Choosing the right URI structure is essential because it becomes part of the API interface exposed to calling applications. It also determines how easily the endpoint can be understood, reused, and integrated with external systems. Good URI design contributes to clean API architecture and improves technical communication across teams.

The overall layout of this panel continues to follow the wizard’s consistent, user-friendly structure. All fields are arranged neatly, with clear labels and supporting tooltips for additional guidance. At this stage, the Cancel and Done buttons remain at the top, although Done cannot be selected until all required fields in all wizard steps are completed. When moving to the next step, the user typically clicks the arrow or simply progresses through the numbered circles at the top.

Behind the configuration panel, the integration canvas remains visible, showing the Start and End nodes. Although no changes appear on the canvas yet, the operation being defined here forms the foundation of the trigger that will eventually be attached to the Start node. Once all REST configuration steps are completed, the canvas will reflect the fully configured REST trigger, including its name and structure.

Resource configuration is a vital step because it defines the operational behavior of your REST API. Naming conventions, descriptive details, and URI structure together form the outward-facing contract of the integration. A well-configured operation ensures that API consumers understand how to call the endpoint and what information to expect. It also sets a clear path for configuring request parameters, payloads, response elements, and backend connections in the upcoming steps.

In summary, Step 5 involves defining the operation name, clearly stating the operation’s purpose, and specifying the relative URI path for the REST service. This step lays the structural foundation for how external systems will interact with the integration, making it one of the most important stages in REST adapter configuration.

In Step 6, the REST Adapter configuration proceeds to the next crucial phase: Request Parameters. This section is essential when designing REST APIs because it determines what input values external systems can send when invoking the integration. Properly defining request parameters ensures that the integration receives the correct data, validates inputs, and behaves in a predictable and structured manner.

At the top of the REST configuration panel, the wizard highlights Step 3, labeled Request Parameters. This visual cue confirms that the configuration has moved past the basic information and resource setup stages and is now focused on handling input specifications. The numbered navigation bar at the top continues to guide the user through each step of the REST configuration process.

The upper part of the panel provides a quick summary of the operation that is being configured. It displays the Operation Name, the Resource URI, and the HTTP Method. These details help orient the user and ensure that the correct operation is being edited. In this scenario, the HTTP method displayed is GET, which is typical for operations designed to retrieve data without requiring a request payload. GET operations often rely heavily on URI parameters because they do not support body content in the request. Therefore, defining request parameters is especially important in GET-based APIs.

This section titled Request Parameters gives developers the ability to configure different types of input elements that can be passed to the REST endpoint. These parameters usually fall into categories such as:

1. Path Parameters

These are dynamic segments embedded directly within the URI. For example, /users/{userId} requires callers to provide a value for the userId parameter. Path parameters are commonly used when the operation is intended to fetch or process specific items based on identifiers.

2. Query Parameters

These are appended to the URI as key-value pairs, such as /employees?department=Finance. Query parameters are optional in many cases and are useful for filtering, searching, sorting, or narrowing down retrieved data.

3. Template or Custom Parameters

These can include any additional values the integration may need to process the incoming request logic.

In this step, the UI does not yet show the detailed parameter-creation fields because the panel is likely showing an overview of existing configurations and preparing users to add parameters. The summary in the panel ensures the user understands what part of the operation they are working on before defining the structure of the parameters.

The purpose of this step is to allow developers to define the input needed for this specific operation. Depending on the use case, request parameters may include identifiers, codes, filter values, or operational keys. A well-structured request parameter design helps to ensure the API call is meaningful, organized, and easily understood by external consumers.

Configuring parameters also plays a significant role in backend logic. For example:

1. If the integration uses a parameter as a key to fetch data from another system, that parameter must be clearly defined.
2. If the logic requires optional filters, query parameters should be set up accordingly.
3. If different flows must be triggered based on incoming values, parameters can be used in switch branches or conditional checks inside the integration.

Additionally, defining parameters properly helps with documentation and testing. API clients such as Postman, SOAP UI, or custom applications rely on the parameter definitions to structure requests correctly. Any missing or incorrectly defined parameter can lead to API call failures or incomplete data retrieval.

The interface in this step also includes two main controls: Cancel and Done. While Cancel allows users to exit without saving current changes, Done remains disabled until all necessary configuration details in the upcoming steps are completed. This ensures that users cannot accidentally create an incomplete or invalid REST trigger.

Behind the configuration panel, the integration designer canvas continues to show the Start and End nodes, reminding the user that this operation will eventually serve as the trigger point of the integration. Once the REST configuration is completed across all steps, the canvas will visually represent the newly added REST trigger, making the integration ready for downstream actions such as invocations, mappings, and business logic.

In summary, Step 6 involves reviewing and defining the request parameters essential for the REST operation. This configuration ensures that the integration receives well-structured input from external systems and performs its functions based on the provided parameters. Proper parameter setup is the backbone of any REST API interaction, especially when using GET methods where input is transmitted through the URL. Completing this step prepares the integration for more advanced configuration phases such as request headers, response structure design, and payload definitions that follow in the next steps.

In Step 7, the REST Adapter configuration reaches its final stage, known as the Summary section. This step consolidates all the details previously entered throughout the REST configuration wizard and presents them in a single, unified view. The purpose of this final stage is to give the developer a clear opportunity to review, validate, and confirm every configuration choice before the REST trigger is officially added to the integration canvas.

At the top of the panel, the wizard highlights Step 10, labeled Summary. This shows that the configuration has progressed through all earlier stages, including Basic Info, Resource Configuration, Request Parameters, Request Headers, Response Settings, CORS options, and Operation-Level Customizations. Each of these previous steps contributed essential elements to the structure and behavior of the REST endpoint. Now, Step 7 ensures all those pieces are accurate and aligned with the intended design.

The Summary panel begins with a high-level textual overview of the REST trigger. This summary typically includes:

1. The endpoint name
2. The general description
3. The configured operation name
4. The relative resource URI
5. The HTTP method selected during Resource Configuration
6. Any request parameters or headers previously defined
7. Settings related to inbound and outbound message handling

This consolidated overview acts as a checkpoint where the developer can ensure that the REST API interface is correctly structured before proceeding.

Below the high-level summary, there is an expandable section titled Endpoint Summary. When expanded, this section displays even more detailed information, including internal configuration items such as:

1. Request parameter structures
2. URI parameter definitions
3. Associated headers
4. Response formats
5. Media types and content handling rules
6. Any optional configurations applied

This deeper layer of information helps developers confirm that the endpoint has been configured according to functional and technical requirements.

The purpose of reviewing the summary is not only to validate correctness, but also to ensure completeness. REST configuration involves numerous interdependent settings, and any omissions—such as missing parameters or incorrect HTTP methods—may lead to runtime failures. By reviewing the summary in one place, developers can catch mistakes early, long before they impact downstream logic or external consumers.

In the upper-right section of the panel, two familiar buttons appear: Cancel and Done. The Cancel option allows the user to abandon the configuration process and return to the main canvas without saving. This option is helpful if the developer realizes that the REST configuration needs to be redesigned from scratch.

The more important button, however, is Done. Clicking Done finalizes the REST Adapter configuration and attaches the newly configured REST trigger to the Start node of the integration. This is the moment when the configured endpoint becomes a functional part of the integration flow. After clicking Done, the integration canvas will update to show the REST trigger as the first component in the flow. This visual representation confirms that the integration is ready for downstream processes such as invoking other systems, applying data transformations, or adding conditional logic.

During the Summary stage, the integration designer in the background remains unchanged, displaying the Start and End nodes. This reinforces the idea that the REST trigger being configured is the starting point of the integration. Once the trigger is applied, the Start node will transform into a labeled REST entry point, making it clear how the integration will be triggered.

The Summary step also marks a significant point in the development process. Once the REST trigger is attached, the integration transitions from a conceptual design into a functional flow that can accept incoming REST calls. The developer gains the flexibility to enrich the integration with additional components—such as database adapters, application connectors, transformations, or branching logic.

Step 7 ensures that the REST trigger is configured accurately and ready for use. By presenting a clear summary of all configuration details, this step helps prevent common mistakes and improves both reliability and maintainability. With the REST trigger finalized and added to the integration, the groundwork is laid for the next stages of development, where the logic and actions that the integration must perform will be created.

In summary, Step 7 involves reviewing all REST configuration details through the Summary page, verifying all inputs, and finalizing the setup by clicking Done. This step confirms the REST trigger is properly configured and prepares the integration for building the rest of the flow.

In Step 8, the integration canvas now visibly reflects the successful completion of the REST Adapter configuration. Once the REST trigger is finalized in the previous step by clicking Done, Oracle Integration Cloud automatically adds the configured REST endpoint as the starting point of the integration. This marks a major milestone because the integration now has a functional trigger that external systems can call.

At the top of the canvas, the integration remains in Draft mode with unsaved changes, indicating that new components have been added but not yet committed. It is good practice to save frequently, especially after major configuration steps like adding a trigger.

The canvas now displays a labeled Trigger activity at the top of the integration flow. This block represents the REST endpoint that was configured during Steps 4 to 7. The icon to the left of the trigger label indicates that the trigger is a REST-based endpoint. This visual cue helps developers quickly recognize the integration’s starting mechanism when revisiting the flow later.

Directly beneath the trigger, a new element appears: a Map action. This mapping action is automatically inserted by Oracle Integration Cloud. Its purpose is to connect the output of the REST trigger to the next component in the flow, even if the output currently contains minimal or no data. The system generates this automatically because REST triggers typically expect some form of response structure, even if the response is simple.

This default mapping placeholder ensures that the integration remains structurally valid. Without it, there would be an immediate gap between the REST trigger and the end point of the flow, which could result in configuration errors or incomplete responses. By inserting this Map step, the platform gives the integration a foundation to start building transformation logic or routing data later.

The Map activity shown in the canvas includes a label that reflects the name of the trigger operation. This indicates that the mapping is specifically tied to the trigger. As the integration evolves, this map may be modified or replaced with more complex logic to transform input data, enrich responses, or pass values to downstream systems.

Below the Map action, a circular icon appears, indicating the End of the integration. This is the same End node that existed from the beginning, but now it is part of a connected flow. The vertical alignment shows that the flow consists of three stages:

1. The REST trigger at the top
2. The automatically inserted Map action in the middle
3. The End element at the bottom

This is the simplest possible REST-based integration structure. As development proceeds, additional actions—such as invoke connections, branching logic, assignments, lookups, or parallel flows—will be inserted between the trigger and the end point.

The right-hand side of the screen shows the vertical control bar containing various design-time tools such as:

1. Warnings and Errors panel
2. Mapping tools
3. Properties panel
4. Other configuration shortcuts

These tools help developers monitor issues, adjust component properties, and configure more advanced options as the integration expands. For now, the flow is simple, so no warnings are displayed except for potential reminders to save or validate the integration.

The Save button remains available in the upper-right corner, and since unsaved changes are present, it is recommended to save the progress at this stage. Saving ensures that the newly added REST trigger and mapping step are securely stored before additional logic is built.

This step demonstrates a key aspect of Oracle Integration Cloud: its ability to automatically structure foundational components and maintain the integrity of the integration design. Even before any complex business logic is added, the platform ensures that the flow has all required structural parts.

Understanding Step 8 is important because it marks the transition from configuration to design. Up until now, development was focused on setting up the trigger. From this point onward, the focus shifts to building the internal logic of the integration—adding invokes, creating mappings, processing data, applying conditions, and defining responses.

In summary, Step 8 shows the integration canvas after the REST trigger has been configured and added to the flow. Oracle Integration Cloud automatically inserts a default Map action to maintain structural soundness, connecting the trigger to the end node. This prepares the integration for additional components and allows developers to begin constructing the logic that will execute when the REST endpoint is called.

In Step 9, the integration design continues to evolve with the addition of an Assign activity placed between the REST Trigger and the Map action. This step represents a common pattern in Oracle Integration Cloud (OIC) where developers need to initialize variables, prepare values, or perform simple data operations before moving into mappings or invoking external systems. The presence of the Assign step indicates that the integration is transitioning from purely structural configuration to functional logic development.

On the canvas, the Assign activity now appears directly below the REST Trigger. This component is visually distinct, featuring an icon typically associated with assignments or expression evaluation. Its position in the flow indicates that as soon as the REST request is received through the trigger, the Assign step will execute immediately to manipulate or generate values needed later in the process.

Assign activities play a crucial role in OIC integrations. They enable developers to define temporary variables, compute values, create concatenated strings, generate flags, or set default outputs before continuing with downstream steps. For example, an Assign activity can calculate timestamps, derive values from input parameters, initialize counters, or prepare response structures. These actions help structure the integration’s logic in a clear, systematic way, ensuring the downstream Map or Invoke activities get the data they need.

The addition of this Assign activity likely occurred when the user clicked the + icon between the Trigger and the Map step, choosing Assign from the list of available actions. Once selected, OIC automatically inserts the Assign block into the flow at the correct position. The activity is labeled automatically with a name that follows the platform’s default naming conventions, but developers can rename it later to reflect its purpose more accurately.

On the right-hand side of the screen, the OIC design toolbox remains visible, offering various tools for validations, properties, and additional configuration. Once the Assign activity is selected, the properties panel would normally allow the developer to configure expressions or assign values. Although this part is not shown in the screenshot, it is implied that the Assign block is ready to be configured. The designer can now define operations such as:

1. Assigning literal values
2. Setting dynamic values retrieved from the REST request
3. Building new variables
4. Creating expressions using functions
5. Preparing data structures for the response

These assignments form the foundation for what the integration will eventually output or use later in the flow.

The Map action is still visible right below the Assign activity, indicating that the system continues to maintain the structural integrity of the integration. In earlier steps, the Map had automatically been placed to connect the Trigger output to the End node. Now, with the Assign inserted, the Map step will later handle the final transformation of the processed data into the response structure that the REST endpoint returns.

This flow—Trigger → Assign → Map → End—is a common and efficient pattern in OIC REST-based integrations. It helps maintain clarity and ensures each part of the process has a clear function:

1. Trigger
2. Receives incoming requests and exposes the integration to external consumers.
3. Assign
4. Initializes or manipulates data needed for transformation or business logic.
5. Map
6. Converts data into the output structure expected by the caller.
7. End
8. Completes the integration and returns the response.

At the top of the screen, the integration remains in Draft status with unsaved changes, which is expected because the Assign activity has just been added. The Save button appears prominently, reminding the developer to commit the work. Frequent saving is essential, especially as more components are added and configured.

The Share, Insight View, and Validation icons continue to be available on the upper-right side, offering additional tools to refine or analyze the integration. At this stage, validation would typically detect no errors, as the flow is structurally correct but not yet functionally complete.

Overall, Step 9 marks an important stage where the integration begins to incorporate logic rather than configuration alone. The Assign step ensures that the integration has a mechanism to handle data manipulation and internal preparation before sending results back or performing more complex actions. This prepares the integration for further development in later steps, where data transformation, business rules, or system invocations may be added.

In summary, Step 9 involves inserting an Assign activity into the integration flow to initialize or compute values needed for subsequent processes. This step strengthens the integration by providing a space to prepare data before mapping it into the final response, ensuring the flow remains logical, modular, and easy to maintain.

In Step 10, the integration design introduces one of the most essential diagnostic tools in Oracle Integration Cloud: the Logger action. This component is used to generate runtime messages that help developers understand the behavior of the integration, verify data values, troubleshoot issues, and monitor execution patterns. Logging becomes especially important when integrations involve dynamic values, conditional logic, or external system calls—making this step a key part of building a reliable and observable integration.

On the canvas, the Logger activity appears directly below the previously added Assign action. This placement ensures that whatever values were computed or initialized in the Assign step can now be captured and displayed in the activity stream during runtime. The Logger is represented by an icon that symbolizes audit or system logging, and it is automatically named according to OIC’s default naming convention. Developers can rename it later for clarity, especially when multiple loggers exist within a complex integration.

Once the Logger activity is selected on the canvas, the right side of the screen expands to show the Logger Configuration Panel. This panel provides all the options needed to build a log message that will be written to the activity stream or diagnostic logs.

At the top of the panel, the header displays the name of the Logger currently being edited. Below that, a description clarifies the purpose of the Logger action. It explains that the Logger can be used to output static text, dynamic variable values, or combined messages created through expressions. This flexibility allows developers to customize logs based on exactly what they need to track.

The first important configuration option is the Log setting. This section provides two choices:

1. Always

When selected, the Logger message will be written during every execution of the integration, regardless of the tracing level. This is often used for critical logs or when debugging functional behavior.

2. When tracing level is set to Audit

This option restricts logging only when the integration’s tracing mode is set to a more detailed audit level. This is helpful in production environments where unnecessary logging may be minimized to improve performance or reduce noise in monitoring systems.

Developers can choose either option depending on their debugging and monitoring needs. For development or testing stages, “Always” is usually selected.

Below the logging option is the most important input field of this step: the Logger Message box. This field allows the user to define the exact message that will appear in the runtime logs. The message can be:

1. A simple static string
2. A dynamic value pulled from a variable
3. A combination of text and variable references
4. A computed expression using functions

This message becomes the key indicator of what the integration is doing at this point in the flow.

To build the log message, the platform provides two tabs above the message area:

Input Sources

This tab lists all variables and values available at that point in the integration. These may include:

1. Query parameters from the REST trigger
2. Values initialized in the Assign activity
3. Internal tracking variables
4. Temporary flow variables
5. Execution metadata

Developers can simply drag and drop any variable into the Log message field, ensuring accurate and dynamic logging.

Functions

This tab allows the use of built-in functions for formatting, string manipulation, numerical operations, or other enhancements. This makes the logger capable of expressing computed or formatted values rather than raw data.

By using these tools, developers can craft meaningful messages such as:

1. “Received parameter value: X”
2. “Calculated total: Y”
3. “Assign step completed successfully”
4. “Flow execution reached Logger checkpoint”

These messages become extremely helpful when reviewing instance-level audit logs, especially when troubleshooting errors or validating behavior.

On the left side of the screen, the canvas still displays the integration steps in sequential order: Trigger → Assign → Logger → Map → End. This verifies that the Logger is positioned correctly in the flow to capture runtime information after data is prepared but before final transformation.

The Save button remains available at the top-right corner, reminding developers that their new Logger configuration needs to be saved. Since logging is an important part of integration observability, saving these changes ensures that diagnostic messages will appear during test executions.

In summary, Step 10 is about enhancing the integration with a Logger action that captures valuable runtime information. This step empowers the developer to monitor the flow, trace variable values, understand execution behavior, and troubleshoot effectively. With the Logger properly configured, the integration becomes easier to observe, debug, and maintain—making it a critical component in the overall design process.

In Step 11, the integration flow visually reflects all the components that have been configured so far—starting from the REST trigger, followed by the Assign activity, the newly added Logger action, the mapping step, and finally the End node. This step is all about reviewing and understanding the structural progress of your integration before moving into further logic development or advanced configurations.

The canvas now displays a neatly aligned sequence of activities arranged horizontally. This horizontal layout is often used when developers zoom out or adjust the orientation for better visibility. The clearer layout allows you to see the complete flow from left to right, making it easier to understand how data moves through the integration.

Beginning from the left:

1. REST Trigger

The flow starts with the Trigger block, representing the REST endpoint configured in earlier steps. This is how external systems initiate the integration. Its position at the start ensures that incoming requests enter the flow correctly and pass execution to the next component.

2. Assign Activity

Directly next in the sequence is the Assign step. This activity handles any value initialization or variable computations that the integration may require early in the process. Assigning values at this stage helps prepare data for logging or for downstream transformations.

3. Logger Action

To the right of the Assign step is the Logger action that was configured in the previous step. Its addition marks an important point in the integration because the logger ensures the flow becomes observable and easier to debug. When the integration runs, the logger will write diagnostic messages to the activity stream. This can include variables assigned earlier, fixed messages, or dynamic expressions. Its placement immediately after the Assign step indicates that the message produced by the logger likely depends on values set or manipulated during the assignment stage.

The Logger block is highlighted, showing that it is currently selected on the canvas. When an activity is selected, developers can edit its configuration, modify the log message, or view input sources available at that point in the integration.

4. Mapping Action

Next in the sequence is the mapping step. This Map activity is responsible for transforming the processed or computed values into the structure required by the REST response. Even if the integration is simple and returns static or prefilled values, the Map step ensures that output data is correctly formatted and compliant with the REST endpoint contract.

The Map activity is wrapped in a dotted outline, indicating that it may still need to be configured or revisited for adjustments. Mapping steps often require modifications later once variables or additional data are added in the flow.

5. End of Integration

At the far right of the sequence is the End node. This indicates where the integration completes and returns the final output to the calling system. In a REST-based integration, this node represents the response being sent back to the caller. Placing the End node after the Map action ensures that the response is fully prepared before the integration terminates.

Why This Review Step Matters

Step 11 is significant because it allows you to validate the logical structure of your integration before moving deeper into functional logic. Reviewing the flow at this stage helps ensure that the sequence of activities follows a coherent order:

1. Trigger receives the request
2. Assign prepares data
3. Logger records information
4. Map transforms output
5. End returns response

This sequence reflects a clean, well-designed integration pattern commonly used in REST API setups.

Canvas Tools and Additional Options

On the right side of the screen, the familiar design icons remain visible:

1. The validation indicator helps detect configuration issues.
2. The properties panel allows reviewing details for any selected activity.
3. Navigation buttons allow zooming, panning, and adjusting the view.

The top-right corner shows the Save button, which is crucial at this stage. The integration is still marked as having unsaved changes, so committing the current state ensures that the flow is preserved before adding more features.

On the top-left toolbar, layout tools allow you to switch between vertical and horizontal canvas views or reorganize activity spacing for better visibility.

Summary of Step 11

Step 11 is about reviewing and confirming the updated structure of the integration after adding the Logger action. The complete visual sequence on the canvas now includes the Trigger, Assign step, Logger action, Map activity, and End node. This review ensures that all components are in the correct order, properly aligned, and ready for the next stage of integration development.

In Step 12, the integration designer displays an important validation message indicating that the integration is missing a required configuration: the Primary Business Identifier. This step highlights how Oracle Integration Cloud (OIC) actively assists developers by alerting them when essential tracking or audit configurations are incomplete. Understanding and addressing this requirement is crucial for making the integration fully functional, traceable, and ready for activation or testing.

On the right-hand side of the screen, the Insight View / Validation Panel is open. This panel displays all issues, categorized under three tabs:

1. All – lists all errors and warnings
2. Errors – shows only the blocking issues
3. Warnings – shows advisory notifications

In this screenshot, the Errors (1) tab is selected, indicating that there is one blocking error that must be resolved before the integration can be activated. The error message reads:

“Missing primary business identifier for tracking. Please define a primary identifier using the tracking option from the menu.”

This message appears when the integration does not have any tracking fields defined. Tracking fields are essential because they allow OIC to follow an integration instance through its lifecycle—capturing values that uniquely identify the transaction. These identifiers are used for:

1. Debugging
2. Monitoring
3. Audit views
4. Instance search and filtering
5. Operational insight

Without at least one primary tracking identifier, the integration cannot be activated because OIC cannot properly track individual messages or transactions flowing through it.

On the left side of the canvas, the integration displays the flow built so far: Trigger → Assign → Logger → Map → End. The flow appears structurally correct, and each block is connected properly. However, OIC will not allow this integration to proceed to activation until tracking is configured. This step is intentionally highlighted by the system to ensure best practices are followed.

The tracking configuration is not automatically applied because OIC cannot assume which input field or variable is the most meaningful for tracking. Developers must explicitly choose which value best represents the transaction or the incoming request.

What Is a Primary Business Identifier?

A Primary Business Identifier is a value that uniquely distinguishes one integration instance from another. Common examples include:

1. Order ID
2. Employee ID
3. Invoice Number
4. Transaction Code
5. Customer ID
6. Request reference numbers

In REST-based integrations, these identifiers often come from query parameters or path parameters supplied in the inbound request. Since the earlier steps involved setting request parameters, one of those values would typically be chosen as the tracking field.

How To Fix This Error

To configure a Primary Business Identifier, developers follow these steps:

1. Navigate to the top-right of the design canvas.
2. Click on the Tracking icon (usually represented by a tag or identifier symbol).
3. A panel opens showing all available request fields.
4. Select one field that can uniquely represent each instance.
5. Mark it as the Primary Tracking Field.
6. Save the integration to confirm the configuration.

Once this is done, the error disappears from the validation panel, allowing the integration to proceed to activation or further development.

Why This Step Matters

The tracking identifier plays a vital role in real-time system monitoring. When an integration executes, OIC stores logs, audit trails, and diagnostic information. With a valid tracking field:

1. Developers can search for specific transactions in the Monitoring dashboard.
2. Support teams can troubleshoot issues faster.
3. Business users gain visibility into functional processes.
4. Instance reports and dashboards become more meaningful.

Without tracking, every instance looks similar, making debugging extremely challenging.

Save Status and Workflow Visibility

At the top of the canvas, the integration continues to display a Draft status, and the Save button likely shows pending changes. Configuring the tracking field and saving afterward ensures the integration becomes fully compliant with OIC requirements.

The presence of the error at this stage is expected and is part of the standard OIC development workflow. It acts as a checkpoint, ensuring that before the integration grows more complex, critical foundational settings like tracking are not forgotten.

In Step 13, the integration proceeds to resolve the validation error identified earlier by configuring the Primary Business Identifier, a required component for runtime tracking within Oracle Integration Cloud (OIC). This step is crucial because OIC uses business identifiers to uniquely identify, monitor, and trace individual integration instances as they pass through various stages of execution. Without assigning at least one primary identifier, the integration cannot be activated or deployed.

On the right side of the screen, the Business Identifiers panel is open. This panel provides a structured interface where one primary and up to two secondary identifiers can be defined. The panel contains helpful instructions explaining how business identifiers enhance observability and tracking. These identifiers help both developers and support teams monitor transactions, especially when multiple instances execute concurrently.

The section titled Primary Business Identifiers is highlighted. This area contains an empty placeholder that reads:

“Drag and drop an element here for tracking.”

This placeholder indicates that OIC is waiting for a value to be assigned from the available input sources. Typically, primary tracking identifiers come from input payload fields, query parameters, or dynamic values that represent the business context of each transaction. In this integration, the input likely originates from REST query parameters defined earlier.

To the left of the panel, the Input Sources menu is displayed. This section lists all available fields that the integration can access at this stage. It includes:

1. Query Parameters from the REST trigger
2. Connectivity or system metadata
3. Variables created earlier in the Assign action

Under QueryParameters, individual values such as P_Value1 and P_Value2 are visible. These are the input variables that were likely defined during the REST request configuration. Such values make ideal candidates for primary business identifiers because they often represent unique data supplied by the calling application.

To configure the identifier, the developer performs a simple drag-and-drop action:

1. Select an appropriate parameter from the Input Sources panel.
2. Drag the parameter into the Business identifier field box.
3. Drop the parameter into the placeholder.

This action binds the input parameter to the tracking variable that OIC generates automatically. Once dropped, the placeholder updates to show the mapped parameter, confirming that the identifier has been successfully linked.

Below the field mapping area, the panel displays two automatically populated fields:

Business identifier variable

This is a system-generated internal variable name that OIC creates to store the tracking value during runtime. The name often follows a structured pattern to differentiate it from other variables.

Business identifier name

This is a user-friendly label that appears in monitoring dashboards and audit logs. Developers can modify this name to reflect something meaningful, such as “CustomerID,” “RequestNumber,” or any descriptive identifier that represents the incoming transaction.

Having the correct business identifier configured provides several operational benefits:

1. Improved Traceability: Each instance of the integration can be searched using the identifier.
2. Better Debugging: Logs and audit trails can be filtered using the tracking value.
3. Clear Business Context: Support teams can correlate integration runs with real business transactions.
4. Simplified Monitoring: Dashboards become meaningful and easier to interpret.

Once the identifier is mapped, the validation error from Step 12 disappears from the Insight View panel. This confirms that the integration now complies with OIC’s tracking requirements and is ready for further development or activation.

On the main canvas, the integration remains in Draft mode, with the Logger, Map, Assign, and Trigger activities aligned horizontally. Even though no structural changes appear on the flow itself, the configuration performed in this step is critical to the backend behavior of the integration.

Before proceeding, the Save button should be used to preserve the changes. Failing to save may cause the mapping to revert, resulting in the tracking error reappearing upon validation.

In Step 14, the integration reaches an important milestone: activation. After configuring the trigger, mapping, logger, assignments, and business identifiers, the integration is now ready to be deployed so it can receive and process real runtime requests. Activation in Oracle Integration Cloud (OIC) enables the integration to become operational and accessible to external systems. This step is crucial because an integration remains in Draft mode until it is activated, meaning it cannot be invoked or tested through runtime endpoints.

The screenshot shows the Integrations dashboard, listing all available integrations along with their version numbers, styles, and statuses. The integration created in earlier steps is now displayed with a New label, indicating that it has not yet been activated for the first time. When the user initiates the activation process, OIC opens an Activate Integration panel on the right-hand side of the screen.

This panel requires the developer to choose a Tracing Level before activation can proceed. Tracing level determines how much runtime information will be captured during execution. OIC offers three distinct tracing modes:

1. Production Mode

Production mode is the recommended tracing level once the integration is stable and moved into a live environment. This mode collects only essential execution information to ensure optimal system performance and to avoid capturing sensitive payload data. It minimizes overhead, reduces storage usage, and ensures user privacy. This is the ideal setting for integrations used in real, high-volume business processes.

2. Audit Mode

Audit tracing captures more detailed activity information than production mode. It logs key checkpoints, variable states, and payload movements without going into overly verbose detail. Audit mode is commonly used during the testing phase or when the integration is newly deployed to confirm behavior. It strikes a balance between visibility and performance, making it suitable for both pre-production and controlled production environments where monitoring is important.

3. Debug Mode (Not Recommended for Production)

Debug mode is the most detailed tracing option. When selected, OIC logs all payloads, all variable data, and all activity details, including loops with up to 1000 iterations. This level of visibility is extremely beneficial when diagnosing complex issues or validating new integrations. However, the system clearly warns against using debug mode in production for two reasons:

1. Performance: Debug mode increases system load because it stores large volumes of diagnostic data.
2. Security: It may log sensitive data, which should be avoided in production systems.

Developers typically choose debug mode only during development and initial testing, especially when verifying the behavior of new logic, transformations, or information flows.

In the screenshot, the debug option is currently selected. This is appropriate for testing scenarios because it ensures maximum visibility into the integration’s execution, logger outputs, request parameters, and system variables. The panel also displays a caution message explaining the consequences of selecting debug mode.

At the bottom of the panel, two buttons appear: Cancel and Activate. Clicking Activate finalizes the activation process. Once activated:

1. The integration’s status changes from New to Active.
2. Its endpoint URL becomes available for invocation.
3. Developers can test the integration using REST tools like Postman or the built-in tester.
4. Runtime instances begin appearing in the Monitoring dashboard.

Activation marks the moment when the integration transitions from a designed workflow into a functional, callable service.

The Integrations dashboard in the background shows the complete list of integrations, confirming their versions and styles (Application or Scheduled). This overview helps developers quickly identify which integrations are active and ready, and which remain in draft or inactive states.

Before finalizing activation, it is important to ensure that:

1. All required configuration elements are completed.
2. The flow has been validated with no errors.
3. The business identifier has been properly set (completed in Step 13).
4. The tracing level matches the intended usage environment.

Once these conditions are satisfied, activation becomes smooth and error-free.

In Step 15, the integration has now been activated and is ready for testing. Oracle Integration Cloud provides a built-in testing interface that allows developers to manually run the integration, supply input values, and observe the response without needing external tools like Postman or cURL. This step focuses on how to configure and submit request parameters to validate the end-to-end behavior of the integration.

At the top of the screen, the interface displays the selected integration along with its version, confirming that the activated version is now available for invocation. The Configure and Run panel opens, presenting a clean and structured testing environment.

1. Endpoint URL Display

The top portion of the testing panel shows the complete GET endpoint URL. This includes:

1. The base API path
2. The integration identifier
3. The version number
4. The specific resource URI configured earlier
5. The defined query parameters

The system automatically appends parameter placeholders such as ?P_Value1=&P_Value2= to the URL. This confirms that the REST configuration earlier was successful and that the integration expects these parameters during execution.

Developers can copy this endpoint for external testing later, but for now, the built-in tester continues to simplify the process.

2. Request Section

Below the endpoint, the Request section contains multiple tabs:

1. URI parameters (visible by default)
2. Headers
3. Body
4. cURL
5. Integration properties

Since this integration uses the GET method and was defined with two query parameters, the URI parameters tab is the most important here.

The URI parameters panel displays two input fields:

1. P_Value1
2. P_Value2

Each parameter is accompanied by a checkbox, indicating whether it should be included in the request. These checkboxes are selected by default, meaning both parameters will be sent when the integration runs.

The developer can now enter test values into these fields. These values will be passed into the integration and will:

1. Influence the Assign activity
2. Be captured by the Logger
3. Flow into the final output mapping
4. Serve as the Business Identifier for runtime tracking

This makes parameter testing essential for validating the logic built earlier.

3. Testing Flexibility Through Additional Tabs

Although the integration primarily uses URI parameters, other tabs provide additional insights:

Headers

This tab allows adding custom headers if the integration requires authorization, correlation IDs, or content-type specifications. For this simple GET request, no additional headers are needed.

Body

For GET integrations, this tab remains disabled since GET operations do not accept a payload body.

cURL

This tab is extremely useful for developers or automation teams. It generates a ready-to-use cURL command that can be executed in terminals or integrated into testing scripts. It reflects the exact request being prepared, including parameter values.

Integration Properties

If the integration uses variables configured as properties, this tab allows modifying them before execution.

4. Response Preview Section

Below the request tabs, there is a Response placeholder section. Before running the integration, this area remains empty. After execution, it will display:

1. The response body returned by the integration
2. HTTP status codes
3. Execution time
4. Any headers included in the response

This gives the developer immediate feedback on whether the integration is functioning correctly.

5. Executing the Test

In the upper-right corner, the Run button initiates the test. When clicked:

1. The integration is invoked using the provided parameter values.
2. The Logger action records runtime information.
3. The Assign activity processes input values.
4. The Map activity prepares the output structure.
5. The response appears instantly in the Response panel.

Meanwhile, the instance is logged in the monitoring dashboard, allowing deeper inspection of logs and audit trails.

Next to the Run button, two helpful buttons are available:

1. Endpoint Metadata – shows details about the integration’s REST contract.
2. Track Instances – opens the monitoring view filtered to this specific integration.

These tools help validate technical behavior and track operational performance.