Technical documentation - Order process http APIs
This article describes the http APIs available to support the order process. It gives an overview of existing providers, and log tracing of API calls.
Http providers require add on module for integration.
API and provider overview
The follwing APIs exist to support the order process.
API | In params | Response | Provider name |
|---|---|---|---|
GetPrice | Authentication information A list of part numbers | Price and currency for each part. NLA code for each part. Replacement information for each part. Result codes (message and error on each part) | <PriceProvider> |
GetAvailability | Authentication information A list of part numbers | List of availabilities for each part (if several warehouses) Result codes (message and error on each part) | <AvailabilityProvider> |
GetAddresses | Authentication information | List of addresses List of order types Temporary address permission (optional) Result code (message and error on each address) | <AddressProvider> |
AddToOrderCart | Authentication information A list of part numbers | Order line results Result codes | <AddToOrderCartProvider> |
PlaceOrder / ValidateOrder | Authentication information Order (header and order lines) | Order (updated if needed with NLA and replacements) Result codes (message on order, error on order, message on order line, error on order lines) | <PlaceOrderProvider> <ValidateOrderProvider> (version 5.0) |
GetOrderTypes | Authentication information | List of Order Types | <PlaceOrderProvider> <ValidateOrderProvider> (version 5.0) |
GetDeliveryOptions | Authentication information Order (header and order lines) | List of Delivery Options valid for the order | <PlaceOrderProvider> <ValidateOrderProvider> (version 5.0) |
GetOrders | Authentication information | Orders, one line per order Result codes | <OrderHistoryProvider> |
GetOrderDetails | Authentication information Order number | Order header, order lines, shipment lines Result codes | <OrderDetailProvider> |
Signin | ReturnUrl | Success or failure status | <AutenticateProvider> |
Authenticate | SesssionId | User record; name, id, permissions etc. | <AutenticateProvider> |
PlaceOrder / ValidateOrder
API calling process
There is an active order in web viewer stored in an order object
Order object is sent in PlaceOrder / ValidateOrder call
If call is successful, PlaceOrder / ValidateOrder call returns an order object. This returned object is used to update the active order.
Prices on order lines in active order is updated
Total price and charges on the active order is updated
Parts may be marked as NLA or a replacement may be returned and active order is updated based on this
Messages on order or order lines are set on the active order
Error code on order lines or on order is set on active order. If an error code exist the corresponding message will display in red and it will not be possible to place the order
Result is presented
For ValidateOrder call user stays on the order page and gets to see the active order
For PlaceOrder call user is either
directed to a confirmation page if PlaceOrder call accepted the order
stays on the order page and gets to see the active order if PlaceOrder call did not accept the order
Validation
Order is validated when parts are added and when user arrives at order. The validation can be turned off using a setting.
<RESTPlaceOrderProvider order-validation-required="false" save-external-order-to-server-database="false" delete-old-trace-log-after-number-of-folder="30" trace-folder="C:\Temp\Trace-logs\" url="http://5.179.112.210/IntegrationWebAPI/"/> Providers
Providers for integrations are normally custom built for each integration and params needed for each custom provider will vary. Typically a custom provider is configured according to the below pattern in profile.config:
<PriceProvider>
<CustomPriceProvider impersonation="true" domain="localhost" user-name="xyz" password="zyx" />
</PriceProvider>End point for the APIs are normally set up in web.config. Example:
<system.serviceModel>
<bindings>
<basicHttpBinding>
<binding name="PostCustomPlaceOrderServiceSoapBinding" maxReceivedMessageSize="20000000" maxBufferSize="20000000" maxBufferPoolSize="20000000">
<readerQuotas maxDepth="32" maxArrayLength="200000000" maxStringContentLength="200000000" />
<security mode="TransportCredentialOnly">
<transport clientCredentialType="Windows" />
</security>
</binding>
</basicHttpBinding>
</bindings>
<client>
<endpoint address="http://www.domain.com/WebServices/CustomOrderService/post" binding="basicHttpBinding" bindingConfiguration="PostCustomPlaceOrderServiceSoapBinding" contract="CustomPlaceOrderService.CustomOrderServicePostPort" name="CustomOrderServicePost" />
</client>
</system.serviceModel>Tracing
See separate article: Log archive (API logs)
Authentication in API calls
API calls may be protected by http basic authentication or api-keys (version 5.2.3 and later) and all REST providers support this security method.
Basic
ApiKey
This option is available from version 5.2.3 and later.
Login / Authenticate
User starts in back end system and navigates to Signifikant, where the Url will contain a session-id to identify the user to the back end system when an order later on is placed,
Signifikant calls the backend system to authenticate the user, and to get the user record with name, permissions etc.
Or the user starts in Signifikant where the backend system is called with sign-in request. When it returns with a signed in user and a session-id, Signifikant makes an authenticate call as above.
Use tracing files for first error search of APIs. See related article Error search order API for more information.