Salesforce.com integration

168 views
Skip to first unread message

Shalom

unread,
Jan 14, 2009, 2:13:05 PM1/14/09
to XMPie Interest Group
Has anyone worked on integrating uProduce and Salesforce.com? Is it
even possible? If so, how difficult? Any positive/negative experience?

Jeffrey A. Stewart

unread,
Jan 14, 2009, 4:36:44 PM1/14/09
to xmpie...@googlegroups.com
While we do not have a complete, foolproof integration between SF and
uProduce, we are working around the edges and will have custom one
before too long. The route we are taking is to align Salesforce
campaigns and the resulting contact lists to uProduce Campaign Recipient
Lists. The idea is that Salesforce will push and initiate a uProduce
production by uploading a list of contacts automatically. And then
report back from data collected as uProduce tracking back into the
Saleforce campaign results.

Conceptually not difficult at all. Both systems have good open API's. It
will require custom code in Salesforce or custom code elsewhere to
achieve the integration. What we have done is 'manual' integration and
proof of concept code for full integration. We have typically exported a
report of contacts from Saleforce and upload them as a recipient list
where the plan is designed to work with this report directly.

The other route you could take is to integrate Saleforce reports or
campaign lists as a custom data feed for uStore. And when you are in
uStore you use Salesforce as a data source to initiate a campaign
production on uProduce.

Does this help?

Jeffrey Stewart

Phone: 815.262.7252
st...@trekk.com
This email and any attached files are confidential and intended solely for the intended recipient(s). If you are not the named recipient you should not read, distribute, copy or alter this email. Any views or opinions expressed in this email are those of the author and do not represent those of TREKK. Warning: Although precautions have been taken to make sure no viruses are present in this email, the company cannot accept responsibility for any loss or damage that arise from the use of this email or attachments.

Timothy Perrett

unread,
Jan 15, 2009, 10:09:11 AM1/15/09
to XMPie Interest Group
Hey Guys,

Interesting thread - If you wanted to use salesforce data as part of
your recipient list I wonder if using a salesforce ODBC driver would
be good? Just a suggestion but it seems like a more logical fit XMPie
wise (data sources are OLEDB / ODBC powered):

http://www.openaccesssoftware.com/products/openrda/salesforce_overview.asp

I must stress i've never used this, nor tried it with XMPie. I have
however tried lots of other wacky datasource solutions and its been
pretty successful: load driver, choose generic DSN string as your data
source, write a recipient filter.

Cheers

Timothy

loop: http://blog.getintheloop.eu
lift: http://liftweb.net


On Jan 14, 9:36 pm, "Jeffrey A. Stewart" <S...@trekk.com> wrote:
> While we do not have a complete, foolproof integration between SF and
> uProduce, we are working around the edges and will have custom one
> before too long. The route we are taking is to align Salesforce
> campaigns and the resulting contact lists to uProduce Campaign Recipient
> Lists. The idea is that Salesforce will push and initiate a uProduce
> production by uploading a list of contacts automatically. And then
> report back from data collected as uProduce tracking back into the
> Saleforce campaign results.
>
> Conceptually not difficult at all. Both systems have good open API's. It
> will require custom code in Salesforce or custom code elsewhere to
> achieve the integration. What we have done is 'manual' integration and
> proof of concept code for full integration. We have typically exported a
> report of contacts from Saleforce and upload them as a recipient list
> where the plan is designed to work with this report directly.
>
> The other route you could take is to integrate Saleforce reports or
> campaign lists as a custom data feed for uStore. And when you are in
> uStore you use Salesforce as a data source to initiate a campaign
> production on uProduce.
>
> Does this help?
>
> Jeffrey Stewart
>
> Phone: 815.262.7252
> s...@trekk.com

Rien van Herpen

unread,
Jan 15, 2009, 2:38:40 PM1/15/09
to xmpie...@googlegroups.com
Hi all,

We now have our first real job with XMPIE (uDirect).

The job is one page with some images, a bit of a heavy page. Transparency is
also included.
We only have text as variable data.
The total job is 2000 single pages.

