Integration OUTPUT to Web Service?
Is is possible to create an integration that creates a PDF and sends that PDF to another system via REST web service call?
Just commenting on this one to follow the post as this would also be very useful for us also..
We have produced PDF's and transferred them to another system via FTP by using a PDF printer (with statically set file path and filename structure inside the PDF printer settings... i think we use PDF2GO) and then the Move Document function inside the integration builder. this works really well.
Aside from running a third party or custom script after the document is created i'm not sure how you would achieve this.
Would the transfer have to happen instantly? if not then you could write some custom code to transfer any created PDF's in a particular folder and transfer them periodically and run this from task scheduler. the code itself would be out of my abilities but there's nothing a bit of googling can't change!
I'm interested to see what you come up with if you wouldn't mind keeping us updated :)0
My fallback option is a two-step process like you described using a script that polls for new files in created in a specific directory. Not as clean but will work with the added benefit of having a copy of the PDF for re-try should the second step fail for any reason. Real-time is not required, a one to two minute polling interval would be OK.0
Looks like no one answered this, and I just asked a question; so I thought I'd give some know-how back :)
We run a customer-facing e-commerce B2B site on Magento 2 that requires dynamic previews. We use Integration Builder on an EC@ AWS server to generate PDF files on the fly based on variable data that comes via POST from the front-end site. These is a basic overview of the steps:
1, POST statement sends the variable information to the integration in JSON format, including BTW template name
2. The integration crates a TXT file with a predefined file name that comes in as one of the JSON values
3. Next, we merge the TXT file from Step 2 with the BTW template and print to a PDF driver (we use NovaPDF because we have some experience with it, but Adobe Acrobat is much cheaper and easier to use...)
4. We return the %path% to the PDF via the built-in %Response% variable back to Magento.
The PDF file is saved to a public folder made accessible through IIS on the same server that the integration is running on; so when the front end calls the path, its available to display in the browser; but with the right PDF driver, you could save the file to an external FTP server; or even send it to a recipient via email. You can do this through an IB Action, or you could also do it through the PDF driver itself, depending on which one you're using.
There's obviously a lot more to it than these steps, but these were the initial basic actions we created in order to achieve what I understand you're trying to do. The additional actions are meant to make up for the fact that error-handling seems to be almost completely missing from IB.
If for some strange reason, you still need help with this after 2 years, let me know :)0
Thanks. I implemented as follows
1. I setup a integration that uses a web service to receive JSON formatted data and using the designated BTW creates the output
2. The PDF is generated by using BullZip PDF printer driver and passing Integration variables for the PDF filename to BullZip.
3 . The PDF gets dropped in a designated folder.
4. A dell Boomi process monitors the drop folder for new files and then uploads those PDF to Salesforce.
This process works pretty well unless I stress it hard by sending 1500 print requests as fast as they can be handled one after the other. When I do that, at around 1000 requests, the Integration engine throws a 3605 "out of resources error". So far Seagull has not been able to determine why the error gets thrown. The server running IB is not maxed in CPU or memory while running the stress test.0
If I didn't know any better, I'd suggest using Integration Builder to handle the Boomi process and eliminate one possible source of issues, but Integration Builder is acting like it has a memory leak - at least my implementation does. I've designed 7-8 version of the same process and they all basically eat up resources while its essentially doing nothing.
My guess would be you're going to have to wait for an update from Seagull to fix your issue; and until then, implement batching to handle cases where you exceed the 1000 files.
By the way, you could eliminate the Bommi step by using the PDF driver to upload the PDF to Salesforce if you wanted to. I'm not familiar with BullZip, but I've been playing with NovaPDF on this project, and it does have that feature. I'd imagine that Acrobat DC has something similar too.
Vous devez vous connecter pour laisser un commentaire.