RELATED IDEAS
Build API into Drawloop that can be called by using apex only
It would be good if Drawloop could have API’s that could be called directly via apex without needing tables (external or otherwise) or drawloop packages either.
So the API would just pass the id of the document template, and the data to be mapped to it, perhaps in a map or json structure where you could have a matchup like this:
"<>" : "Fred"
"<>" : "Smith"
etc
So that given an document template, the data to go on it and the field tags could be sent via the apex API without requiring involvement from a Salesforce object or needing to create a Drawloop package. Perhaps the API would allow creation of a dummy Drawloop Package etc so it can be used.
So the API would just pass the id of the document template, and the data to be mapped to it, perhaps in a map or json structure where you could have a matchup like this:
"<>" : "Fred"
"<>" : "Smith"
etc
So that given an document template, the data to go on it and the field tags could be sent via the apex API without requiring involvement from a Salesforce object or needing to create a Drawloop package. Perhaps the API would allow creation of a dummy Drawloop Package etc so it can be used.
-
ADMIN RESPONSESep 8, 2022This is an interesting suggestion! Can you tell us more about how you would use this?
So a scenario might be that there is data in a system external to Salesforce (which is where Drawloop is currently installed). In that system there is some data that the business would like to have merged with a word template using Drawloop to produce a PDF to be sent to a customer.
Currenlty to utilize Drawloop would require that the external systems data be sent to SF and stored in an object in SF, which might need a new custom object just to store that data so that the drawloop package can then reference it.
I was thinking that apart from creating a drawloop package, the external data might be sent to drawloop directly via a JSON payload perhaps where the payload would represent the data records to be processed and be of the pattern
{field_name_tag1 : data value1,
field_name_tag2 : data value2 } etc. Could also have arrays in there.
The document in the drawloop package would reference that data by using the tags <> and <> etc.
The drawloop package, instead of nominating a starting object might nominate 'JSON Payload'.
So when the inbound transaction comes in (probably a REST API call with a JSON payload), it invokes an Apex class and that class, amongst whatever else it may need to do will make a call out to Drawloop, perhaps in the form of something like this:
PageReference dDPPage = new PageReference(
'/apex/loop__looplus?sessionId=' + sessionID + '&autorun=true&ddpIds=' + DDP_Id_to_run + '&json1=' + jsonPayload1String + '&json2=' + jsonPayload2String
);
return dDPPage;
where the variable 'DDP_Id_to_run' holds the DDP id and the jsonPayload variables hold the record data to be merged into the documents. These payloads could be string or serialised json payloads.
Or perhaps by having the apex class construct & send an outbound message instead with similar parameters.
Simple relationships could still be handled, possibly, by having json variables be referenced, ie Json1.id etc.
Essentially, Nintex could construct an api that could receive all the data that a Drawloop package would normally access, but just receive it on a case by case basis as a transaction.
If the template document id was sent then maybe a Drawloop package would not be needed either as the document id would point to the doc to be merged with etc, for simple cases.
This would just allow a more dynamic use of Drawloop which would allow the passing to it of data that was not necessarily in a SF table but that could still be processed by a Drawloop package.
Anyway, i was thinking along those lines, hope it helps
kind regards