1. CREATING COMPANION APPLICATIONS FOR DYNAMICS GP

2. AGENDA Topic Service Based Architecture Overview The A – Z of Building Service Procedures Approaches for Building Mobile Applications Questions

3. Service Based Architecture Overview

4. Consumes and exposes services Logic in any dictionary including ISV products can be exposed as service operations. Secure Access Use Windows or O365 Identity to authenticate. https protocol with REST style API lets you build apps on many different platforms Operation Security Managed within the application just like forms and reports. Scalable Deployment models fit any sized organization needs. Discovery operations inform you of available operations and their syntax Deployable on Enhanced Interoperability gives developers additional capability to leverage the Microsoft Platform. Integrate to other applications or services

5. Host 1 MEET THE COMPONENTS Host 2

6. COMPONENT RESPONSIBILITIES User resolved? User in tenant? Available host? Forward request Recycled process? New process? Forward request Known operation? Map parameters Call procedure GP User? Security? Execute procedure Return after delayed Run background Execution finished

7. THE ENDPOINT URI STRUCTURE PATTERN: [Context]/[Resource Path(keys)]?[Query String] Hypothetical Examples GET … /Tenants(Default)/Companies(Contoso)/Sales/Customers(AARONFITZ0001)?format=summary POST … /Tenants(Default)/Companies(Contoso)/Sales/Customers DELETE … /Tenants(Default)/Companies(Fabrikam.%20Inc)/Manufacturing/Boms(WIDGET123) GET … /Tenants(Default)/Companies(Fabrikam.%20Inc)/Products(Id=346)/Boms?limit=20 https://gpwebr2.gpwithazure.com/GPService/Tenants(GP 2015 RTM)/Companies(Fabrikam, Inc.) /Dynamics/Inventory/Items(100XLG).xml

8. DISCOVER YOUR URI Discover available operations on a live deployment – just add /Help Use to model your code or extract info from system Provides info on objects, parameter requirements Discovery not filtered by security – you may see operations you can’t call Example URI does not provide company context

9. SERVICE CALL IN ACTION LAN Boundary Machine Boundary Host 1 Base URL = www.FABHosted.com/Services/ GPService GET https://www.FABHosted.com/Services/GPService/Tenants(DefaultTenant)/FieldService/Contracts?Number=‘1234 ’ GET https://www.FABHosted.com/Services/GPService/Tenants(DefaultTenant)/Sales/Orders(BKO98765) Products

10. WHAT’S BEHIND AN OPERATION? Dexterity sanScript +.NET interop New global procedure type - Service Procedure Added properties to describe operation Documentation – flows through to Discovery

11. SERVICE PROCEDURE PROPERTIES Action – maps to http verbs + custom POST option CustomAction – tag to identify a non crud operation Enabled – DAG recognizes if TRUE RawRequest – you get the raw html stream URI Template – resource path used to invoke and bind non managed parameters Special User Type – available to limited users

12. SECURITY Fully Encrypted with SSL Consumers must be a GP User with AD or Org Account mapped Roles/Tasks authorize operations

13. Host 1 bob@somedomain.com Authenticate “bob” Is “bob” in Tenant2? Is “bob” a GP User and can he access this procedure? SSL Encrypted SECURITY FLOW

14. PARTNER BENEFITS Companion/Mobile app opportunities A recent survey by Vision Mobile found that just 16% of worldwideVision Mobile developers are building mobile apps for enterprises Ability to leverage managed code Integrate to any desired GP functionality CRUD & non CRUD operations Maintain existing Dexterity investments

15. “REIMAGINE THE POSSIBILITIES” This is more than just a bunch of web services It’s a framework It’s an enabler Think broadly first then narrow your focus Anything that benefits from mobility is a candidate

16. The A – Z of Building Service Procedures

17. DECIDING ON THE DESIGN Wrapped Window Approach A complete window or form’s logic is wrapped into a service Decoupled Approach Exposes Dexterity procedures or functions as a service

18. DECOUPLED APPROACH When to choose a decouple approach? Limited data validation on control scripts Scripts can be called independently of window Faster performance Faster method for developing service procedures

19. DECOUPLED APPROACH EXAMPLE

20. WRAPPED WINDOW APPROACH Why choose to wrap a window? Window controls tied heavily to data validation Window contains a large amount of implicit validation Example: If Field A = X then disable Fields B - D

21. WRAPPED WINDOW APPROACH EXAMPLE

22. .NET CLASSES Create a.NET class library with all the properties reflecting the associated Dexterity table Include all fields from the table Remove white spaces from the names Create enumerations for radio groups and drop down lists Expose this newly created class to your Dexterity application via the.NET Interop functionality

