nav[aria-label="Primary Navigation"] { padding: 0; & ul { list-style: none; width: 100%; display: flex; flex-direction: row; justify-content: start; align-items: start; gap: 30px; padding: 0; & li { margin: 0; } & ul li { list-style: none; } } }

custom script vs. solution email script

Annad

Hi,
I have developed workflow with emails using the solution email script (iw_solustion_email.ipl). However, I find that since it uses tpl, it makes the script very complicated and it is hard to manage.

I have also used my own custom perl script (in external tasks) to send emails, which was much more manageable and I had full control over it.

Currently I am building a workflow that requires emails. However, I want to know which approach (the 2 mentioned above) is used widely by IW developers. I want to get a sense of how people approach it when it comes to email in IW workflows.

Please let me know if you have any input,

Thanks,
Anna

Find more posts tagged with

Comments

Ambuj

Hi,
I have developed workflow with emails using the solution email script (iw_solustion_email.ipl). However, I find that since it uses tpl, it makes the script very complicated and it is hard to manage.

I have also used my own custom perl script (in external tasks) to send emails, which was much more manageable and I had full control over it.

Currently I am building a workflow that requires emails. However, I want to know which approach (the 2 mentioned above) is used widely by IW developers. I want to get a sense of how people approach it when it comes to email in IW workflows.

Please let me know if you have any input,

Thanks,
Anna

If you are comfortable with 2nd approach (where you are managing your own script), go for it...

kaalraa

Hi,
I have developed workflow with emails using the solution email script (iw_solustion_email.ipl). However, I find that since it uses tpl, it makes the script very complicated and it is hard to manage.

I have also used my own custom perl script (in external tasks) to send emails, which was much more manageable and I had full control over it.

Currently I am building a workflow that requires emails. However, I want to know which approach (the 2 mentioned above) is used widely by IW developers. I want to get a sense of how people approach it when it comes to email in IW workflows.

Please let me know if you have any input,

Thanks,
Anna

In one of my project, which was a complete process automation with different kind of content authors and approvers involved, we used our own custom mail script. As we need to put the mail in text/html format and has to state many other dynamic info within mail content.

It is easy to maintain the To; Cc; Subject and mail body.

Annad

Thanks to both of you.

I think I'll take the custom script approach.

mdang

I would recommend to use the Java/XSLT route if you are starting fresh. Because
1. TPL is considered obsolete.
2. OOTB TS will have less and less Perl in the future.
3. Java/XSLT is freely customizable, it won't do less than the Perl solution.
4. More scalable.

--Michael

Adam Stoller

I would recommend to use the Java/XSLT route if you are starting fresh. Because
1. TPL is considered obsolete.
2. OOTB TS will have less and less Perl in the future.
3. Java/XSLT is freely customizable, it won't do less than the Perl solution.
4. More scalable.

--Michael

that things will improve in upcoming releases so that I'll be happy using either technology - I just don't think it's there yet.

mdang

1. Ok.
2. I am sure we will continue to support both. But just OOTB, we are doing less Perl.
3. Answered in the other thread. Smiley Happy

Thanks for the feedbacks, BTW.
4. We do encounter scalability issues when using a full-fledged Perl external task workflow system. In a heavy loaded system, we could see high number of Perl invocations per second. This uses up system resource much faster than a Java threading system.

I would want to add #5.
5. XSLT is an open standard, while TPL is proprietary. That means you maybe able to reuse your solution here in other places or vice versa.

--Michael

Adam Stoller

1. Ok.
2. I am sure we will continue to support both. But just OOTB, we are doing less Perl.
3. Answered in the other thread. Thanks for the feedbacks, BTW.
4. We do encounter scalability issues when using a full-fledged Perl external task workflow system. In a heavy loaded system, we could see high number of Perl invocations per second. This uses up system resource much faster than a Java threading system.

I would want to add #5.
5. XSLT is an open standard, while TPL is proprietary. That means you maybe able to reuse your solution here in other places or vice versa.

--Michael

nipper

Michael & Adam, I like this thread. Hopefuly Sunil is following this as well. My concern is similar to Adam's. I am having trouble doing some of the basic functionality that I depend on in TPL with XSLT, I also notice similar loss of functionality with WFM as compared to WFT.

I understand this is bound to happen, because when you have Perl, you can write anything. It is going to take time to get us kicking and screaming into the WFM/XSLT environment. Sounds like a good GearUP topic, when you did this in a TPL, this is how your XSLT will look instead.

ISCBorisB

Michael & Adam, I like this thread. Hopefuly Sunil is following this as well. My concern is similar to Adam's. I am having trouble doing some of the basic functionality that I depend on in TPL with XSLT, I also notice similar loss of functionality with WFM as compared to WFT.

