AWSAWS Certified Generative AI Developer - Professional2026-102.5 Implement application integration patterns and development tools
Separate document extraction from workflow acceptance
Completed by the knowledge check
Learning objective
Orchestrate document processing with Amazon Bedrock Data Automation and Step Functions
Core idea
Amazon Bedrock Data Automation (BDA) performs extraction and understanding; AWS Step Functions coordinates when processing starts, how its status is checked, and what happens to the result. Treat them as separate responsibilities. An accepted BDA invocation is not a completed document job, and a completed extraction is not proof that a business record is valid.
Design three explicit boundaries: input eligibility, extraction completion, and application acceptance. Each needs a concrete signal. File requirements determine eligibility, GetDataAutomationStatus.status reports processing state, and application checks decide whether the extracted fields can enter a downstream system.
Preserve the invocation identity throughout the workflow. A state machine that loses it and starts extraction again on every retry creates duplicate work and confusing output provenance. Keep large source documents and outputs in Amazon S3, and pass their references with the job identity through the orchestration states.
How it works
Choose the output contract before submission
BDA supports standard and custom outputs. Standard output returns commonly needed information based on the input type, such as document summaries. Custom output uses a blueprint that defines fields to extract. Projects organize standard output configuration and custom blueprints for the supported input types.
For a document-processing application, choose the result from the downstream task. A readable summary may serve a reviewer, but invoice posting needs explicit fields and validation rules. A custom blueprint describes the desired extraction; it does not establish that an extracted total matches the invoice lines or that a supplier is authorized.
Record the source identity and extraction configuration alongside every job. For example, an application record can identify the document revision, project, blueprint version, and output location. These are your provenance requirements, not an assertion that BDA automatically creates a complete business audit record. See 1.3.5 for the broader provenance pipeline.
Reject ineligible files before starting work
BDA’s asynchronous document requirements include PDF, TIFF, JPEG, PNG, and DOCX. The documented maximum file size is 500 MB for the asynchronous API, while the console has a 200 MB limit. The document page limit is 3,000 pages when the splitter is enabled; do not apply that qualifier-free to every document path.
The synchronous document path has different boundaries: 50 MB, 10 pages, and no splitter. It supports PDF, TIFF, JPEG, and PNG rather than the same full format set as the asynchronous path. A file admitted for asynchronous processing is therefore not automatically eligible for a synchronous request.
Other constraints can decide eligibility before orchestration. PDFs cannot be password protected. DOCX processing converts the document to PDF, so page-number mapping does not work for DOCX. If downstream evidence requires original page identity, that behavior changes the acceptable input contract even when the format is supported.
Validate these conditions at intake and report a specific rejection. Do not repeatedly retry an unsupported or protected document as if it were a temporary service failure.
Submit through a Step Functions SDK integration
Step Functions documents BDA Runtime under the SDK integration service name bedrockdataautomationruntime. Use a Task resource such as arn:aws:states:::aws-sdk:bedrockdataautomationruntime:invokeDataAutomationAsync. The service operation is InvokeDataAutomationAsync; the Task resource uses the SDK integration’s action naming convention.
The native BDA request includes inputConfiguration.s3Uri, outputConfiguration.s3Uri, the required dataAutomationProfileArn, and the selected project or blueprint configuration. Step Functions SDK integration parameters use PascalCase, even when the native service API uses camelCase. The corresponding workflow parameters include InputConfiguration, OutputConfiguration, DataAutomationProfileArn, and nested S3Uri.
Set a stable clientToken for the logical submission, expressed as ClientToken in the integration. AWS documents this token as the mechanism for avoiding duplicate calls. Reuse it when retrying the same submission; change the logical job identity when deliberately processing a different source or configuration. The token complements an application job record rather than replacing all downstream duplicate controls.
The submission returns invocationArn. Store that ARN before entering status checks. The successful Task means the request was accepted, not that extraction has finished. Do not invent a .sync suffix as a substitute for explicit BDA completion handling.
Step Functions cannot autogenerate IAM policies for SDK integrations. Configure the execution role’s required service permissions explicitly and verify the BDA invocation’s access to the referenced input and output resources. The workflow definition alone is not evidence that access is correctly provisioned.
Detect completion and classify outcomes
For event-driven completion, set notificationConfiguration.eventBridgeConfiguration.eventBridgeEnabled to true on InvokeDataAutomationAsync. Notifications provide an alternative to repeated status calls; polling keeps completion detection within one execution’s bounded Wait/Choice loop. Choose the detection path explicitly and preserve the invocation identity in either design.
Use arn:aws:states:::aws-sdk:bedrockdataautomationruntime:getDataAutomationStatus with InvocationArn. A Wait state separates bounded checks; a Choice state routes the returned status. Normalize the integration result into an application job record before routing. The BDA fields described here use native API names; verify the integration’s returned structure before writing result selectors or Choice expressions.
The documented states are Created, InProgress, Success, ServiceError, and ClientError. Continue waiting for the first two within the job deadline. For Success, retrieve the result through outputConfiguration.s3Uri. For the error states, retain errorType and errorMessage and route to an explicit failure or review outcome.
Distinguish an API call failing from a job returning an error status. A failed status-check request might warrant another bounded check of the same invocation. A successful check returning ClientError is data for a Choice decision, not automatically a Task exception caught by Catch. Retry policy and workflow control are covered in 2.1.5.
Choose a Standard workflow when the job needs durable orchestration beyond the short processing envelope. Standard supports executions up to one year, whereas Express supports up to five minutes. These are workflow maxima, not sensible polling budgets: apply a shorter task-specific deadline and terminal outcome.
Validate before publishing the business result
After BDA reports Success, validate the output against the application’s acceptance contract. Check required fields, business identifiers, and relationships such as totals. Keep extraction success distinct from accepted, rejected, or review-required business states.
Extraction success leads to validation, and only validation decides the business state.
Publish only the accepted result and retain a reference to its source and invocation. If a downstream write fails, recover that publication stage without automatically re-extracting the document. If a deadline expires, reconcile the stored invocation before creating a replacement. A workflow timeout does not prove that asynchronous extraction never completed.
Key distinctions and trade-offs
Standard output versus custom blueprint: A summary-oriented result and a field-oriented extraction serve different consumers. Neither automatically enforces business rules.
Submission versus completion: invocationArn identifies accepted processing. status: Success identifies completed extraction. Application validation controls publication.
Task error versus returned job error: SDK exceptions enter error handling; ClientError or ServiceError returned as status enters explicit state-machine routing.
Polling versus notifications: A bounded polling loop checks the identified job within the execution. EventBridge notifications avoid repeated status calls but need an event-handling path. Neither turns submission into completed extraction. A synchronous path is a separate option with stricter file and page limits.
Architecture / decision scenario
A finance application receives invoice PDFs and DOCX files. It chooses asynchronous BDA processing for its admitted workload and rejects protected PDFs. For DOCX, it records that original page mapping cannot be relied on, so reviewers use the source document identity rather than an invented original page reference.
A Standard Step Functions workflow submits the project and blueprint configuration with a stable ClientToken, stores invocationArn, and polls that invocation. Created and InProgress lead to bounded waits; ClientError ends the job with diagnostics; Success loads the S3 output for validation.
A validator checks supplier identity and invoice arithmetic. Discrepancies enter review, while accepted records proceed to the accounting adapter. A failed accounting write retries publication of the accepted record, not the original extraction. The job record connects the invoice revision, extraction invocation, review decision, and final write.
Common exam traps
- Treating
InvokeDataAutomationAsyncsuccess as a finished extraction. - Applying console limits to the API or synchronous limits to asynchronous processing.
- Omitting the splitter qualifier from the 3,000-page limit.
- Assuming DOCX preserves original page-number mapping.
- Inventing a BDA
.syncintegration or assuming IAM policies are autogenerated. - Using
Catchalone to handle returnedClientErrorstatus. - Re-extracting a document because a downstream business write failed.
What to remember
- Gate input eligibility before creating an invocation.
- Use the SDK integration’s service, action, and parameter conventions.
- Retain
invocationArnand retry the same logical submission with its token. - Route documented status values explicitly and bound the waits.
- Validate and publish separately from extraction completion.
Knowledge check
A team must extract fields from a 120-page, 40 MB PDF and proposes the synchronous BDA path because the file is under its 50 MB limit. Which conclusion is correct?
A Step Functions polling loop calls GetDataAutomationStatus. The call succeeds and returns status: ClientError, and the Catch on that Task never fires. What should the workflow do?
Retry on the Task so the status check repeats until SuccessClientToken and poll that invocationClientError precedes Success in the job lifecycleCatch and Retry never see it. Only Created and InProgress mean keep waiting; a Choice state routes ClientError to a failure or review path that retains errorType and errorMessage .The Task that calls InvokeDataAutomationAsync times out before a response arrives, and the workflow retries it. Which choice keeps the retry from starting a second extraction of the same document?
ClientToken on the retryClientToken for each retry.sync to the Task resource ARNclientToken as the way to avoid duplicate calls, so the same logical submission keeps its token across retries. A new token asks for a new job, and BDA has no .sync integration that would replace explicit completion tracking.BDA reports Success for an invoice extracted with a custom blueprint, but the extracted total disagrees with the sum of the line items. What should happen next?
ClientToken to extract it againSuccess means extraction finished, not that the fields are right. A blueprint describes what to extract; business rules such as invoice arithmetic are the application’s acceptance gate, and a discrepancy goes to review rather than downstream.An invoice passed validation, but the write to the accounting system times out. Which recovery keeps the workflow correct without duplicate work?
ClientToken and validate the new output