E1 Install Guide
This Data Access Studio (DAS) guide provides comprehensive information for installing and licensing DAS. This manual describes downloading DAS from the Download Center of the ReportsNow website and installing it to your dedicated DAS server. These instructions apply to the following JDE E1 releases:
- E1 8.9
- E1 8.10
- E1 8.11
- E1 8.12
- E1 9.0
- E1 9.1
- E1 9.2+
To successfully install and run Data Access Studio, your system must meet the following minimum requirements.
Data Access Studio Server
- Windows Server 2012 or greater
- 2 processor cores per 20 clients (1 processor core per 20 users
- Automator requires at a minimum 1.5 additional processor cores per queue
- 4 GB RAM per 20 clients (2GB per 20 users minimum)
- Use of server-side summarization requires a minimum 4 GB RAM per 20 clients
- Automator requires a minimum of 2GB additional memory per queue
- .NET Framework v4.8 or greater
Internet Information Services (IIS) 8.0 or greater
ASP.NET 4.8 feature found under Web Server>Application Development when managing roles for Windows Server.
Note that older versions of Windows Server OS will display older ASP.NET versions such as 4.6 or 4.7 even though these options will install ASP.NET 4.8 if .NET Framework 4.8 is installed on the server.
- Windows Authentication feature found under Web Server>Security when managing roles for Windows Server
- Full EnterpriseOne client install Xe or higher
For External Data sources:
- Appropriate 32-bit or 64-bit drivers for the targeted databases
Microsoft Excel 2013, 2016, 2019, or 2021. Excel Office 365 not supported.
Some of these Excel versions also require a minimum OS level) Please see the current knowledge base article regarding Excel certification.
Data Access Studio Client
- Microsoft supported edition of Windows 10 or Windows 11
- 4 GB RAM (2 GB Minimum)
- .NET Framework v4.8 or greater
- Microsoft Excel 2013, 2016, 2019, 2021, or Office 365
Microsoft Edge (version 87 or later)
The following browsers are not supported, however have been known to work with appropriate Microsoft ClickOnce plug-ins:
- Mozilla Firefox
Downloading and Installing/Upgrading DAS
Follow these steps to download the latest version of Data Access Studio.
Download DASUpdate.exe from our Download Center to the DAS server by clicking the Download DAS8 button.
If this is just an upgrade, and you have a Web deployment, please stop the DAS Automator service, then kill any DASWorker.exe processes before continuing. If you are a DAS mobie customer and have DAS mobie hosted on the same server as your DAS web server, please also download the MOBIEPortal.zip file (click the Download Mobie button) to the same directory as DASupdate.exe so that the installer can detect it during the installation.
Run the DASUpdate.exe you just downloaded to your DAS server and click Setup.
Please review the End User License Agreement, and if you accept the terms please click the “I Accept the Agreement” option and click Next.
Sign into JDE EnterpriseOne using an environment that is part of the EnterpriseOne client installation on the DAS server (for example, DV920 or PD920).
If this is the first time you are installing Data Access Studio, the JDE User ID provided here must have permissions to create and generate the “FDASPROP” table in your system data source.
Sign into JDEdwards.
If you do not see the EnterpriseOne (E1) sign in, you either do not have the JDE E1 dev client installed or you are a JDE World customer. If you are on JDE World, please refer to the Data Access Studio install guide for JDE World customers
Select the Advanced checkbox only if you wish to unzip the setup files to a directory; otherwise the files will be placed in the user’s temp directory. If you intend to install DAS software on other additional servers (e.g. a dedicated Automator server, or multiple DAS servers) or a Citrix deployment, then select “Advanced” and specify a network share location to make it easier to install on the other servers.
The FDASPROP table is the main storage table for Data Access Studio. This is the table where DAS stores layouts, published reports, user preferences, etc. DASUpdate.exe creates this table in your system data source to ensure that DAS users have access to FDASPROP regardless of the environment selected when signing into DAS.
Because there is only one FDASPROP table for your entire enterprise, you do not have to worry about environments promotion (e.g. DV->PY->PD). After DASUpdate.exe creates FDASPROP, it then creates an OCM mapping for FDASPROP. This way DAS will always know where FDASPROP is located regardless of the signed-in environment.
If you are applying an update/upgrade, the installer will skip the FDASPROP generation screen as it will detect that this table already exists. In this case you will see the following window:
The summarized installation plan is displayed. Click Next.
If the JDE User ID failed to create this table, you will be prompted to enter database credentials. Please enter the database credentials to create the table and click Next.
The installer will generate the search item cache. This step could take several minutes.
Click Next once the search completes and you see the Deployment installation succeeded window.
Once you have created the FDASPROP table, you may deploy DAS in one or more of the following ways:
Web - Your users are located in a Wide Area Network (WAN). Users run DAS from a web page link hosted by IIS (Internet Information Services). DAS consumes resources on the DAS Web server, the user’s workstation and the database.
Citrix - In Citrix deployment, your users do not have a JDE E1 Full client and are typically located on a WAN. Once installed and published on Citrix, your users access the Citrix server and run DAS. DAS consumes resources from the Citrix server and database.
Web Install Procedure
Use Web Server configuration to deploy Data Access Studio across a Wide Area Network. This configuration is the most generic way to deploy DAS as it will work within your local area network (LAN) and in your WAN. ReportsNow recommends that you use a dedicated machine to host Data Access Studio.
Do not use your JD Edwards deployment server as the DAS Web server. The DAS Web Server should be in close network proximity to the E1 database.
Once you click Next at the install summary window, you will see this window with “Launch Data Access Studio setup on this machine” selected. Click Finish.
After you click Finish, you will see the installer welcome screen. Click Next.
Accept the License Agreement and click Next.
Click Install to begin the installation.
Once the installation is complete, click Finish.
After DAS is installed on your Web server, you need to run a tool to convert it from a Workstation/Standalone mode to a Web mode. Go to your Windows start menu and find the "Web Setup" application under your "Data Access Studio" application folder (or "Test Environment Web Setup" under "Data Access Studio Test Environment" if you are installing a test installation of Data Access Studio).
If this is an upgrade, it will automatically prompt you to run Web Setup. Click Yes to continue.
The Web Setup utility will be displayed that allows you to change various settings for your DAS server installation. Default settings are generally the recommended ones, though one setting you may need adjust is for the Maximum Connections. The default setting is for 20 connections. To accommodate more users, increase Maximum Connections. For example, if you have a total of 50 licenses, you may want to change that to 70. For more information on all the settings, please review the tables below.
Click Setup Web when finished to apply the settings.
Server Communication section
This section includes settings used when clients make their initial connection to IIS on the server as well as negotiating their session.
Field Description Enable SSL If checked, clients will connect to their DAS server using encrypted SSL communication (recommended). Note that this option will only be available if IIS is configured with an SSL certificate that is bound to the default Web site. Please consult Microsoft documentation for instructions on installing SSL certificates in IIS. Server Name or IP The server network name used by clients to connect to the DAS server. This must be a network name recognized both by the server and by client machines. It may be a partially or fully qualified DNS name or an IP address. Using Load Balancer Check this only if you are using a load balancer and the network address of this particular server must be specified independently of the network name specified above. This Server's Name This setting is only visible if Using Load Balancer is checked and is used to specify the network address of this particular server rather than the load balanced name that is specified under Server Name or IP.
The Enable SSL setting also dictates whether AES-256 encryption will be performed for DASWorker session communication.
DASWorker Communication section
Once the DAS server negotiates a session for a client, further client communication is routed to a DASWorker (or DASWorker64) process dedicated to that session on the DAS server. The following settings control the behavior of those session communications.
Field Description Channel Select tcp or http. tcp performs better, but cannot traverse firewalls that perform network address translation. Selecting tcp is incompatible with the "Clients connect via firewall" setting below. Compress May be used to compress data to improve performance over very slow network connections. Please note that the performance cost of compression and decompression may be greater than the cost of network communications, so this option should only be used over very slow network connections. Start Port The port that the DAS Server will start with to assign client connections Maximum Connections The maximum number of allowed client connections. Client sessions will fail to be created if all ports are used. Note that external data connections can cause a second session to be created for an individual DAS client. IMPORTANT! If you run a firewall, make sure the range of Start Port to Start Port + Maximum Connections is open. The default setting is 20. Increase this value to be at least the number of licenses you purchased. Lease Timeout The number of seconds a DASWorker process will stay alive after a client session has disconnected. When the client session ends abnormally, this timeout ensures that the corresponding server executable gets cleaned up. Using the default timeout is recommended. IMPORTANT! If your users experience timeouts when running DAS, try increasing the value of this parameter. Sign-in Timeout Once a user signs in, this is the number of seconds the server has to create a session for the user. If users have trouble signing in, try increasing this value. Otherwise, the default timeout is recommended. Idle Timeout If set to a non-zero amount, this will set the number of minutes the software will allow the client to run before automatically shutting it down. For instance, if this is set to 30 minutes, then if the web client is idle for 30 minutes, the software will issue a 20 second idle warning and then shutdown the client -- thereby freeing the concurrent license and any system resources the client held. This will not disconnect any users with unsaved work. Clients connect via firewall This should be checked in the following cases: (1) Clients connect via a firewall through which network address translation occurs, or (2) The server has multiple network interfaces and the primary interface is not the one known by clients. NOTE! This setting is not compatible with the tcp channel setting (http must be used).
This section includes settings for configuring how client users authenticate to the DAS server.
Field Description Type Simple (default), Windows, Okta, or AzureAD (Azure Active Directory). Selecting authentication other than Simple allows for single sign-on. Please see the Single Sign-on section for more detail. Default Environment In single sign-on configurations, this field is required and denotes the JD Edwards environment that users will be logged in to if no environment is specified in the invocation URL.
Miscellaneous settings used during installation.
Field Description Reinstall Automator Service When checked, Web Setup will reinstall the Windows service that is responsible for running the DAS Automator (DAS Automator Service). Note that using this option also has the side effect of allowing you to change the Windows service user under which all DAS related services are run. Regenerate Encryption Key DAS uses an encryption key stored in a file in the Windows %ProgramData%\ReportsNow\Key (encrypt.key) to encrypt command line password information. For DAS test installations, this file resides in %ProgramData%\ReportsNow\TestEnv\Key. These folders should only be readable by administrators and the DAS service user. Use this checkbox to regenerate the encryption key. Mixed-case password Check this box if you are using LDAP security or other login authentication that accepts passwords that are not all uppercase.
You will be prompted with the following window. We recommend specifying a service account user that is a simple Windows domain user without administrator rights. Note that if you are installing both a production and a test installation of DAS on the same server, the service user for both installations must be the same. Prior to release 8.0.13, DAS required the service user to be part of the DAS server machine's Administrators group, though beginning with release 8.0.13, this is no longer recommended for improved security.
If this is an upgrade, you will not be prompted for this. It will continue to use the existing service account. (One exception to this is when upgrading from a release prior to 8.0.13 to a release that is 8.0.13 or greater.)
When the install is complete you will see “Setup Succeeded”.
(For mobie customers and mobie Upgrades only): If you are a DAS mobie customer and mobie is hosted on the DAS web server, and you initially downloaded the DASUpdate.exe and MOBIEPortal.zip file in the same directory, it will bring up the following window. The WebSetup and mobie configuration windows may both come up at the same time. It does not matter which order they are configured. If the MobiePortal.zip is not in the same directory as DASUpdate.exe then you will need to select it. Click the visual assist (…) for the installation zip file location and pick the MOBIEPortal.zip file you downloaded, then click Configure.
To run DAS from a browser, the URL to use will depend on the settings chosen in Web Setup, but should take one of the following forms:
URL Web Setup options
https://<Server Name or IP>/DASWeb/
SSL enabled production install
https://<Server Name or IP>/DASWebTest/
SSL enabled test install
http://<Server Name or IP>/DASWeb/
SSL disabled production install
http://<Server Name or IP>/DASWebTest/
SSL disabled test install
The first time clients connect to a new version of DAS, they will be prompted with a Microsoft ClickOnce dialog where they must click Run to download the client application files necessary to run DAS. Once DAS is loaded, the client will cache the downloaded information so that future sign-ons go faster.
Single sign-on is the mechanism that allows invocation of DAS with credentials supplied from an alternate identity provider. DAS supports several methods of single sign-on, each of which is detailed in this section.
JD Edwards Trusted Node Configuration
To support Windows and Okta single sign-on methods, the DAS server needs to be a Trusted Node in your JD Edwards configuration. When switching the authentication type to Windows or Okta, the Web Setup tool will prompt for a JD Edwards login in order to validate trusted node configuration settings as well as LDAP settings in the case of a Windows Active Directory configuration.
If the DAS server has not yet been configured as a trusted node, you will be presented with the following dialog:
Each of the three panes represents an element of the configuration that must be satisfied. The first element is the trusted node configuration within JD Edwards. The above image shows what is a typical default configuration in JD Edwards where there are no trusted nodes defined. This means that JD Edwards will use the less secure default _GLOBALNODE configuration rather than a configuration based on trust between individual servers. The Launch JDE SSO App button in this dialog will launch the JD Edwards SSO configuration application in a browser to allow for configuration of the DAS server as a trusted node.
Do not alter the default unless you have read the Oracle documentation about trusted node configurations carefully. Changing from the default JD Edwards _GLOBALNODE configuration to a configuration with named Enterprise Server nodes will break existing connections from other JD Edwards servers unless they are also configured as trusted nodes.
You may, however, accept the warning and default configuration to proceed with configuring DAS.
The middle pane generally does not require any action as the Web Setup tool in normal circumstances is able to locate necessary components from your JD Edwards development client installation in order to update the CLASSPATH setting in your server's jde.ini file.
The right-most pane is used to save the file %ProgramData%\ReportsNow\Key\tokengen.ini to facilitate the generation of JD Edwards authentication tokens from the DAS server. In the default _GLOBALNODE configuration, the Node Password field is disabled and simply clicking on the Save button will save the necessary file. If you have created a JD Edwards node configuration, the DAS server node will have a password registered in JD Edwards. In that case, the password must be supplied in the Node Password field prior to clicking on Save to save the necessary file.
Once all of the necessary items have been resolved, the OK button of the dialog will be enabled in order to continue on to settings for the particular authentication type.
Windows Active Directory/LDAP
This mode of single sign-on is designed for users that have configured their JD Edwards authentication to use Windows Active Directory as an LDAP provider.
The Web Setup utility will read LDAP configuration settings from your JD Edwards configuration and automatically apply the necessary settings. See JD Edwards documentation for a more complete discussion of configuring LDAP support in JD Edwards.
DAS assumes that the Windows service account user that the DAS server applications run under have sufficient privileges to read directory information from the Active Directory/LDAP server. For this reason, the service account user should be a Windows domain user as opposed to a user local to the DAS server machine.
LDAP single sign-on settings can be seen in the ASP.NET XML configuration file Server\web.config under your DAS installation directory. The LDAP related settings are as follows:
|ldap:Server||The network name of your LDAP server, which is often simply your Windows domain name.|
|ldap:Port||The port to use to connect to your LDAP server. Typically 636 for SSL connections and 389 for non-SSL connections.|
|ldap:USRSRCHBAS||The user search basis for LDAP user queries. Typically something like "DC=mycompany,DC=com".|
|ldap:USRSRCHSCP||The LDAP user search scope (base, subtree, or onelevel). The default is subtree.|
|ldap:USRSRCHATR||The Active Directory attribute that is used to look up the logged on user. Typically this is sAMAccountName.|
|ldap:E1USRIDATR||The Active Directory attribute that represents the JD Edwards user name matching the Windows Active Directory user. This may also be sAMAccountName or a custom attribute name.|
The Web Setup utility presents a dialog with various configuration settings to support Okta single sign-on:
These settings must be filled in based on configuration created in your Okta administration dashboard. In Okta, you must go to the Applications section and click the button to Create App Integration. This will present the following dialog:
Here you will want to select OIDC - OpenID Connect. Then you will want to select Web Application as the Application Type.
On the New Web App Integration screen that follows, you will want to supply the following settings:
|App integration name||A suitable name for your integration, such as "Data Access Studio"|
|Grant type||Authorization Code and Implicit (hybrid) should be checked|
|Sign-in redirect URIs||Here you will want to enter the URL of your DAS server suffixed with DASServer (or DASServerTest for a DAS test installation) followed by authorization-code/callback. For example:
|Sign-out redirect URIs||Not required|
|Trusted Origins||Not required|
|Assignments>Controlled access||This settings allows you to decide how Okta users are assigned to be able to use this app integration. Typically, you would assign users in the same manner that you do for your JD Edwards app integration.|
Once the app integration wizard is complete, you will be taken to a screen that shows the Client ID and Client secret that you will need to record for use in the above DAS Web Setup dialog.
One additional step you will need to take in your Okta configuration is to go to Directory>Profile Editor in your Okta administration panel. After having created the new app integration, you should see a new profile by the name of your app integration suffixed with "User". If you named your app integration "Data Access Studio", the profile would be "Data Access Studio User". Select that profile to edit it. Here you will want to add an attribute that represents the JD Edwards user name of your Okta users. To do this click Add Attribute:
You may name the attribute anything you like, though you may wish to name it the same as the attribute name that you use for your JD Edwards integration. Once you have created the attribute, you need to map an Okta value to this attribute by clicking on Mappings in the profile editor. Here you would select the Okta value that you use for your JD Edwards user name to map to the new attribute:
Now that all of your Okta settings are complete, you can return to the DAS Web Setup Okta Settings dialog to enter the following settings:
|Authority URL||The URL to your Okta tenant - typically of the form
|Client ID||The Client ID recorded when you created the Okta app integration.|
|Client secret||The Client secret recorded when you created the Okta app integration.|
|User Claim Name||This is the name of the Okta attribute created in the Okta profile editor for the app integration. In our example, this was set to jde_uid.|
|Server Base URL||This is typically filled in correctly by default. It represents the URL to the DAS server application.|
After applying the configuration with Web Setup, when users attempt to log in to DAS using the DAS launch URL, they will be presented with an Okta login dialog where they can supply their Okta credentials to log in.
It is not presently possible to launch DAS from the Okta login panel as the authentication must be initiated from the DAS application. You must use the DAS launch URL (pointing to the DAS server) in order to launch DAS.
One prerequisite for using Okta integration with DAS is that client machines must have the Microsoft Edge WebView2 runtime installed. See Microsoft's download page for more information and links to installers. This runtime is often already installed on client machines that use Office 365 and other Microsoft applications.
Azure Active Directory (AzureAD)
The Web Setup utility presents a dialog with various configuration settings to support Azure Active Directory single sign-on:
These settings must be filled in based on configuration created in your Azure Active Directory administration portal. In Azure Active Directory, you must go to App registrations and click the button for a New registration. This will present the following:
Here you will want to give a name for your application registration (e.g., "Data Access Studio"). The choice of account types would typically be the default "Single Tenant" option. In the "Redirect URI" section, you will want to select "Web" for the platform type and supply the URL found in the Server Base URL field in Web setup's Azure Active Directory (AD) Settings dialog (see above).
Once you click on Register, you will be taken to the Overview page of your app registration that will show the Directory (tenant) ID and the Application (client) ID to be filled in the Azure AD Settings dialog.
In the Authentication section of your Azure App Registration, you also need to select ID tokens (used for implicit and hybrid flows) under Implicit grant and hybrid flows.
For the Client Secret, you will need to go to Certificates & secrets in your Azure Active Directory portal, click on New client secret to generate a new client secret. Note that the secret will only be displayed when first created, so you will want to immediately copy the secret to the DAS Web setup configuration.
The User Claim Name setting is typically left blank as it is typical for the JD Edwards long user ID to match the UPN name of users in Azure Active Directory. If, however, an alternate claim is defined in Azure Active Directory for use as the JD Edwards user ID, that claim name may be specified in the settings dialog.
After applying the configuration with Web Setup, when users attempt to log in to DAS using the DAS launch URL, they will be presented with a Microsoft Azure login dialog where they can supply their credentials to log in.
One prerequisite for using Azure Active Directory integration with DAS is that client machines must have the Microsoft Edge WebView2 runtime installed. See Microsoft's download page for more information and links to installers. This runtime is often already installed on client machines that use Office 365 and other Microsoft applications.
In this configuration, it is necessary to stop the DASServerAppPool (or DASServerAppPoolTest for a test installation) in IIS prior to performing JD Edwards maintenance and then restarting the AppPool when maintenance is complete.
User Login Experience
When single sign-on is configured, users are logged in automatically with the default environment specified in the Web Setup tool.
To log in with a different environment and/or role, the user must supply this information in the invocation URL.
For example, if the default DAS invocation URL for your installation is
https://DASSERVER/DASWeb/, to specify a
and environment such as PY920 instead of the default, the user would use the following link
To add a role, the user would use a link like the following
By default, users may also bypass the single sign-on experience and supply their
JD Edwards user and password. This can be done by supplying the -nosso URL
option. For example:
https://DASSERVER/DASWeb/?-nosso will log on with the DAS login screen
where the user must supply their JD Edwards user name and password.
Some administrators may wish to disallow the capability to bypass single sign-on. To disable, the DAS server administrator must make a change on the server to disallow this capability.
In the DAS server installation directory, you will find an XML file called Remoting.txt. You must edit this
file with a text editor and add an entry at the bottom of the file before the
</DASRemotingConfiguration> closing tag that looks as follows:
To make this setting effective, the DAS server administrator must stop and restart the IIS application pool for the DAS server. The name of this AppPool is DASServerAppPool (or DASServerAppPoolTest for a DAS test installation).
Once completed, users will no longer be able to use the -nosso URL option to bypass signing in with single sign-on.
Citrix Install Procedure
There are two primary variations on how to install DAS in a Citrix environment:
Citrix-only approach: Install DAS completely on the Citrix server with all of its necessary prerequisites (in particular, the JDE client install).
Hybrid approach: Install DAS on a web server (see Web Install Procedure), and then install the client on the Citrix server to connect to the DAS web server.
Citrix-only approach procedure:
Perform the Citrix install for each server where you want DAS. The Citrix server must have a full JDE E1 client install.
Prior to installing DAS, it is necessary to change the server to install mode by running “change user /install” from the command prompt. After the installation, you must run “change user /execute” to bring it out of install mode.
Once you click Next at the install summary window, you will see this window. Click Finish.
Accept the License Agreement term and click Next.
Click Install to begin the installation.
Once the installation is complete, click Finish.
You can now publish Data Access Studio to your users.
The executable location is the location from Step 4:
C:\Program Files (x86)\ReportsNow\Data Access Studio\DataAccessStudio.exe
Hybrid approach procedure
Installing DAS on Citrix using the hybrid approach assumes that you have already completed a normal DAS Web client installation on another server. In this configuration, the Citrix server acts very much like a Web client with one important difference. The difference is that the DAS client should be installed and published on the Citrix server as opposed to publishing the Web link that Web client users would use when accessing the DAS Web server. Publishing the Web link on the Citrix server has couple of problems:
Citrix on Windows operating systems prior to Windows Server 2012 R2 do not support Microsoft .NET ClickOnce deployment, which is what is used by DAS when connecting via the Web URL.
Resource consumption is much higher, because each user has their own copy of the DAS application as opposed to using one shared installation.
To install the DAS client on the Citrix server using the Hybrid approach, you must first copy the installation/setup files from the DAS Web server to the Citrix server. The location of the install files will be in the directory that you specified in Step 7 (under Downloading and Installing/Upgrading DAS section).
Once you have copied over the installation files, it is necessary to change the server to install mode by running “change user /install” from the command prompt. After the installation, you must run “change user /execute” to bring it out of install mode. Run Setup.exe and install DAS.
Lastly, copy the file called Remoting.txt that can be found in the DAS installation directory on your DAS Web server (typically C:\Program Files (x86)\ReportsNow\Data Access Studio\Remoting.txt) to the DAS installation directory on your Citrix server.
At this point, you will want to publish the DataAccessStudio.exe application on the Citrix server to your Citrix users.
Maintenance Considerations for Hybrid approach
To maintain this installation, the version of DAS installed on the Web server must be kept in sync with the version installed on the Citrix server. Any time an updated installation is performed on the DAS Web server, the Citrix server should also be updated using the mechanism described above.
Similarly, the Remoting.txt file should also be kept in sync. If any changes to configuration options in the DAS WebSetup utility are made on the DAS Web server, these will result in changes to the Remoting.txt file and the Remoting.txt file should again be copied to the Citrix server.
Some customers opt to simply copy the complete DAS Web server’s installation directory to a known, stable location on the Citrix server rather than use the Setup.exe to install. This mechanism also works fine, though DAS will then not appear with its current version number as an installed application on the Citrix server.
Requesting and Importing License Key
Sign into Data Access Studio as DAS Administrator.
If you are a new customer, you will be prompted to Request License, Import License, or Cancel.
Click on Request License.
Copy and paste the information and email it to email@example.com
Once we receive the request, ReportsNow will generate a 30-day key and email you the license file. Upon receipt, save the file to a local folder and click Import License to import the file.
As of 7.0.52 and greater, for new installs, you no longer need to create a DASADMIN user in JDE to access the Data Access Studio as an administrator. The JDE user ID that was used to install DAS will automatically be designated to be the new DAS administrator. You can now assign other users to be a DAS Administrator as well by giving them the “DAS Administrator” permission under Work With Security.
Setting up DAS Automator
DAS allows authorized users to schedule reports to run on defined Automator servers. The output of these reports can be emailed, saved to the file system, or even saved to a database (via our mobie® product). Please verify that Excel is installed on the DAS web server.
Sign into DAS as DAS Administrator
Click Admin > Email Providers
Click New Provider and configure it to reference your email system.
Click Test Email. This should send out a test email (to the email address listed in the ‘From Email’ field. If it is setup correctly, it will display a dialog box saying it was successful sending the email.
Click OK > Save > Close
Click Admin > Automator to bring up the Automator Server control.
Click Add Server. This will bring up the Server Setup window.
Server Name: Name of the server
Network Address: Network identification of the server with the two ‘//’ in front. Usually, this is the same name as the server, but it can be an IP address.
Run Limit: Inherit (uses the Run Limit specified in Global Settings).
Check the Enabled box and click OK.
Click Add Queue button.
Give a name for your Queue and check the Enabled box.
Click the Start button under the Server section.
If you get any errors, try restarting the DAS Automator service in the Windows Services.