Pass Transform Query/Path/Header Parameter-Value by Mapping ?
Introduction
Passing, transforming, querying, or modifying parameter values within an SKYVVA app or an API can be crucial for data manipulation and effective communication between different components. This process is used to manipulate or pass values in various contexts, such as APIs, and data transformation pipelines, in our SKYVVA application integrations.
In the realm of APIs, passing parameters involves transmitting specific values or information to endpoints to trigger actions or retrieve data. These parameters can be in the form of query parameters, path parameters, or header parameters, each serving a distinct purpose:
- Query Parameters: These are key-value pairs appended to the URL of an API endpoint. They are used to filter, paginate, or modify the requested data by using our SKYVVA app.
- Path Parameters: These parameters are embedded within the URL path itself, typically used to identify specific resources or endpoints by using our SKYYVA app.
- Header Parameters: These are additional parameters sent within the header of an HTTP request. Headers contain metadata about the request or response, and they can be used to pass various information such as authentication tokens, content types, or custom data by using our SKYVVA app.
Mapping techniques allow for the manipulation or transformation of these parameters. This can involve:
- Parameter Passing: Establishing a direct link between input and output parameters, transmitting specific values from one SKYYVA app to another.
- Value Transformation: Modifying or transforming parameter values before passing them along. This might involve converting data types, as per the business requirement.
- Conditional Mapping: Defining rules or conditions for parameter handling based on certain criteria. For example, routing requests differently based on the values of specific parameters on the SKYYVA mapping tool.
Implementing parameter-value mapping involves tools, middleware, transforms, and forwards parameters between the SKYVVA app. This process enables efficient communication and interaction between different parts of the SKYVVA application ecosystem.
Case1: Passed direct Query/Path/Header value without Transform
Users need to pass header, path, and query parameter values from a request made using invokeCalloutV3() in the developer console to an adapter, and then have the adapter use these values to generate a response that mirrors the received request parameters back to an inbound (response) interface.
To accomplish this:
- Passing Parameters from Developer Console to Adapter:
Using invokeCalloutV3() in the developer console, the user sends an HTTP request to an endpoint handled by your adapter.
- This request will contain header parameters, path parameters, and query parameters.
- Adapter Logic:
Within the adapter, the user needs logic to capture and extract the received header, path, and query parameters from the incoming request.
- Store these parameters or their values appropriately for use in the response.
- Generating the Response:
Use the captured header, path, and query parameter values to construct the response payload.
- Create the response in a way that mirrors the received parameters back to the inbound interface.
- Sending the Response:
Return the generated response from the adapter back to the inbound interface.
- Ensure the response structure includes the header, path, and query parameters similar to those received in the request.
The proper error handling, validation, and transformation logic while using the parameters to ensure the integrity and security of the data by using the SKYVVA application.
Required step:
- Create Interface Request with Rest Template -> Message Type Request
[su_box title="Note" box_color="#FF0000" title_color="#000000"] In This case we don’t use outbound mapping.[/su_box]
- Setup Adapter Rest with dynamic Path, Query, and Header
That API is just for testing by forwarding requests as response back with Path, Query, and Header
- Create Interface Response with Rest Template -> Message Type Response
- Mapping Response API back
- Go to Interface Request link Adapter and Interface Response with interface.
- Go to Developer Console -> Open Execute Anonymous Window
[su_box title="Result:" box_color="#2a8af0" title_color="#000000"]
- Users can see the response from API when the request has been sent.
- The header containing “sender=SKYVVA_TEST”, the path containing “apiversion=v1”, the query containing “modification_date=Datetime.now().format('yyyy-MM-dd\'T\'HH:mm:ss.SSSZ')”.[/su_box]
After Execute Apex Code, we got the Debug Log
Message Monitoring API Response back
Case2: Passed Transform value through the mapping to Query/Path/Header at the adapter to invokeCalloutV3()
- The goal is to pass header, path, and query values retrieved from Query/Path/Header Parameters using invokeCalloutV3() in the developer console.
- These values will then be forwarded to a mapping process for transformation. Afterward, the transformed values will be sent to an adapter for a callout.
- The objective is to ensure that the response includes the transformed values obtained from the request header, path, and query, allowing verification of the accuracy of parameter transformation in our SKYVVA application inbound (response) interface.
Required step:
- Create Interface Request with Rest Template -> Message Type Request
- Mapping Interface Request
- Setup Adapter Rest with dynamic Path, Query, and Header
- Create Interface Response with Rest Template -> Message Type Response
- Mapping Response API back
- Go to Interface Request link Adapter and Interface Response with interface.
- Go to Developer Console -> Open Execute Anonymous Window
[su_box title="Result:" box_color="#2a8af0" title_color="#000000"]
- Users can see the response value transform from API when the request has been sent.
- The header containing “sender=SKYVVA_TEST_transformed”, the path containing “Code=200”, the query containing “modification_date=Datetime.now().format('yyyy-MM-dd\'T\'HH:mm:ss.SSSZ')__transformed”.[/su_box]
After Execute Apex Code, we got the Debug Log
Message Monitoring API Response back
Case3: Passed "__SKYVVA__LAST_RUN_DATE_TIME" from Scheduler to Query/Path/Header
- The case involves validating the transfer of Query/Path/Header values, specifically "__SKYVVA__LAST_RUN_DATE_TIME", from the request (outbound) to the response (inbound) through an interface executed scheduler into the Query/Path/Header parameters for the invokeCalloutV3() execution.
- The expected outcome is to extract the "__SKYVVA__LAST_RUN_DATE_TIME" value from the request and use it in the Query/Path/Header parameters to request an API via an interface executed scheduler. Subsequently, the response retrieved from this process will contain the last run date value, enabling a comparison with the originally passed value.
- This comparison aims to verify whether the value passed in the request aligns correctly with the SKYVVA application.
Required step:
- Create Interface Request with Rest Template -> Message Type Request
- Mapping Interface Request
- Setup Adapter Rest support Path parameter as Data Time
- Create Interface Response with Rest Template ->Message Type Response
- Mapping Response API back
Go to Interface Request link Adapter and Interface Response with interface.
- After linking the Adapter and Interface Response, go to Integration -> Scheduler -> Start Run Interface Execution Scheduler
- First Scheduler run
2. Seconds Scheduler run
- Message Monitoring
[su_box title="Note:" box_color="#2a8af0" title_color="#000000"]
- A request is generated where the last run value from the interface executed scheduler is passed into the path parameter. Subsequently, upon receiving this request, the SKYVVA app responds with the same value passed in the account name field to either create or modify the account.
- The scheduler execution involves using the last run value in the path parameter of the request.
- Processes this value in the account name field of the response within the SKYVVA app. This action creates a new account or modifies an existing one based on the received value.
[/su_box]
[su_box title="Note:" box_color="#FF0000" title_color="#000000"]
- Default Value for First Run:
The default value used during the initial run is set as 1800-01-01T00:00:00.000+0000. This value likely serves as a starting point when there's no previously recorded last run date.
- Setting Initial Value:
This initial value can be configured by adjusting the Interface Control Runtime, specifically related to the record type V3 Outbound Execution. This setup involves associating this record with the last run value to initialize the process.
- Passing _SKYVVA_LAST_RUN_DATE_TIME:
The scheduler is responsible for passing _SKYVVA_LAST_RUN_DATE_TIME as a parameter or value to the Query/Path/Header. This parameter represents or holds the last run date and is crucial for subsequent operations during the scheduler's execution.
[/su_box]
Summary
Now user learned how our SKYVVA application facilitates parameter-value transformation via mapping. Users pass query, path, and header data through interfaces, manipulating and transforming values for outbound calls. Scheduler executions manage last run dates, initiating requests with transformed parameters. These transformed values integrate into API calls through adapters. Responses contain transformed data, verifying correctness. SKYVVA app streamlines parameter handling, ensuring accurate data transmission and compatibility between systems.