A consumer references SAIF.Claims.Intake.Client, copies the ClaimIntakeBasic client endpoint into its own configuration file, constructs a ClaimIntakeGateway with that endpoint name, calls Submit or GetStatus, and disposes the gateway. The gateway wraps a svcutil-generated ClaimIntakeClient. It applies a 30-second send timeout, performs no retry, and is not safe for concurrent use.
Read from the <client><endpoint name="ClaimIntakeBasic"> element of the consuming application's configuration file, selected by the endpointConfigurationName constructor argument
Binding
Named binding configuration ClaimIntakeBasic
Credentials
Windows transport credential of the calling process, with an impersonation level of Identification
A class library's own app.config is not read at run time. The consuming application must copy the <client> and <bindings> sections into its own configuration file, which is also where each environment sets its address.
A consumer that needs retry must wrap each call in its own policy and create a new gateway for each attempt, because a faulted channel cannot be reused. A consumer that needs circuit breaking must provide it outside the package. A consumer that calls from several threads must construct one gateway per thread. The retry, circuit breaking, and thread safety findings are recorded in Tech debt.
// Submit a claim, then read its statususing(vargateway=newClaimIntakeGateway("ClaimIntakeBasic")){ClaimReceiptreceipt=gateway.Submit(submission);ClaimStatusResultstatus=gateway.GetStatus(receipt.ClaimNumber);}
// Handle a validation failuretry{gateway.Submit(submission);}catch(FaultException<ClaimValidationFault>ex){Assert.Equal("INJURY_DATE_FUTURE",ex.Detail.Code);}
Scenario
Operations used
Notes
Submit a claim and read its status
SubmitClaim, GetClaimStatus
Taken from tests/SAIF.Claims.Intake.Client.IntegrationTests/GatewayTests.cs:18
Handle a validation failure
SubmitClaim
Taken from tests/SAIF.Claims.Intake.Client.IntegrationTests/GatewayTests.cs:41
Note: Statements marked with † were retrieved from dependency library documentation
via the Legends CLI RAG service. They describe inherited behavior from the indicated
origin library and should be verified if the dependency version changes.