|
1 | 1 | # Pardot Java API Client 2.x.x to 3.0.0 Migration Guide |
2 | 2 |
|
3 | | -## Authentication & Configuration Breaking Changes |
| 3 | +## Breaking Change : Authentication & Configuration |
4 | 4 |
|
5 | 5 | In order to properly support the transition of the Pardot API from authenticating using Pardot username, password, and user keys, to |
6 | 6 | Salesforce Single Signon, several breaking changes were made to how you configure the Pardot API Client. |
@@ -48,4 +48,97 @@ final ConfigurationBuilder configuration = Configuration.newBuilder() |
48 | 48 | final PardotClient client = new PardotClient(configuration); |
49 | 49 | ``` |
50 | 50 |
|
51 | | -See [Offical Pardot Developer Documentation](https://developer.pardot.com/kb/authentication/) and [Salesforce OAuth Setup](https://help.salesforce.com/articleView?id=remoteaccess_oauth_flows.htm) for details on how to obtain the above required properties. |
| 51 | +See [Offical Pardot Developer Documentation](https://developer.pardot.com/kb/authentication/) and [Salesforce OAuth Setup](https://help.salesforce.com/articleView?id=remoteaccess_oauth_flows.htm) for details on how to obtain the above required properties. |
| 52 | + |
| 53 | +## Breaking Change : Read request methods now return Optionals |
| 54 | + |
| 55 | +Previously methods on `PardotClient` for reading objects (such as `PardotClient.readProspect()`, `PardotClient.readCampaign()`, etc...) |
| 56 | +either returned the object you wished to retrieve, or threw an `InvalidRequestException` if the API returned a response stating that the record |
| 57 | +could not be found. |
| 58 | + |
| 59 | +This often led to code like: |
| 60 | +```java |
| 61 | +// Try to lookup prospect by Email. |
| 62 | +Prospect myProspect = null; |
| 63 | +try { |
| 64 | + myProspect = client.prospectRead(new ProspectReadRequest() |
| 65 | + .selectByEmail( "[email protected]") |
| 66 | + ); |
| 67 | +} catch (final InvalidRequestException exception) { |
| 68 | + // Prospect could not be found. Swallow exception. |
| 69 | +} |
| 70 | + |
| 71 | +// Handle prospect if found |
| 72 | +if (myProspect != null) { |
| 73 | + ... |
| 74 | +} |
| 75 | +``` |
| 76 | + |
| 77 | +These methods now return `Optional<T>`,which means you no longer need to catch and handle `InvalidRequestException` |
| 78 | +when an object is unable to be found in the API. The above example code can be simplified to: |
| 79 | + |
| 80 | +```java |
| 81 | +// Check if the Optional is present |
| 82 | +final Optional<Prospect> prospectResponse = client.prospectRead(new ProspectReadRequest() |
| 83 | + .selectByEmail( "[email protected]") |
| 84 | +); |
| 85 | +if (prospectResponse.isPresent()) { |
| 86 | + final Prospect myProspect = prospectResponse.get() |
| 87 | +} |
| 88 | + |
| 89 | +// Or even better by using the methods available on Optional |
| 90 | +client.prospectRead(new ProspectReadRequest() |
| 91 | + .selectByEmail( '[email protected]') |
| 92 | +).ifPresent((prospect) -> { |
| 93 | + // Make use of prospect if found |
| 94 | + logger.info("Found prospect: {}", prospect.getEmail()); |
| 95 | +}); |
| 96 | +``` |
| 97 | + |
| 98 | +## Breaking Change : Delete request methods no longer return boolean |
| 99 | + |
| 100 | +Previously methods on `PardotClient` for deleting objects (such as `PardotClient.deleteProspect()`, `PardotClient.deleteCampaign()`, etc...) |
| 101 | +always returned a value of `true` regardless if the delete request was successful or not. Version 3.0.0 changes the return type for these methods |
| 102 | +to a type of `Result<Boolean>`. The [Result](src/main/java/com/darksci/pardot/api/response/Result.java) object |
| 103 | +allows for returning a successful response (value of boolean `true`) as well as an [ErrorResponse](src/main/java/com/darksci/pardot/api/response/ErrorResponse.java) |
| 104 | +instance if the request was not successful. |
| 105 | + |
| 106 | +The quick way to simply migrate your code: |
| 107 | + |
| 108 | +```java |
| 109 | +// Code that looked like the following: |
| 110 | +final boolean result = client.userDelete(deleteRequest); |
| 111 | +// or |
| 112 | +if (client.userDelete(deleteRequest)) { |
| 113 | + |
| 114 | +// Now should look like: |
| 115 | +final boolean result = client.userDelete(deleteRequest).isSuccess(); |
| 116 | +// or |
| 117 | +if (client.userDelete(deleteRequest.isSuccess())) { |
| 118 | +``` |
| 119 | + |
| 120 | +But this new return type also gives you additional flexibility to handle errors more gracefully: |
| 121 | +```java |
| 122 | +// Handle success conditions: |
| 123 | +client |
| 124 | + .userDelete(deleteRequest) |
| 125 | + .ifSuccess((success) -> logger.info("Successfully deleted user!")); |
| 126 | + |
| 127 | +// Handle error conditions: |
| 128 | +client |
| 129 | + .userDelete(deleteRequest) |
| 130 | + .ifError((error -> logger.info("Failed to delete user: {}", error.getMessage()))); |
| 131 | + |
| 132 | +// Or handle both cases: |
| 133 | +client |
| 134 | + .userDelete(deleteRequest) |
| 135 | + .handle( |
| 136 | + (success) -> { |
| 137 | + logger.info("Successfully deleted user!"); |
| 138 | + return true; |
| 139 | + }, |
| 140 | + (error) -> { |
| 141 | + logger.info("Error deleting user: {}", error.getMessage()); |
| 142 | + return false; |
| 143 | + }); |
| 144 | +``` |
0 commit comments