How to add assembly reference for Microsoft Outlook Object Library?

ChrisR1ch
New Contributor II

Is it possible to add an assembly reference to OneStream that will allow the BRApi to reference the Microsoft Outlook Object Library....or any other library that is not currently included in the OneStream.

I would like to provide a dashboard button that allows the user to open up a new Outlook email message.  Done similarly in other VB.NET projects like this

<add assembly="Microsoft.Office.Interop.Outlook, Version=11.0.0.0, Culture=neutral, PublicKeyToken=71e9bce111e9429c"/> 

 

Imports outlook = Microsoft.Office.Interop.Outlook

Dim OutlookMessage As outlook.MailItem
Dim AppOutlook As New outlook.Application
Try
OutlookMessage = AppOutlook.CreateItem(outlook.OlItemType.olMailItem)
Dim Recipents As outlook.Recipients = OutlookMessage.Recipients
Recipents.Add("myemail@hotmail.com")
OutlookMessage.Subject = "Sending through Outlook"
OutlookMessage.Body = "Testing outlook Mail"
OutlookMessage.BodyFormat = outlook.OlBodyFormat.olFormatHTML
OutlookMessage.Send()
Catch ex As Exception
MessageBox.Show("Mail could not be sent") 'if you dont want this message, simply delete this line
Finally
OutlookMessage = Nothing
AppOutlook = Nothing
End Try

 

3 REPLIES 3

ChrisR1ch
New Contributor II

I currently have set up this feature using the existing BRApi.Utlities.SendMail function......but it would be better if we could just call Outlook and use all of it's features and capabilities (i.e. formatting and file attachments)

BRApi.Utilities.SendMail(si,
"EmailConnector",
recipientList,
"OneStream",
EmailBodyText,
emptyAttachList)

OS_Pizza
Contributor III

Defining a Reference to an External .Net DLL
OneStream XF allows developers to build and reference their own custom Microsoft .Net DLLs from
Shared Business Rules. These are written in either VB.Net or C#. Custom business logic can be
encapsulated and protected within an external DLL written in Microsoft Visual Studio.
Common reasons to create a custom DLL referenced by a Business Rule:
l Protect domain specific intellectual property (hide value programming logic)
l Separate code with dependencies on other programs (system integration wrappers)
l Complex logic requiring development tools only available within Microsoft Visual Studio (Web
Service Discovery and Interface Development)
DLL Installation and Configuration
This section defines the configuration steps that must be completed before an external DLL can be
referenced within a Shared Business Rule. This is a three-step process.
1. Specify the BusinessRuleAssemblyFolder located in the Application Server configuration file
This folder should be shared by all application servers meaning the folder must be accessible
by the Account Credentials used to configure the IIS Application Pool on the application
server.
This setup process is a best practice but is not required. As an alternative, reference the
external DLL from a folder located on each application server and any time the DLL is
updated, it needs to be copied to a standard folder on each application server.

Foundation Guides
2. Identify or create the external DLL to be called and copy it to the
BusinessRuleAssemblyFolder
When a Business Rule is executed and an external DLL reference containing the XF\ prefix is
found in the Referenced Assemblies property of the rule, the application server will look in the
BusinessRuleAssemblyFolder defined in the application server configuration file in order to
find the DLL to be referenced.
3. Add a reference specification to the DLL in the Referenced Assemblies property of the
Business Rule using it.

The challenge with Interop assemblies is that it needs to be installed on the server since that is where the rules are running. I don't think the interop assemblies are portable. (means Outlook or EXCEL must be installed on the server). So your bet will be to use a dashboard button, gather the information with another dashboard and use the BRApi.utilities to send the email