23. SERVICE CODE GENERATOR FORM Exists in the Core dictionary Accessed by placing button on window Purely a developer tool Helps with initial creation of classes

24. “SERVICECODEGENERATOR” FORM

25. ENUMS Ease of consumption and use Considerations 0 or 1 based controls Static or Dynamic

26. MAP STATEMENT Syntax: map field1 to field2; Example: inout string itemID; inout CustomerClass CustObj; map itemID to ItemID of window IV_Item_Maintenance; map CustObj.ID to CustomerID of window RM_Customer_Maintenance;

27. .NET INTEROP Reference.NET assemblies in Dexterity dictionaries Create.NET objects Access fields, properties, methods and events on objects Helps overcome some limitations in Dex Direct access to alternate data sources ADO.net

28. EXAMPLE

29. SANSCRIPT PROCEDURES Library resources How to add references Understanding metadata How to define metadata on procedures

30. LIBRARY RESOURCES

31. ADDING REFERENCE VIA IMPORT STATEMENT

32. ASSEMBLY LOCATIONS Registered in the Global Assembly Cache (GAC). In the same folder as the.set file (runtime) or application dictionary (Dexterity). In the same folder as Dynamics.exe (runtime) or Dex.exe (Dexterity).

33. FOR MORE INFORMATION… #1 resource is the Dexterity Help.NET Interop chapter under Scripting Various blog articles in the Dynamics GP community https://community.dynamics.com/gp

34. UNDERSTANDING METADATA

35. SCRIPT PROPERTIES CAN BE QUERIED Within the same dictionary: Script_GetSystemProperty and Script_GetUserProperty From another dictionary: Script_GetSystemPropertyByName and Script_GetUserPropertyByName

36. SCRIPT METADATA ServiceEnabled: Is the procedure exposed to service calls? If TRUE – Exposes procedure to be called via service Exposes procedure to security

37. SCRIPT METADATA CONTINUED… ServiceAction and ServiceCustomAction These properties determine which HTTP method is used to call a given procedure. ServiceAction offers the following selections: Get (which maps to HTTP GET) GetList (which also maps to HTTP GET) Create (which maps to HTTP POST) Update (which maps to HTTP PATCH) Delete (which maps to HTTP DELETE) Custom (which maps to HTTP POST)

38. SCRIPT METADATA CONTINUED… ServiceURITemplate Template example in Dynamics dictionary: “Inventory/Items({itemName})” Maps to the URL: "…/Dynamics/Inventory/Items(Surface3)” This targets a procedure and binds the value “Surface3” as a parameter named “itemName”.

39. SCRIPT METADATA CONTINUED… ServiceRawRequest Advanced feature that disables our request parsing Permits (and requires) developers to handle those steps on their own. https://community.dynamics.com/gp/ Service Based Architecture – Raw (4/21/2015) Service Based Architecture – Service Context (3/24/2015)

40. DEBUGGING – WHERE TO BEGIN? Successfully launch Dynamics GP client Verify active directory account linked to GP user Ensure user has security to service operation Verify that the “Ping” operation is successful

41. DEBUGGING TOOLS Launching Dynamics GP Script log SBA logging Trace messages SQL Profiler

42. SERVICE BASED ARCHITECTURE LOGGING \ProgramData\Microsoft Dynamics\GPSvc\Logs

43. TURNING LOGGING ON For all requests (TenantConfiguration.xml): true For individual request (header of request): GP-Server-Logging: true For login scripts and login process (TenantConfiguration.xml): true

44. THE KEY WHEN DEBUGGING: Any request that is made is assigned a Correlation ID cc0afdd0fafa43adb9def6a0c9c67ab4 This will also be included in all associated logs

45. ERROR HANDLING IsServiceMode() Implemented through TRACE object in Dexterity Initiated in initial service procedure Setup for use from all code during the session Uses TRACE composite

46. MORE INFORMATION ON ERROR HANDLING https://community.dynamics.com/gp/b/dynamicsgpengineeringteamblog/archiv e/2015/02/12/service-based-architecture-error-handling.aspx https://community.dynamics.com/gp/b/dynamicsgpengineeringteamblog/archiv e/2015/02/12/service-based-architecture-error-handling.aspx Includes details on new functions as well as code examples

47. HANDY DEVELOPMENT TOOL - POSTMAN https://www.getpostman.com/features

48. BUILDING AND DEPLOYING Run the DAG Tool (Dictionary Assembly Generator) to create assemblies Deploy assemblies into the correct folder Visual Studio Tools addins go to Addins folder Service Procedure Assemblies go to the Dynamics install folder (Application.Dynamics.Metadata.dll) Non-addin assemblies go to the Dynamics install folder

