Kentico 10. When I make a rest request to post data to the kentico form module I get a successful http 201 back and I can see the data created in the kentico interface. This particular form I am posting data to has an autoresponder set up.
I have a default smtp server set up and can successfully email out through it, which leads me to believe that the autoresponder on the form does not get triggered when data is created in the kentico form via rest. I never see the autoresponder attempt to send an email in either the email queue module or the event viewer (with the proper web.config key set).
Is that the intended behavior, to not trigger the autoresponder when forms module data is created via a rest request? If so, any idea how to get it to trigger?
Yes you are correct. Kentico REST is meant to perform simple CRUD operations. Essentially what you doing is the same as if you do it inside the admin i.e. go inside admin -> forms -> your form name -> recorded data and add new record. It doesn't trigger anything like sending email or Redirect to URL etc.
What you can do if you want to send email using form global events and on insert send email yourself. Here is the example of using global events
Related
I am trying to figure out how to use multiple URLs in a Connect-Rest in Pega 7.3 to connect to DocuSign using the DocuSign Pega integration that is built by Pega.
I have a specific link that contains API keys that I am required to use as the resource path in my Connect-Rest. However, I also have another link that calls a specific instance of DocuSign so that the info from Pega goes directly to the DocuSign instance.
I know that Pega has updated their connect-rest functionality in the current version but my question is does anyone know if there is a way to incorporate multiple urls into one connect-rest.
Thank you in advance.
I don't know what you mean by "connect-rest."
DocuSign has the "Connect" feature for sending webhook notifications when an envelope's status changes. All envelope sent by selected (or all) users will be monitored. You can create multiple Connect subscriptions so that multiple URLs will be sent when an envelope's status changes.
DocuSign also has "individual envelope webhooks." This feature is configured when an envelope is created via the API and the create request includes the EventNotification attribute. A maximum of one URL can be set per envelope.
If you are invoking Connect-Rest from a pega activity, you can capture the relevant URL as variable and pass that to function call to 'Connect-Rest' within activity. Another useful way maybe to use dynamic system setting and use #(Pega-RULES:Utilities).getSystemSetting() function to read the value of URL saved in the Dynamic system settings
I want to know if this is possible: I would like to have a custom text field on an envelope that I set and if the envelope fails for some reason, like there are missing tabs or email address is bad, I want to be able to look at the exception and see the custom field that I set. Would this info be in the raw data? It is as important to us to know which envelopes failed as to know why they failed. I saved the custom field in a database before sending out the envelope. When it fails, I can look up that custom field and discover which envelope didn't make it and to take some action, like correcting and resending.
If the envelope is created incorrectly (i.e: specifying a conditional parent tab which does not exist, syntax error, etc), then you will know at the time you attempt to create the envelope w/the API. The reason will be included in an error code the API returns
If an envelope was sent to an email address which does not exist/bounces, that information can be discovered using the DS API to see a recipient/envelope status of 'autoresponded', or if you are using DS Connect you can receive a push notification.
Is there additional rationale why you want to use a custom field? Per the above, I do not believe it is necessary or applicable.
With the RestSharp api, I was able to get the Request body. The Request body has a collection of Parameters, and one of those items is the RequestBody.
I want to make sure I am on the right track as I have been having some problems getting started with the API. I am looking to maintain a list of product application PDFs as templates on docusign. When a customer comes to our site and wants a particular product they need to fill out an application form. All the data would be collected on our site. I would then want to:
Create an envolope with the customer (and potentially other parties) that need to sign the document
Fill in the form fields from data collected on our site
Send the envelope out for signature and monitor the progress.
So in doing this I am trying to build this up a piece at a time and first task is to make sure that I can provide form data to docusign. I create a template with the docusign web user interface and all of the form fields seem to be preserved. However when I try and retrieve the template with API
https://demo.docusign.net/restapi/v2/accounts/xxxx/templates/yyyy
I see a very short response with an envelopeTemplateDefinition showing the correct name for the template but no documents object and no custom fields object. I have also tried this by creating an envelope with the document (in draft) but with similar results.
My apologies in advance for this newbie question.
I've repro'd the issue you describe -- i.e., the Response I get from a GET Template request contains only very limited information and is thereby not consistent with the expected Response as documented on pages 194-196 of the DocuSign REST API guide (http://www.docusign.com/sites/default/files/REST_API_Guide_v2.pdf). Not sure if this is a bug with the GET Template operation or with the Documentation -- someone at DocuSign will need to confirm (#Ergin).
In light of this limitation with the GET Template operation, you can alternatively retrieve the recipient information (including tabs) and document information about a Template by using the GET Envelope Recipients and GET Envelope Documents operations -- just specify the TEMPLATE Id in place of the Envelope Id, as shown here:
GET https://{{env}}.docusign.net/restapi/{{version}}/accounts/{{acctId}}/envelopes/{templateId}/documents
GET https://{{env}}.docusign.net/restapi/{{version}}/accounts/{{acctId}}/envelopes/{templateId}/recipients?include_tabs=true
We have an alert set-up for sharepoint list, but I want to add some custom text to the alert email. We do not have any access to SPD or sharepoint server and can make changes to sharepoint client only.
Can anyone please advice?
The code that sends out emails runs on the SharePoint server via the Timer Job. Since you have no access to do anything with the server you've got absolutely no chance of modifying the built in alert emails.
Could you do this with javascript?
You can't send emails with JavaScript directly. You can open up a draft email in a users default email client using a mailto link but this won't achieve what you want as a user will still have to edit it.
You could, I suppose, put some javascript onto an edit page using a content editor web part (which you can do without SPD) to on changes make an AJAX call to a separate web server to do the actual sending.
This is a common problem that I find when programming a Lotus Notes App.
Use case: An employer fills out a request form in a Request database. A notification gets mailed to the person that may give them OK or REJECT for that request. The authority person visits the Request database and gives OK or REJECT.
Good. But, where would you save the approval status OK or REJECT:
Should the authority person have write access to the original request
and set the status directly (and may alter other data in the form)
Should the aproval action create a response doc to the original (and i cannot show in a view the current status)
Typically you are better off setting an approval status directly on the request. That may not seem initially ideal, but remember Lotus Notes isn't like a relational database where things would be more normalized.
Let's consider the alternative, putting a status in the response document. Now how do you show all the requests with their statuses? You'd probably have to write some code just to do that when with the first option you could just create a view.
You can control the access to the document using reader and writer access fields. See how the built in template does it (the approval workflow template). Essentially as the document changes state (i.e. New, Submitted for Approval, Approved or Denied, etc), you can also change the reader and writer access fields at that point.
Once, I designed a database that mailed that request to the approver with the form stored in the document. As long as the user accessed the document using a Notes client, they could click on a button in the message to approve, which would send a message back to the database with the field data to mark the request as approved. An agent in that request database was set to run when new mail arrived, read those messages and change status on the original requests. That way, the approver never had to leave their inbox and didn't even need rights to edit the request.
You could do it with URLs if the users would be approving via browser client - have the link to an agent and pass in the parameters.
Or, to go back to your scenario, once the requester has submitted the request, don't display the fields that you don't want changed, display the values as computed text instead.
Anyway you look at it, best to have the approval recorded on the original document.
For above, Everything is our concern. In SQL or any other RDMS, we are in need of normalize that. Similarly here we have view categorization, show response document in hierarchy, and a lot of great hide when functionality based on role, ACL, unique person and whatever you need. We can easily manipulate the data render depends on the current user.
For your Q:-
1. We can control the appropriate user[authority person] from editing the request form's item.
2. We can also do by the response document. There we can show the documents in view by using show the Response documents in hierarchy.