Glen Mazza's Weblog

https://glenmazza.net/blog/date/20230419 Wednesday April 19, 2023

FuelSDK-Java fork available

Updated April 2023.

At work we use a fork of Marketing Cloud's FuelSDK, generally for keeping its libraries up-to-date as Salesforce doesn't often do so for its main branch. The fork is using the latest CXF 3.5.x branch as of this writing. Other enhancements:

  • JDK 11 base, above the Java 6 in the main fork.

  • Gradle build, with help from Francisco Mateo's cxf-codegen-gradle plugin.

  • The Partner API WSDL has been updated. This file is used by CXF to generate Java classes supporting the SOAP requests and responses. 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 found necessary 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.

  • 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 the 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.

  • The FuelSDK's ETClient now has a close() method to explicitly release various CXF objects prior to making a new connection. While DataDog or another memory profiler can tell you whether that is actually necessary, I've found no harm in calling it.

The fork has been running fine on production for several months now, we're using it to register and update subscribers and send emails, and it is providing us peace of mind that we're using the latest libraries while doing so.

Posted by Glen Mazza in Marketing Cloud at 03:00AM Apr 19, 2023 | Comments[0]

Post a Comment:

Calendar
« March 2024
Sun Mon Tue Wed Thu Fri Sat
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
Today
About Me
Java Software Engineer
TightBlog project maintainer
Arlington, Virginia USA
glen.mazza at pm dot me
GitHub profile for Glen Mazza at Stack Overflow, Q&A for professional and enthusiast programmers
Blog Search


Blog article index
Navigation
About Blog
Blog software: TightBlog 4.0.0
Application Server: Tomcat
Database: MySQL
Hosted on: Linode
SSL Certificate: Let's Encrypt
Installation Instructions