Glen Mazza's Weblog

I've found in rare instances that access token requests to Marketing Cloud fail with a MC-side 500 system error with little extra detail provided. In such cases the ETClient in the FuelSDK would throw a generic EtSdkException for the client to handle. Our logging has shown that a second access token request immediately thereafter would usually be successful.

To make it easier for FuelSDK clients to trap and recover from this specific error, in my FuelSDK fork I created a new ETTokenRequestException, subclassed from the current ETSdkException, that the ETClient now instead throws. Subclassing from the current exception maintains backwards compatibility for current clients of the library while allowing them to update as they wish.

For my FuelSDK fork I found another component that would benefit from updating, namely the Partner API WSDL defining the SOAP requests and responses, used by Apache CXF to generate Java classes representing those objects. The main Salesforce branch is still relying on a copy of the WSDL downloaded in 2017. A comparison of the two WSDLs is showing quite a few new and modified request and response objects since then:

ClientID: CustomerID
TaskResult: TblAsyncID
SaveOption: TrackChanges
AccountUser: IsSendable
APIObject: __AdditionalEmailAttribute 1-5.
Attribute: no longer inheriting APIObject
SubscriberResult: ErrorCodeID
TriggeredSendClassEnum
TriggeredSendSubClassEnum
SenderProfile: FallbackFromAddress
deleted: MessagingConfiguration
ChatMessagingEventType
SalesforceSendActivity
ImportDefinition: HasMultipleFiles
ImportResultsSummary: NumberRestricted
JsonWebKey
DirectoryTenant
AuditLogUserContext
AutomationActivity: SerializedObject
AttributeEntityV1
Thumbnail
NameIdReference
CategorynameIdReference
UserBasicsEntity
AssetAnyProperty
Asset
Category
ScheduledRequest
ScheduledConversation

I did need to make two adjustments to the WSDL copied into my fork, as detailed on the project README and commented in the WSDL. For one of them--a mismatch between what the WSDL claims the SOAP response will be for a particular call and what it actually is, causing a validation exception with CXF--I've sent a help ticket to Marketing Cloud requesting they update their WSDL. This particular issue has been around a long time, apparently, as even the 2017 WSDL needed this manual adjustment.