Typically when AppDirect sends a subscription event to an ISV, a response is expected. Subscription events are assumed to be synchronous (the response is received immediately) unless otherwise stated. However, when a business process requires a delayed response, AppDirect can support it with an asynchronous event.All subscription events that involve a response can also be supported as asynchronous (delayed response) events. For asynchronous events, AppDirect listens for the delayed response to arrive.
The SUBSCRIPTION_NOTICE event is the only subscription event that does not involve a response so it is only supported as a synchronous event.
The Asynchronous Flow
When AppDirect calls an ISV with a notification URL, they return a JSON or XML response, as well as an HTTP response code. Usually, this code is 200 (OK) or 201 (Created). Additionally, however, AppDirect will recognize an code of 202 (Accepted) as a mechanism for the ISV to tell AppDirect that the event has been received and is being processed, and the ISV will notify AppDirect upon completion. The ISV can make an HTTP POST to the /api/integration/v1/events/{eventUrl}/result endpoint to notify AppDirect of the result. The subscription or assignment will remain in a "pending" state (e.g., PENDING_USER_ACTIVATION, PENDING_REMOTE_CREATION, or PENDING_REMOTE_CANCELLATION) in the AppDirect marketplace until AppDirect is notified of the result. When a subscription or assignment is in the pending state, the user cannot act upon it.
A Scenario:
A Developer is facing the issue that when they send a SUBSCRIPTION_ORDER event which isn't actioned as expected by AppDirect. The order is created and made active. They were expecting that it would be pending and then upon a 200 success=true it would be made Active and had no AccountIdentifier.
AppDirect only requires an accountIdentifier in the response to a Subscription Order Event so we can know how to reference the new customer account in future Event Notifications.
Success Response to a Notification
{
"success": "true",
"accountIdentifier": "new-account-identifier"
}
Error Response to a Notification
{
"success": "false",
"errorCode": "ACCOUNT_NOT_FOUND",
"message": "The account TEST123 could not be found."
}
Investigation Steps:
Check in splunk for the EVENT_CALLBACK from the ISV, searching for the event token is the fastest way to find this information. You can find the event token in the event logs in the Marketplace. In particular look for the following tags,
[event.type=SUBSCRIPTION_ORDER]
[result.success=true]
[result.asynchronous=false]
[result.errorCode=null]
[result.message=]
[result.accountIdentifier=abc]
Here you can identify what type you are looking at and if it was successful. If it wasn't successful you would also see the error code and message with which you could reach out to the ISV to investigate. If it was successful you should see an AccountIdentifier. You can also observe if the event is Asynchronous or not. This is crucial in matching what behavior is expected when placing an order.
Clearly if the order is being activated when the ISV is expecting it to be pending their OK then the desired behavior should be [result.asynchronous=true]. If this is the case then this is pretty straight-forward on how it is set. Provied the following snippet to the Developer:
if (result != null) { result.setAsynchronous(response.getStatusCode() == HttpStatus.ACCEPTED); }