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; } } }

WFM - CSSDK Email Task

Adam Stoller

The original thread was here

Yes, we are fully aware of the missing getGroup() API of the CSGroupTask. I was the one who filed the internal bug and had been pushing it for the fix. Hope we can fix that asap.

For the other claims, I would really want to understand them. It would be a big surprise for me if you have to resort to iwgetwfobj system call or other means in the Java mail task.

I am looking at this example source file:
iw-home/local/config/lib/content_center/customer_samples_src/src/com/corp/custom/MailNotificationTask.java

the constants section has these
    public static final String MAIL_SUBJECT         = "Sample Task Notification";
    public static final String MAIL_ENCODING        = "UTF-8";
    public static final String MAIL_MIME_TYPE       = "text/html";

    // fill in your mail server host name
    public static final String MAIL_SERVER          = "smtp.corp.com";

    public static final String KEY_MAIL_TEMPLATE    = "mail_template";
    public static final String KEY_TARGET_TASK_NAME = "target_task_name";

    // web host to serve all the stylesheet and images to the HTML email
    public static final String WEB_HOST             = "localhost";

    // print lots of JavaMail mail session debugging info.  Turn this off when
    // email is working properly.
    public static final boolean DEBUG_MAIL_SESSION  = true;
So you can code your business logic to customize the subject line, encoding, html/plaintext, and also the debugging flag. In the following code like the sendMail() method, you can certainly customize your recipient list, from address, cc list, etc.

Maybe the current Java solution did not expose these customizations as config files like the Perl solution mail did. We may want to improve the Java solution in that way, but that doesn't hinder the flexibility of it, I think. Please let me know otherwise. I would like to kill your pain before it becomes mine.

Also, I hear that we need to improve on the documentation part of the CS APIs.

--Michael

First, since you're internal - I'll assume you can access support cases - in which case - feel free to chime in on:

Java implementation of iw_solution_email.ipl OOTB. If you can convince the powers-to-be to do this, I'll buy you dinner at GearUp next year ;-)

Find more posts tagged with

Comments

mdang

I hear that the biggest issue is that the CSGroupTask is missing the getGroup() api. I am monitoring the bug and pushing the fix for TS6.7.1 SP1 Patch 5 and TS6.7.2 Patch 2 (keep my fingers crossed). This missing piece gives me some big pain too since customer cases like this are coming to my lap (including the ones you filed Smiley Happy

). I would want this to be fixed as much as you do. Plus I want to get your dinner too. Smiley Happy

On the other hand, I want to speak for CSSDK a bit. Besides the one missing API (due to some oversight) we found, CSSDK is not a half-completed tool to replace Perl/CLTs. The entire Content Center UI is built on top of CSSDK to communicate to the server. CSSDK functionality should be a superset of what Perl/CLTs can offer. To developers, CSSDK has much richer APIs and provides finer control over Perl/CLTs.

If we were using OS-Users, this wouldn't be that big a deal - we would simply use the Perl script and be done with it. Unfortunately, Interwoven made a big deal about being able to use Non-OS Users with 6.7.1SP1 - and my current customer is among those who is requiring that we implement for such an environment - so the Perl script cannot be used (as far as I understand it) because of the issues of trying to handle impersonation with non-OS-users as the file system / OS level (I'm assuming the system would attempt to do so and fail, since the Email Task would be owned by a Non-OS-User - am I right?)

I am sure the non-OS user feature is more of a customer driven feature than a IWOV invented one. Also I think some of the statements out there are somewhat misleading. It sounds like Non-OS users and Perl scripts are absolutely incompatible. But that is not true to me. There are 3 things: Non-OS users, Perl scripts, and impersonation. You can not have all 3. You can only pick the 2 that are most important to you and give up the last one. For example, if customers have to have Non-OS users and Perl scripts, then they will have to give up impersonation. That means the Perl scripts will be run as root or system. But in many cases, impersonation is on the top of the list for customers. Smiley Sad

--Michael

Adam Stoller

I hear that the biggest issue is that the CSGroupTask is missing the getGroup() api. I am monitoring the bug and pushing the fix for TS6.7.1 SP1 Patch 5 and TS6.7.2 Patch 2 (keep my fingers crossed). This missing piece gives me some big pain too since customer cases like this are coming to my lap (including the ones you filed ). I would want this to be fixed as much as you do. Plus I want to get your dinner too.

Sounds good!

On the other hand, I want to speak for CSSDK a bit. Besides the one missing API (due to some oversight) we found, CSSDK is not a half-completed tool to replace Perl/CLTs. The entire Content Center UI is built on top of CSSDK to communicate to the server. CSSDK functionality should be a superset of what Perl/CLTs can offer. To developers, CSSDK has much richer APIs and provides finer control over Perl/CLTs.