I understand this is bound to happen, because when you have Perl, you can write anything. It is going to take time to get us kicking and screaming into the WFM/XSLT environment. Sounds like a good GearUP topic, when you did this in a TPL, this is how your XSLT will look instead.

Strictly IMO, XSLT is a verbose monstrosity good for (perhaps) performing a limited set of specific transformations upon
large volumes of XML encoded data - and little else.

Sure, it is Turing complete and has certain perverse Functional Language elegance comparing to Procedural Languages like
Perl. As a general purpose programming language it is (again IMO) plain absurd. Just think DB Request, HTTP (or any other
protocol level) Request/Response or DateManip sort of processing in XSLT.

All that is perhaps one of the reasons why in the new schema we have to do XSLT + Java Data Sources to achieve anything more
complex than bracketing DCR Item value into an anchor tag. End of day, you have three modules with ~150 lines of code in two
languages in the place of (former) 15 lines of the original PT Perl - but it is certainly *more scalable*.

nipper

Strictly IMO, XSLT is a verbose monstrosity good for (perhaps) performing a limited set of specific transformations upon
large volumes of XML encoded data - and little else.

And you call XSLT a verbose monstrosity ? Or was the following just an example in case someone did not understand what a verbose monstrosity was ?

Sure, it is Turing complete and has certain perverse Functional Language elegance comparing to Procedural Languages like
Perl. As a general purpose programming language it is (again IMO) plain absurd. Just think DB Request, HTTP (or any other
protocol level) Request/Response or DateManip sort of processing in XSLT. Certainly, classical loops can be generalised
(to the delight of brain-dead CS College Professors) as recursions. It is shooting sparrows with the cannon though, silly
even if effective.

All that is perhaps one of the reasons why in the new schema we have to do XSLT + Java Data Sources to achieve anything more
complex than bracketing DCR Item value into an anchor tag. End of day, you have three modules with ~150 lines of code in two
languages in the place of (former) 15 lines of the original PT Perl - but it is certainly *more scalable*.

mdang

The biggest problem I've seen is cases where poorly written Perl was involved (I once got a customer a 60% improvement in performance simply be re-writing their scripts) - however, I'll consider your statement as reasonable advice (though I think if we made use of mod_perl or similar, that the difference wouldn't be that significant... haven't ever tried it though)

Poorly written code applies to any language. I see poorly written Java code that kills the performance too.

5~6 years ago, we tried mod_perl, compiled Perl, and fastcgi?. The result was not that good, mainly due to the instability and awkwardness of those tools.

One of the tests we did showed that TS scalability doubled once we changed from Perl external task to URL external task. The test was mimicking what typical customer does, mixing UI navigations, DCR creations, DCR generations, workflow creations and task transitions together. The task transitions simply call "iwextattr -s" in Perl external task, and CSSDK's setExtendedAttributes() in URL external task. By only changing that one parameter, the maximum number of concurrent users the system can support doubled.

--Michael

mdang

Strictly IMO, XSLT is a verbose monstrosity good for (perhaps) performing a limited set of specific transformations upon
large volumes of XML encoded data - and little else.

Sure, it is Turing complete and has certain perverse Functional Language elegance comparing to Procedural Languages like
Perl. As a general purpose programming language it is (again IMO) plain absurd. Just think DB Request, HTTP (or any other
protocol level) Request/Response or DateManip sort of processing in XSLT.

All that is perhaps one of the reasons why in the new schema we have to do XSLT + Java Data Sources to achieve anything more
complex than bracketing DCR Item value into an anchor tag. End of day, you have three modules with ~150 lines of code in two
languages in the place of (former) 15 lines of the original PT Perl - but it is certainly *more scalable*.

I am both a Perl coder and a Java coder too. I need to provide the exact feature in both Perl and Java from time to time. In one case, doing it properly in Perl, I wrote 1 Perl script plus 1 Perl module in 8 kB source code in 2 hours. Doing it properly in Java, I wrote 14 classes in 88 kB source in 6 hours. I totally understand the development difference between them.

Then I put them in test, and the Perl script still won the performance in some degree for the execution time. Only when I put them in a system for heavy load tests, there the Java code started to shine.

--Michael

ISCBorisB

I am both a Perl coder and a Java coder too. I need to provide the exact feature in both Perl and Java from time to time. In one case, doing it properly in Perl, I wrote 1 Perl script plus 1 Perl module in 8 kB source code in 2 hours. Doing it properly in Java, I wrote 14 classes in 88 kB source in 6 hours. I totally understand the development difference between them.

Then I put them in test, and the Perl script still won the performance in some degree for the execution time. Only when I put them in a system for heavy load tests, there the Java code started to shine.

--Michael

Although certainly Perl biased, I code Perl and Java as well. Please note that I was not talking about Java in this post - just XSLT