We started with 1000 page at one run. After 1 night, it still wasn't
finished.
So we stopped this run. Now we tried it with 100 pages. This takes 20
minutes to process a PDF file.

This is quite a long time, we think.

Those anyone have the same experiences?
Or does anyone know what we doing wrong?

Greets Rien.

George Marsh

unread,
Jan 16, 2009, 2:37:19 AM1/16/09
to xmpie...@googlegroups.com
Hopefully not stating the obvious but have you optimized all your
images? They should all be pre-cropped to 300ppi, rotated and
converted to your destination colourspace.

What hardware are you running on? We had abysmal performance on Mac
power pc and saw a huge performance jump when going to Windows a few
years back.

Are you doing nested composition?

What db are you using? Etc.

Adam Luther

unread,
Jan 15, 2009, 7:53:52 PM1/15/09
to xmpie...@googlegroups.com
It's the transparency.

The transparency is being resolved on a record-per-record basis. Basically, open record #1, flatten record #1, output record #1...

My question: Is your dynamic text transparent?

If it is, you are going to notice a performance hit, both in output time and in the final file size.

If your variable text does NOT require transparency, then I'd recommend preflattening all of the static elements. Eliminate the need to invoke the flattener (XDOT), unless you NEED to.

Either way, file optimization is a good idea.
- Downsample any images of excessive resolution. Get anything above 300ppi (or whatever you're shooting for) down to that level.
- Consider saving images (or the entire "static" background) in the EPS format, which can be cached and reused in the output stream.
- Basically, lock down and simplify anything that isn't dynamic -- it'll help in the long run.

Adam

Tyrone Obrien

unread,
Jan 15, 2009, 8:12:08 PM1/15/09
to xmpie...@googlegroups.com
Hi Rien

Firstly what output device are you printing to as if its any XEROX
machines you would be better off running VPS
Also check the image sizes as they need to be 100% to the indesign
picture boxes as some times the actual images are 100's of megs for a
logo size image a quick way to fix this is to copy the image in indesign
with Display Performance as highest quality, then open photoshop >> file
new >>OK then go to edit Paste this will use smart object layers in
Phtoshop to place the images at the same size as at a high resolution.
Then flatten layers and replace images at 100% in indesign. This applies
if your images have any effects applied to them in indesign as XMPie
will use XDot at processing time and this will slow your processing down
considerably

Hope this helps

TOB

-----Original Message-----
From: xmpie...@googlegroups.com [mailto:xmpie...@googlegroups.com]
On Behalf Of Rien van Herpen
Sent: Friday, 16 January 2009 6:39 AM
To: xmpie...@googlegroups.com
Subject: [xmpie-users] uDirect output takes a long time


######################################################################
Notice of Confidential and Privileged Information
This e-mail transmission is intended only for the addressee(s) and may contain confidential information. Confidentiality is not waived if you are not the intended recipient of this e-mail, nor may you use, review, disclose, disseminate or copy any information contained in or attached to it. If you received this e-mail in error please delete it and any attachments and notify us immediately by reply e-mail. The unauthorised use of this email may result in liability for breach of confidentiality, privilege or copyright.

The sender does not warrant that any attachments are free from viruses or other defects. You assume all liability for any loss, damage or other consequences which may arise from opening or using the attachments

This email was scanned and cleared by NetIQ MailMarshal.
######################################################################

Alan Dixon

unread,
Jan 16, 2009, 3:13:35 AM1/16/09
to xmpie...@googlegroups.com
Hi
It is always difficult to compare processing speeds - when the comparisons are made unfairly

ie a year apart and also when the host application (Adobe Indesign) and the plug-in technology form XMPie has also been upgraded. Let alone the actual platforms and OS running (Power PC compared to Intel based)

We demo XMPIE on both platforms (Mac and Windows) and although there are some fundamental differences, both perform well as a desktop solution.
If demand grows then you should consider moving up to and XMPIE server based solution.

George is quite correct though. Regardless of platform or architecture you need to consider carefully when you design the campaign, trying to optimise where possible.

Regards
Alan

noodle

unread,
Jan 16, 2009, 10:14:26 AM1/16/09
to XMPie Interest Group
Hello all,

This is my first post so of course, I hope that I am doing this right.

I am about 4 months into using the XMPie program so I am petty new at
this myself. I have been running the iGen3 for about a year and a
half. But for my .010th of a cent imput.

Why is your output pdf? If the only thing that is variable wouldn't it
easier to seperate the static from the variable in layers and export
the static as an eps then repast it as a flattened image? ( That was a
question to the population of the group ). And the last question is
what are you printing this on?

Jeffrey A. Stewart

unread,
Jan 16, 2009, 12:16:14 PM1/16/09
to xmpie...@googlegroups.com
Rien,

uDirect utilizes your desktop InDesign engine to produce output. If you
manually create a sample using your template and go through all of the
steps from opening InDesign through export and save as PDF you can gage
the time it takes to produce this output via uDirect automation.

It sounds like you could look at the imagery and transparency as issues
that could use optimization. The great news is that excellent
transparency support is available. The bad news is that it is available.
In our experience, addressing image size, formats and transiency in
general are the cause of much of the performance issue confronting you.

Jeff


-----Original Message-----
From: xmpie...@googlegroups.com [mailto:xmpie...@googlegroups.com]
On Behalf Of Rien van Herpen
Sent: Thursday, January 15, 2009 1:39 PM
To: xmpie...@googlegroups.com
Subject: [xmpie-users] uDirect output takes a long time


Mark Kuehn

unread,
Jan 16, 2009, 11:13:37 AM1/16/09
to xmpie...@googlegroups.com
I typically create a version of the document that has the variable fields
removed. I then print that document to a postscript file and distill the
output. I then export the page as an EPS file from the PDF document. I place
this EPS into an art box and create the variable content fields.

This method dramatically speeds up processing and because I am distilling
everything I can control effective PPI and truncation of image content not
in the visible area of the page without having to modify the underlying art.

This method works great for short documents 2 to 8 pages. However when I get
into larger documents, I work everything in the native InDesign format. For
example I have a 32 page marketing brochure that would be too much work to
place and replace each page. It can be done, but since that document only
produces 5 to 10 at a time, I felt it wasn't worth it.

-Mark

markb

unread,
Jan 16, 2009, 12:46:48 PM1/16/09
to XMPie Interest Group
My 2 cents on Xerox production presses and XMPie output. We don't have
VIPP licenses on our iGen4 or iGen3 and we have had great success with
optimized PDF output. We migrated a workflow that's about 80,000
impressions each cycle (14x20 sheet size) from fusion pro PPML to
uProduce Optimized PDF output. As a rule, we try very hard to not
include transparent elements in our XMPie templates, but this specific
workflow allows users to upload pdf content. I'd say 10% of the stream
has to be flatten by X-DOT due to this. The uProduce server gear we
have rendering the stream is quick and only issue I have found, is
that sometimes a 250 sheet segment of the stream will create a PDF
that is too large for uProduce and the job will fail. This is rare
though, and the work around for this is to re-render the 250 sheet
chunk into multiple smaller segments- 100 or 50 clicks. Optimized PDF
is the choice output format right now for us- works well with some
Indigo RIPs as well, but the trick is to have a RIP that can work with
Optimized PDF- if you don't, the RIP can't take advantage of the
dynamic properties of the format. Mark

Rien van Herpen

unread,
Jan 16, 2009, 1:50:28 PM1/16/09
to xmpie...@googlegroups.com
Hi all again,

Thanks for your input.

We have a Kodak Nexpres printer, so we can't use the iGen format. And we
have to use PDF.

We are going the check the images and see whether we can flatten the images.

Thanks.

-----Oorspronkelijk bericht-----
Van: xmpie...@googlegroups.com [mailto:xmpie...@googlegroups.com]
Namens noodle
Verzonden: vrijdag 16 januari 2009 16:14
Aan: XMPie Interest Group
Onderwerp: [xmpie-users] Re: uDirect output takes a long time

Mark Kuehn

unread,
Jan 16, 2009, 4:24:27 PM1/16/09
to xmpie...@googlegroups.com
You could use VDX output with your Nexpress. It should give you better
performance than PDF, as it caches common images.

-Mark
Reply all
Reply to author
Forward
0 new messages