I understand that the UI was built with CSSDK - and I never intended to imply that it was "half-completed" - merely that it had a gaping hole as far as Workflow API was considered (I believe the Workflow engine core is C++) and that it seems that the hole (as I see it) was not found during unit tests or QA - which is ... shall we say ... very annoying. In addition, there appear to be at least some aspects of the CSSDK that failed to get documented (e.g.: emit() in 3.1.0 and toElement() in 3.1.1) which should have been discovered when the various workflow email notification modules were created.
All that, coupled with the fact that Interwoven already provided a fairly well designed, flexible, functional Perl script (iw_solution_email.ipl) - they seemed to take a step backwards when trying to produce a Java replacement for it which, had they actually used it is a design model, would have uncovered the issue with the CSGroup module and this entire thread (along with my other recent posts) would never have been necessary.

I am sure the non-OS user feature is more of a customer driven feature than a IWOV invented one.

I'm sure you're right about that, but it was an "advertised" feature which then means that more customers are going to latch onto it

Also I think some of the statements out there are somewhat misleading. It sounds like Non-OS users and Perl scripts are absolutely incompatible. But that is not true to me. There are 3 things: Non-OS users, Perl scripts, and impersonation. You can not have all 3. You can only pick the 2 that are most important to you and give up the last one. For example, if customers have to have Non-OS users and Perl scripts, then they will have to give up impersonation. That means the Perl scripts will be run as root or system. But in many cases, impersonation is on the top of the list for customers.

--Michael

Thanks for the clarification about that, and yes, I think you are right about impersonation being more important than method-of-implementation of the customizations. This makes me think that we might be able to use iw_solution_email.ipl even in a non-OS user environment, since the From information should be coming from the "current" task owner - and even though the process is run by root, the task owner should still be the non-OS user - right?
Of course, we also have to deal with our customer's insistence that we not use Perl, but based on what you've indicated here - that would be more of a "political" than "technical" issue - yes?

mdang

I am an engineer, I am unaware of any political issues. Smiley Happy

Technically it looks possible to me. I haven't tried it though.

--Michael

Adam Stoller

FYI (though mdang probably already knew this) - the bug number for the GroupTask issues is (as I was just informed by Support): TS-5304

So - for the rest of you reading this thread, if you feel that this functionality is important - feel free to open a case with Support and get your customer's name added to the bug (it helps improve the chances for a sooner-rather-than-later fix)

crosstabsum.rptdesign

Migrateduser

guys, we recently upgraded to ts 6.7.2 and all our emails stopped working, with the following error

