I'm using Docusign's apex toolkit to generate an envelope within my sfdc instance.
I need to initially create the envelop as draft, so I'm using the dfsle.EnvelopeService.sendEnvelope with the sendNow flag on false.
Executing this call creates the envelope as draft on Docusign, but I'm also expecting a record from dfsle.Envelope.Status custom object to be automatically created, so I can track envelope status, and this record is not created.
I've tested that if I sendEnvelope with the sendNow flag on true, then the status record is created.
Also tried creating the status record manually on my sfdc instance using the envelope docusignId, but the record is not updated if I send the envelope from outside sfdc.
Does anyone know if this is the expected behavior?
According to the design of the application the status record is created immediately only if send now is true during the send envelope call.
However, you can use dfsle.StatusService for dynamically fetching the status of an envelope as well updating it back to salesforce automatically.
Please use the explanation provided in step 5 in the following link
https://developers.docusign.com/salesforce/code-examples/salesforce-sending-signing-template
Related
This is sort of an extension of this question here. I have a policy that calls a REST API. The API returns an error message and this message needs to be localized.
One way is to of course get the API to return a localized message, but is there a way for the CustomPolicy itself to localize the error code? According to the CustomPolicy Docs, a REST API can send an error code along with the Conflict error code. Our thinking was to use this error code as a key and select a localized message (from the messageValue enum mentioned in the answer in the link).
However, we can't seem to capture/handle the error data returned by the API. The Policy seems to handle error codes by itself and we would like to know if it is possible to inject localized exception/error messages from the policy itself.
Thanks in advance!
Edit: A little more information about the setup. We have a TechnicalProfile that has a DisplayWidget and a ValidationTechnicalProfile. The DisplayWidget is used for entering & verifying the user's phone/email and the ValidationTechnicalProfile makes the final call to the RestAPI with all the user's information to register him/her. This RestAPI call output is what we want to localize.
The suggestion in the linked SO question, from what I understand, is that we integrate another DisplayClaim (that references an enum) in the DisplayWidget, and depending on the ErrorCode returned by the call, change it to display the appropriate code. However, as per my understanding, this would also require editing the API to return only 200 along with a code. This code would indicate the true nature of the result - success or a code for one of the enums to be displayed.
Our aim therefore is to check if there is a way to follow the Policy's flow (disrupt the SignUp/SignIn process) but at the same time localize the API's displayed response.
We managed to find a workaround to this, so I'm posting this here for anyone else who might be interested in this.
Our restriction for localizations was the fact that used Phrase to manage our translations and wanted the CustomPolicy specific translations all in one place. Our CD workflow was as follows:
PolicyCommit -> Build Variable Replacement through PS -> Release Variable Replacement and localized strings replacement through PS & Policy Uploads
Barring the policy from localizing the APIs response, we had the following options to achieve this:
Sending the language to the API and having the API return the appropriate error message
in the appropriate language. We were reluctant to follow this because of a multitude of reasons, but mostly because we would also have to handle different regions, etc. in the API - something the policy does by itself.
We actually had only one API that we called, and also only two error messages that were used. Hence we created an enum with the two error messages that would be localized. We then used a chain of InputClaimsTransformations that did the following:
Repeat Steps 1 through 3 for all the errors
1. CreateStringClaim (Create ClaimTypes for each of the error codes, holding the index of the error code in the enum)
2. GetMappedValueFromLocalizedCollection (Make the localized enum choose and hold the value of the required error code)
3. AddItemToStringCollection (Add the localized error from the enum to a StringCollection)
4. GenerateJson (Add the error codes StringCollection to the JSON payload to be sent to the API)
This way, the policy performed the localization for all the errors and we sent them along with the request to the API. The API, when an error occurred, picked one of the error messages from the policy and sent it back. This method was for us, because of our CD structure and Phrase integration, much easier than actually having the translations in a file hosted on the cloud to be accessed by the API.
Hope this helps someone; I can also add code in case someone needs it :)
According to here: https://cloud.google.com/pubsub/docs/reference/rest/v1/PubsubMessage
The timestamp field should not be populated when a publisher sends a message to the queue. So this leads me to think PubSub attaches a timestamp automatically whenever it gets a message from a publisher.
Is this correct?
Yes, you got that correctly. This is what is implied with the following sentence (from the docs you linked):
publishTime: The time at which the message was published, populated by
the server when it receives the topics.publish call.
You can test that yourself: if you go to the Explorer's API and publish to a topic using the pubsub.projects.topics.publish method, without giving a publishTime and then you pull using a subscription from that same topic (pubsub.projects.subscriptions.pull), the pulled message will have a publishTime.
Now, there is also a sentence in the docs regarding publishTime which seems a bit unclear to me:
It must not be populated by the publisher in a topics.publish call.
If you actually try to add a (correctly formatted) publishTime in your publish call, you will not get an error. Still, the actual publishTime attached to the message that you later pull is the one provided by the pub/sub service (i.e. the publish time you gave will simply be ignored).
They do generate using the publishTime. However on cases where there are multiple publishers publishing to Pub-Sub, you could attach a timestamp to every event in the publisher.
https://cloud.google.com/pubsub/docs/ordering
From this official docusign support guide, I understood that we don't need to add Email or FirstName or LastName atrributes in CRL call when SigningGroup is used. My custom button url in salesforce is below.
/apex/dsfs__DocuSign_CreateEnvelope?DSEID=0&SourceID=a3G4C000000HE8X&
CRL=SigningGroup~LegalSigner;RoutingOrder~20;Role~Signer5
&OCO=Send
When I try to send a document, I get the following exception:
Error: System.CalloutException: Web service callout failed: WebService
returned a SOAP Fault: The email address for the recipient is invalid.
The recipient Id follows. faultcode=soap:Client
faultactor=https://demo.docusign.net/api/3.0/dsapi.asmx
The error says that the email address is invalid, because I did not pass one in the CRL parameter.
Anyone have an idea on what is wrong with my custom button url?
I talked to docusign professional service team today and guess what? We need to upgrade our docusign installed package version in the org. (upgraded from 6.3 to 6.7.2)
This document from docusign website says
Future updates will be downloaded and installed automatically.
Wondering why it never got upgraded automatically for us. While the error message is so mis-leading, please check your version package number before you start using any new functionality that is released. Lesson Learned.
I have an interface for updating pass. When I click 'update pass', I want to call pushnotification to the pass in device. I don't know how to do this. How to do this?
For Passbook, quite a few things have to be in place in order for a push to trigger a notification on a device. From your form, you will need to implement everything to follow this flow:
post the data from your form to your server and update the pass record(s) in your database
retrieve the device pushToken(s) for the device(s) that require the updated pass from your devices table (these should be linked to the pass table with a common key)
connect to the production APNS using the PassID certificate that matches the passTypeIdentifier of the changed pass
send an APNS message containing an empty payload for each device
wait a few seconds......
upon receiving the push, each device will contact your web service using the 'Getting the Serial Numbers for Passes Associated with a Device' method
your web service must respond with a json dictionary containing the serial(s) of the updated pass (note only send serials relevant to the device, if you send a serial of a pass that is not installed, you will receive error log messages)
when the device get's your response, it will call your service again with the 'Getting Latest Version of a Pass' for the serial you sent it.
dynamically build the new .pkpass bundle and send as a response with the correct MIME type and 'Last-Modified' header
providing that a field value has changed, and that field dictionary contains a changeMessage key, a notification will show on the device. If nothing has changed, or if no changeMessage is set, the above will still happen, the pass will update but you will not see a notification.
In the current version of Salesforce,
IF I have multiple Validation Rules Error message defined on one object
AND IF these rules are not respected when clicking on Save
THEN I get multiple error messages (all at once).
This is what I would like to have when using API calls.
As it is now, I am only getting error messages one by one via API calls. Is there any way to display all error messages at once, as it is in the Salesforce interface?
No, currently API processing stops at the first error and report thats, there's no way to have to report all the errors.