49. Approaches for Building Mobile Applications

50. SECTION OVERVIEW Understand the four most common approaches for building cross platform apps Understand the pros and cons of each approach Be able to choose the most appropriate approach for your app

51. MOST IMPORTANT THING YOU WILL HEAR: Choose your approach based on the requirements of your customers and the needs of your app

52. APPROACH #1: WEBSITES Pros:  Not in the app stores  No end user configuration  No version mismatches  Largest selection of tools and tech Cons: Not in the app stores Same look and feel across platforms No access to platform APIs

53. APPROACH #2: NATIVE APPS Pros:  Get look and feel of each platform  Performance (if done right)  Best debugging experience  Native APIs Cons: Cost ( x platforms) Requires knowledge of multiple platforms in the engineering team Maintenance Redundancy (x platforms)

54. NATIVE APPS: WINDOWS 8.1 Developed in Visual Studio Uses.NET/XAML, HTML/JS, or C++ If using.NET, can share code with Windows Phone 8 through use of portable class libraries (PCLs) Emulator does a good job of matching actual platform

55. NATIVE APPS: ANDROID Developed in Eclipse or ADT (soon Android Studio) Windows OR Mac Written in Java Better to use real devices for development Wide variety of screen size and OS modifications. Takes a number of steps to set up a dev environment

56. NATIVE APPS: IOS Must be developed on a MAC xCode IDE Very good simulators Can share code between iPad and iPhone Must have an Apple Developer license (not free) to run on device or deploy to app store

57. APPROACH #3: CROSS COMPILE/COMMON RUNTIME A common set of code that is compiled on one platform but can be run on others.

58. WHAT IS XAMARIN? Started with Mono – use C# code on Unix MonoTouch – Mac Mono for Android – Linux Evolved into Xamarin in 2011 “Delight Developers” Very rapid development Over 1000 new developers per day

59. HOW IT WORKS “Depending on the platform, produces a native app (eg. iOS) or an integrated.NET application and runtime (eg. Android)… iOS – C# is ahead-of-time (AOT) compiled to ARM assembly language. The.NET framework is included, with unused classes being stripped out during linking to reduce the application size. Android – C# is compiled to IL and packaged with MonoVM + JIT’ing. Unused classes in the framework are stripped out during linking. The application runs side-by-side with Java/Dalvik and interacts with the native types via JNI. Windows Phone – C# is compiled to IL and executed by the built-in runtime, and does not require Xamarin tools. Designing Windows Phone applications following Xamarin’s guidance makes it simpler to re-use the code on iOS and Android. “ Xamarin Whitepaper, Understanding the Xamarin Mobile Platform http://developer.xamarin.com/guides/cross- platform/application_fundamentals/building_cross_platform_applications/part_1_- _understanding_the_xamarin_mobile_platform/

60. ADDITIONAL INFORMATION From http://xamarin.com/platformhttp://xamarin.com/platform

61. EXAMPLES IN XAMARIN From http://xamarin.com/formshttp://xamarin.com/forms

62. XAMARIN PROS AND CONS Pros: Native look and feel Code Sharing (75-100%) Visual Studio integration (can use your favorite tools) C# - Full.NET support 3 rd Party.NET libraries Automated tests with significant code coverage (go to http://xamarin.com/resources/videos and watch the keynote session 70:50. It’s Amazing!) http://xamarin.com/resources/videos Cons: You should know specifics of each platform Cost MSDN Discount (30-50% off) 90-day trial http://xamarin.com/msdn

63. APPROACH #4: HYBRID APPS An app created using a combination of native and web application elements

64. HYBRID APPS - CORDOVA http://cordova.apache.org Uses JavaScript APIs on Windows 8 Uses Web Browser control on other platforms Provides access to underlying platform Provides a plugin API to create reusable code Several plugins available from Apache for common functionality

65. CORDOVA PROS AND CONS Pros:  Has support for ~15 different platforms  Almost 500 plugins on Cordova site  Open source tool with large community  Visual Studio support  Code easily translates to web Cons: Not all devices have same level of HTML support Later versions are better

66. MOST IMPORTANT THING YOU WILL HEAR: Choose your approach based on the requirements of your customers and the needs of your app

67. OUR CHOICE FOR BUILDING APPS: CORDOVA Why: 1.We wanted a presence in the app stores. 2.We may migrate some of the assets to web apps in the future. 3.We wanted a common look and feel. (Windows 8) 4.Cost of licensing Xamarin. 5.Xamarin was less mature when we investigated it for building apps.

68. Questions