java.lang.NoSuchMethodError: com.interwoven.cssdk.workflow.CSTask.emit(Lorg/dom4j/Element Smiley Wink

Lorg/dom4j/Element;

so fish, you are saying this method was deprecated/changed to

toElement()? is it as simple as to update all our calls from emit() to

toElement()?

Adam Stoller

guys, we recently upgraded to ts 6.7.2 and all our emails stopped working, with the following error

java.lang.NoSuchMethodError: com.interwoven.cssdk.workflow.CSTask.emit(Lorg/dom4j/ElementLorg/dom4j/Element;

so fish, you are saying this method was deprecated/changed to
toElement()? is it as simple as to update all our calls from emit() to
toElement()?

I believe that is the case - yes - try it and let us know.

Migrateduser

...
        CSUser targetTaskOwner = targetTasks[0].getOwner(); 
        String recipientAddress = targetTaskOwner.getEmailAddress();
...
If your targetTask is an unowned GroupTask - one or both of these lines will cause an exception to be thrown.

I just tried this, and it does not throw an exception. I am trying to do something if the group task is unowned. I can call


    CSUser owner = targetGroupTask.getOwner();
    String ownerName = owner.getName();

without getting an exception, and ownerName is equal to "<no user>".

Migrateduser

so does it actually send emails to group tasks properly? or does it just not throw the error? is there any update if/when this will be fixed in the java methods/cssdk?

Migrateduser

Anybody able to compile the code using the currentTask.toElement() or currentTask.emit()?

When I put it in my ide, I am getting:
cannot find symbol
symbol: method toElement(java.lang.String, java.util.Map)
location: interface com.interwoven.cssdk.workflow.CSTask

I have imported com.interwoven.cssdk.workflow.*

TeamSite 6.7.2 on Linux (no sp)
CSSDK 3.1.1
Also tried with CSSDK 3.1.0

Anybody else was able to compile the code?

CRB

there is no currentTask.emit().
there is currenTask.emit(Element arg0) and currenTask.emit(Element arg0, Map arg1).
try importing com.interwoven.sharedutils100.xml.*

what are you trying to get?

dynamic_yseries_title.rptdesign

Migrateduser

I am just trying to compile the sample code in customer_samples_src/src/com/corp/custom
MailNotificationTask.java.

But there are no references to .emit(older cssdk) method or .toElement(newer cssdk) method.

Yes, I have the import com.interwoven.sharedutils100.xml.*;
line in my java class.

there is no currentTask.emit().
there is currenTask.emit(Element arg0) and currenTask.emit(Element arg0, Map arg1).
try importing com.interwoven.sharedutils100.xml.*

what are you trying to get?

Migrateduser

Anybody able to compile the code using the currentTask.toElement() or currentTask.emit()?

When I put it in my ide, I am getting:
cannot find symbol
symbol: method toElement(java.lang.String, java.util.Map)
location: interface com.interwoven.cssdk.workflow.CSTask

I have imported com.interwoven.cssdk.workflow.*

TeamSite 6.7.2 on Linux (no sp)
CSSDK 3.1.1
Also tried with CSSDK 3.1.0

Anybody else was able to compile the code?

For what it's worth, we are using currentTask.toElement(). It works fine:

[left]

 
// Get the XML representation of the current task [/left]
Element bodyElement = getCurrentTask().toElement();

[left]

We are on TS6.7.2 on Solaris.[/left]

Migrateduser

Would you mind sharing your code? Or your secret? Is there some import that I am missing?

For what it's worth, we are using currentTask.toElement(). It works fine:

[left]
 
// Get the XML representation of the current task [/left]
Element bodyElement = getCurrentTask().toElement();

[left]
We are on TS6.7.2 on Solaris.[/left]

Migrateduser

Can't give you our code, but I am importing:

[size=2][color=#7f0055]import[/color][/size] com.interwoven.cssdk.workflow.CSTask;

Your error says:

cannot find symbol
symbol: method toElement(java.lang.String, java.util.Map)

Have you tried to use the method that takes no parameters instead of the method that takes 2 parameters? Perhaps you don't have the most recent jars?

Migrateduser

I finally had the chance to get the sample code to compile. What I had to do was to remove all my jars from the IDE, then add the jars from CSSDK 3.1.1 back. If you just try to add the jars from cssdk3.1.1 with the same name that you had, I guess it is not smart enough to figure out that even though the names are the same, they are different especially since the older cssdk does not have the toElement method for the CSTask.

Can't give you our code, but I am importing:

[size=2][color=#7f0055]import[/color][/size] com.interwoven.cssdk.workflow.CSTask;

Your error says:

cannot find symbol
symbol: method toElement(java.lang.String, java.util.Map)

Have you tried to use the method that takes no parameters instead of the method that takes 2 parameters? Perhaps you don't have the most recent jars?

vpatel

Anybody able to compile the code using the currentTask.toElement() or currentTask.emit()?

When I put it in my ide, I am getting:
cannot find symbol
symbol: method toElement(java.lang.String, java.util.Map)
location: interface com.interwoven.cssdk.workflow.CSTask

I have imported com.interwoven.cssdk.workflow.*

TeamSite 6.7.2 on Linux (no sp)
CSSDK 3.1.1
Also tried with CSSDK 3.1.0

Anybody else was able to compile the code?

What is the object type of your "currentTask"?
Have you imported com.interwoven.cssdk.common.xml.*?
Do you have the necessary JAR files in your classpath?

mart2001

currentTask is of type CSTask
Yes, I have imported com.interwoven.cssdk.common.xml.ElementableUtils since there was only 1 class in that package.

I had to remove the old jars from my library (3.1.0) and then add the jars from (3.1.1) in order to get the code to compile.

What I did before was just import the cssdk 3.1.1 jars, and it looks like since it had the same name, the jars were not updated.

What is the object type of your "currentTask"?
Have you imported com.interwoven.cssdk.common.xml.*?
Do you have the necessary JAR files in your classpath?

vpatel

currentTask is of type CSTask
Yes, I have imported com.interwoven.cssdk.common.xml.ElementableUtils since there was only 1 class in that package.

I had to remove the old jars from my library (3.1.0) and then add the jars from (3.1.1) in order to get the code to compile.

What I did before was just import the cssdk 3.1.1 jars, and it looks like since it had the same name, the jars were not updated.

Not totally true. In 3.1.1 version, in the com.interwoven.cssdk.common.xml package, there is an interface called "Elementable" and the "toElement" method is inside of that interface. Indeed, the CSTask.toElement points to the method in the Elementable interface. Just go ahead and import entire package and see what you get.

mart2001

Thanks, I have it working now. Just need to remove packages and reinstall packages....

Now, onto why I can't have a group task after an email task....

Not totally true. In 3.1.1 version, in the com.interwoven.cssdk.common.xml package, there is an interface called "Elementable" and the "toElement" method is inside of that interface. Indeed, the CSTask.toElement points to the method in the Elementable interface. Just go ahead and import entire package and see what you get.