A casual search of the Informatica Network Knowledge Base for the terms “send email notification from ICRT process” will yield https://network.informatica.com/thread/52346 in the top results. This is a fine solution if the process is being used with Salesforce or related to a Salesforce integration.

If your integration does not have a Salesforce component to it, you would continue to search and most likely run across KB article 441540 “HOW TO: Email from an Informatica Process Designer (IPD) in ICRT”. I can guarantee this approach will work as I have implemented it successfully after figuring out that:

1. The BPR deployment targets are reversed (eventually obvious when looking at the file names)
2. The process must be called from the Secure Agent, meaning to call from an exposed service it must be called as a sub-process

At the end of the steps, the article notes that

“As of Jan 2016 there is no direct service or function exposed that the users could leverage to send an email to some recipient.”

I appreciate that they date the point in time when this is the case as good a documentation best practice. Another best practice I have used is to create a support ticket to check for when an update is available and then update the dated documentation I have published. I recently discovered this is not shared by everyone 😛

If you are reading this now, I suggest you save some time and skip the above references and go to the February 2016 release notes (yup, with just a few weeks of the helpful KB date) and discover the Email Connector that is now available. It does all the same stuff, with the same limitation of needing to call from the Secure Agent, but with much less hassle.

I discovered the availability of the new Email connector when I was putting together reference links in preparation for this article. Using the connector is very straight-forward. The connection configuration screen is mostly intuitive, though you have to select a Specific Agent for the Run On option even though the option for Cloud Server or Any Secure Agent is available in the drop down.

You can download a basic set of example components to see how to use the email functionality here > ICRT_Test_Email_Example.zip. To use the example, follow these steps:

1. Open TestEmailConnection, select a valid Secure Agent for the Run On setting and update the Connection Properites with valid email server and credential values, then save and publish.
   
2. Close the TestEmailConnection, refresh your screen, then open TestEmailProcess and select the same Secure Agent you selected for the TestEmailConnection Run On setting for the Run Process On setting, then save and publish.
3. Close the TestEmailProcess, refresh your screen, then publish TestEmailGuide.
4. Finally, click the Run Guide link next to the TestEmailGuide name and see for yourself that it works.

I found no mention of the additional settings described in KB article 441540 in reference to using the connector, and that could be because they are no longer necessary. Note that I did not have an ORG where I had not already used the KB solution and I did not roll back those changes for a start-to-finish test because of the amount of time it would have added to making this article available. You may need to refer to the KB solution for additional settings when adding this functionality to your own ORG.

© Scott S. Nelson

I am in complete agreement with the current wisdom of designing security in from the start. When developing, it is often more expedient to leave the security out until everything else has been tested to reduce the number of parts that need to be evaluated when debugging, and I (for better or worse) take the expedient path most of the time.

Recently I built some Informatica Cloud Real Time (ICRT) Processes intended for use as web services and built them with Anonymous access allowed up until completion, at which point I added the authorized users to the list to lock them down. And then found that they would not run when provided the correct authentication.

I will spare you the many things I looked at to resolve the issue and simply point that my excuse for it taking so long was the nature of the response when calling the service, which was “HTTP Status 403 – User is not authorized to perform operation within tenant context”. With that error my pursuits at debugging were focused on security configuration.

The actual source of the issue is that once the process is deployed requiring authentication, it uses a different URL format. To wit the unauthenticated structure is:

https://[SEGEMENT] .rt.informaticacloud.com/active-bpel/public/soap/[ORG ID]/[PROCESS NAME]

and the authenticated URL is:

https://[SEGEMENT] .rt.informaticacloud.com/active-bpel/soap/[PROCESS NAME].

So, be sure to publish the correct authenticated URL to clients while developing and update your test client when finalizing.

© Scott S. Nelson