Show answer and explanation
Correct answer: A, B, D
As an Appian Lead Developer, designing a complex integration to a RESTful API for updating a case in
a legacy system requires a structured approach to ensure reliability, performance, and alignment
with business needs. The integration involves sending a JSON payload (implied by the context) and
handling responses, so the focus is on technical and functional prerequisites. Let’s evaluate each
option:
A . Define the HTTP method that the integration will use:
This is a primary prerequisite. RESTful APIs use HTTP methods (e.g., POST, PUT, GET) to define the
operation—here, updating a case likely requires PUT or POST. Appian’s Connected System and
Integration objects require specifying the method to configure the HTTP request correctly.
Understanding the API’s method ensures the integration aligns with its design, making this essential
for design. Appian’s documentation emphasizes choosing the correct HTTP method as a foundational
step.
B . Understand the content of the expected body, including each field type and their limits:
This is also critical. The JSON payload for updating a case includes fields (e.g., text, dates, numbers),
and the API expects a specific structure with field types (e.g., string, integer) and limits (e.g., max
length, size constraints). In Appian, the Integration object requires a dictionary or CDT to construct
the body, and mismatches (e.g., wrong types, exceeding limits) cause errors (e.g., 400 Bad Request). Appian’s best practices mandate understanding the API schema to ensure data compatibility, making
this a key prerequisite.
C . Understand whether this integration will be used in an interface or in a process model:
While knowing the context (interface vs. process model) is useful for design (e.g., synchronous vs.
asynchronous calls), it’s not a prerequisite for the integration itself—it’s a usage consideration.
Appian supports integrations in both contexts, and the integration’s design (e.g., HTTP method,
body) remains the same. This is secondary to technical API details, so it’s not among the top three
prerequisites.
D . Understand the different error codes managed by the API and the process of error handling in
Appian:
This is essential. RESTful APIs return HTTP status codes (e.g., 200 OK, 400 Bad Request, 500 Internal
Server Error), and the customer’s API likely documents these for failure scenarios (e.g., invalid data,
server issues). Appian’s Integration objects can handle errors via error mappings or process models,
and understanding these codes ensures robust error handling (e.g., retry logic, user notifications).
Appian’s documentation stresses error handling as a core design element for reliable integrations,
making this a primary prerequisite.
E . Understand the business rules to be applied to ensure the business logic of the data:
While business rules (e.g., validating case data before sending) are important for the overall
application, they aren’t a prerequisite for designing the integration itself—they’re part of the
application logic (e.g., process model or interface). The integration focuses on technical interaction
with the API, not business validation, which can be handled separately in Appian. This is a secondary
concern, not a core design requirement for the integration.
Conclusion: The three prerequisites are A (define the HTTP method), B (understand the body content
and limits), and D (understand error codes and handling). These ensure the integration is technically
sound, compatible with the API, and resilient to errors—critical for a complex RESTful API integration
in Appian.
Reference:
Appian Documentation: "Designing REST Integrations" (HTTP Methods, Request Body, Error
Handling).
Appian Lead Developer Certification: Integration Module (Prerequisites for Complex Integrations).
Appian Best Practices: "Building Reliable API Integrations" (Payload and Error Management).
To design a complex Appian integration to call a RESTful API, you need to have some prerequisites,
such as:
Define the HTTP method that the integration will use. The HTTP method is the action that the
integration will perform on the API, such as GET, POST, PUT, PATCH, or DELETE. The HTTP method
determines how the data will be sent and received by the API, and what kind of response will be
expected.
Understand the content of the expected body, including each field type and their limits. The body is
the data that the integration will send to the API, or receive from the API, depending on the HTTP
method. The body can be in different formats, such as JSON, XML, or form data. You need to
understand how to structure the body according to the API specification, and what kind of data types
and values are allowed for each field.
Understand the different error codes managed by the API and the process of error handling in
Appian. The error codes are the status codes that indicate whether the API request was successful or
not, and what kind of problem occurred if not. The error codes can range from 200 (OK) to 500
(Internal Server Error), and each code has a different meaning and implication. You need to
understand how to handle different error codes in Appian, and how to display meaningful messages erations
for implementing it.
Understand whether this integration will be used in an interface or in a process model. This is not a
prerequisite, but rather a decision that you need to make based on your application requirements
and design. You can use an integration either in an interface or in a process model, depending on
where you need to call the API and how you want to handle the response. For example, if you need
to update a case in real-time based on user input, you may want to use an integration in an interface.
If you need to update a case periodically based on a schedule or an event, you may want to use an
integration in a process model.
Understand the business rules to be applied to ensure the business logic of the data. This is not a
prerequisite, but rather a part of your application logic that you need to implement after designing
the integration. You need to apply business rules to validate, transform, or enrich the data that you
send or receive from the API, according to your business requirements and logic. For example, you
may need to check if the case status is valid before updating it in the legacy system, or you may need
to add some additional information to the case data before displaying it in Appian.