George

My feedback

  1. 1 vote
    Vote

    We're glad you're here

    Please sign in to leave feedback

    Signed in as (Sign out)
    You have left! (?) (thinking…)

    How important is this to you?

    We're glad you're here

    Please sign in to leave feedback

    Signed in as (Sign out)
    An error occurred while saving the comment
    George commented  · 

    Hi Candace
    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 <<field_name_tag1>> and <<field_name_tag2>> 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

    George shared this idea  · 

Feedback and Knowledge Base