Sage ACT! 2013SDK Update

Brian P. MowkaMarch 23, 2012

Template date: October 2010

2

Agenda• Smart Tasks Changes

– Service– New framework plugin interface

• Overview• Definition• Example and diagram

• Moving to .NET 4.0– Reasoning– What’s new?– Plugins– Resources

• IIS 14.2/15.0 APFW/SAPM– Configuration IIS 6 (Demo)– Configuration IIS 7

3

Smart Task Changes - Service

• There will now be a service running on the application server (usually same as Search service/DB server) that can process smart tasks without the user being logged in/running ACT!

• Existing smart task flows will continue to work and there will not be the need to redo or rework existing workflows

• If smart task requires user interaction to complete, the server service can only process steps up to the point where user interaction is required and therefore will leave it pending state for a local instance to be picked up for correct user requiring input. (Moral here is don’t require user input if you want something to run unattended)

4

Smart Task Changes - Service

• There is both a local client workflow activity service *AND* a workflow activity server service which can process steps with the exception of user interaction steps.

• Both services (actually one per client running ACT! and one for the server) can execute steps for workflows and they process them serially per instance

• Think of the database as a holding queue for tasks and the server and client activity services polling (Frequently) trying to find steps to execute and processing them as they are found

5

Smart Task Changes – Service Diagram

ACT! Database Server

ACT! Client (Has Local ST Service)

ACT! Client (Has Local ST Service)

ACT! Application Server/Smart Task Service

Client Server

6

New framework plugin interface - Overview

• Purpose: To support plugins intended to extend the functionality of Sage ACT! “Smart Task” Service

• Instantiation: Framework plugins will be loaded by the Smart Task service framework instance (before any user is logged on *AND* they will be loaded on the application/db server (Often DB server for most systems))

• Design: Modeled after the existing plugin technology interface in virtually every way – one large exception being that it will return a “ActFramework” object as opposed to “ActApplication” object and is instantiated by the Start Tasks service only

7

New framework plugin interface - Definitionnamespace Act.Framework.Plugins{ /// <summary> /// Allows 3rd parties to integrate plugin functionality with the ACT! framework. /// Classes implementing IFrameworkPlugin and placed in the ACT! Plugins folder are /// Loaded on demand. /// </summary> public interface IFrameworkPlugin {

/// <summary> /// Code to run when a plugin is loaded. /// </summary> /// <param name="framework">Current instance of the ACT! framework object</param> void OnLoad(Act.Framework.ActFramework framework);

/// <summary> /// Code to run when a plugin is unloaded. /// </summary> void OnUnLoad(); }}

8

New framework plugin interface - Demo• Please see download example for creating a note:

– http://community.act.com/t5/Sage-ACT-Developer-Downloads/NEW-ACT-Framework-Plugin-used-for-new-Smart-Task-Service-v15-0/m-p/189411#M650

– Code dive...

9

Moving to .NET 4.0 - Reasoning• Why?

– Faster install on some OS’s (Vista particularly)– Smaller package (IE: Less to Download)

• 3.5 SP1 – 231MB• 4.0 – 48.1MB

– Additional capabilities• WPF Controls

– UI Renders *MUCH* faster using Direct X/Video Card vs. winforms CPU

– Saves us time from developing and testing our own• RAZOR/MVC 3 is being used on mobile web client in 14.2

– Also helps to avoid confusion over “Mixed” deployment scenarios with windows client (3.5) web client and mobile client (4.0)

10

Moving to .NET 4.0 - What’s new• New CLR

– This has far reaching implications as it creates a dividing line between everything from 2.0-3.5 and 4.0. Basically, everything since 2.0 has been running under the same engine and 3.0 and 3.5 were just improvements in functionality and capabilities – no changes to the engine.

• New GAC– We tend to put most of our assemblies into the GAC for a few

reasons• Performance• Guaranteed to find assemblies for 3rd parties

– There is a completely separate GAC for 4.0 – again different that 3.0 and 3.5 which still used 2.0 GAC

– There is therefore a separate machine.config also for assembly version redirecting – which we do a lot of!

11

Moving to .NET 4.0 - Plugins• What does this mean for existing plugins?

– Plugins should not fail as they are loaded by Sage ACT! running under .NET 4.0 and we have updated our configuration to “Allow” non-4.0 code to run under 4.0 CLR

• How does this work?– We add the following node to our config file which tell the

*NEW* 4.0 CLR that we will allow .NET 2-3.5 versions to run under our CLR

• <startup useLegacyV2RuntimeActivationPolicy="true"> <supportedRuntime version="v4.0" sku=".NETFramework,Version=v4.0"/> </startup>

• Will it always work?– Simply put, that depends on each plugin – That is why you

need to test them out during BETA.– So far, I have not seen problems with the plugins I have

downloaded and tested.

12

Moving to .NET 4.0 - Plugins• Should I recompile my plugin for .NET 4.0?

– It’s up to you, but from 2013 on we will only install .NET 4.0 and .NET 2.0 for you

• Why 2.0? Because SQL 2008 R2 installs it automatically, we don’t use it though...

• Will I need to distribute 3.5 with my plugin?– Depends on what you are leveraging in 3.5 vs. 2.0.

• If you are using core 2.0 functionality, you are just fine.• If you are using 3.5 functionality explicitly and it’s not on system

(most systems now have 3.5, but going forward (win 8) that will change to 4.0 being pre-installed) then you may need too if you have references that specify specificversion=true; or you have any breaking changes in 4.0 - See MS site for more info.

• We *REALLY* need your help to make sure of our findings here during BETA – TEST…TEST…TEST your plugins this year!

13

Moving to .NET 4.0 - Applications• If you have an application that utilizes the Sage ACT!

Framework you will need to do one of the following:– Rebuild application with .net 4.0 and re-deploy– Add node to configuration file to run under specifically

under .net 4.0 (and deploy) – needs to reside in folder of exe• <configuration>• <startup useLegacyV2RuntimeActivationPolicy="false">• <supportedRuntime version="v4.0.30319"/>• </startup>• </configuration>

• We are still doing testing in this area as well as researching configuration issues so stay tuned!

14

Moving to .NET 4.0 - Applications• Demo

15

Moving to .NET 4.0 - Resources

http://msdn.microsoft.com/en-us/library/bb822049.aspx

History of .NET

16

Moving to .NET 4.0 - Resources

http://msdn.microsoft.com/en-us/library/ff602939.aspx

Version Compatibility in the .NET Framework

http://msdn.microsoft.com/en-us/library/ee941656.aspx

.NET Framework 4 Migration Issues

http://msdn.microsoft.com/en-us/library/ff770241.aspx

How to: Configure the .NET Framework 4 Runtime

17

IIS 14.2/15.0 APFW/SAPM – IIS 6– Demo

18

IIS 14.2/15.0 APFW/SAPM – IIS 7