The Lyftron Provider for FedEx uses five pieces of information in order to authenticate its actions with the FedEx service.
- Server: This controls the URL where the requests should be sent. Common testing options for this are: "https://gatewaybeta.fedex.com:443/xml", "https://wsbeta.fedex.com:443/xml", "https://gatewaybeta.fedex.com:443/web-service", and "https://wsbeta.fedex.com:443/web-service"
- DeveloperKey: This is the identifier part of the authentication key for the sender's identity. This value will be provided to you by FedEx after registration.
- Password: This is the secret part of the authentication key for the sender's identity. This value will be provided to you by FedEx after registration.
- AccountNumber: This valid 9-digit FedEx account number is used for logging into the FedEx server.
- MeterNumber: This value is used for submitting requests to FedEx. This value will be provided to you by FedEx after registration.
- PrintLabelLocation: This property is required to use the GenerateLabels or GenerateReturnLabels stored procedures. This should be set to the folder location where generated labels should be stored.
The Cache Database
Many of the useful task available from FedEx require a lot of data. To ensure this data is easy to input and recall later, the Lyftron Provider for FedEx utilizes a cache database to make these requests. You must set the cache connection properties in order to use the Lyftron Provider for FedEx:
- CacheLocation: The path to the cache location, for which a connection will be configured with the default cache provider. For example, C:\users\username\documents\fedexcache
As an alternative to CacheLocation, set the combination of CacheConnection and CacheProvider to configure a cache connection using a provider separate from the default.
Connecting Through a Firewall or Proxy
HTTP Proxies
To connect through the Windows system proxy, you do not need to set any additional connection properties. To connect to other proxies, set ProxyAutoDetect to false.
In addition, to authenticate to an HTTP proxy, set ProxyAuthScheme, ProxyUser, and ProxyPassword, in addition to ProxyServer and ProxyPort.
Other Proxies
Set the following properties:
- To use a proxy-based firewall, set FirewallType, FirewallServer, and FirewallPort.
- To tunnel the connection, set FirewallType to TUNNEL.
- To authenticate, specify FirewallUser and FirewallPassword.
- To authenticate to a SOCKS proxy, additionally set FirewallType to SOCKS5.
Troubleshooting the Connection
To show provider activity from query execution to network traffic, use Logfile and Verbosity. The examples of common connection errors below show how to use these properties to get more context. Contact the support team for help tracing the source of an error or circumventing a performance issue.
- Authentication errors: Typically, recording a Logfile at Verbosity 4 is necessary to get full details on an authentication error.
- Queries time out: A server that takes too long to respond will exceed the provider's client-side timeout. Often, setting the Timeout property to a higher value will avoid a connection error. Another option is to disable the timeout by setting the property to 0. Setting Verbosity to 2 will show where the time is being spent.
Working with FedEx
The primary functionality of the Lyftron ADO.NET Provider for FedEx 2019 lies in its stored procedures, which interact directly with the available services for FedEx. However, many of these stored procedures rely on information stored in the provider's tables. These tables must be populated by the user and will contain all of the information that certain stored procedures will need. Among the most important stored procedures that will rely on these tables are CalculateRates, GenerateLabels, GenerateReturnLabels, and SchedulePickup. Among the tables that the stored procedures will rely on are Senders, Recipients, Packages, and Shipments. See the queries below for an example of some basic preparation needed for use of the GenerateLabels stored procedure:
INSERT INTO Senders (SenderId, FirstName, LastName, Phone, Address1, City, State, ZipCode, CountryCode) VALUES (1, 'John', 'Doe', '336-773-0111', '101 Some Street Dr', 'Chapel Hill', 'NC', '27517', 'US')
INSERT INTO Recipients (RecipientId, FirstName, LastName, Phone, Address1, City, State, ZipCode, CountryCode) VALUES (1, 'Jane', 'Doe', '336-111-0377', '343 Bad Traffic Rd', 'Raleigh', 'NC', '27609', 'US')
INSERT INTO Packages (PackageId, Weight, Length, Width, Height) VALUES (1, 34.3, 48, 24, 12)
INSERT INTO Packages (PackageId, Weight, Length, Width, Height) VALUES (2, 13.37, 24, 24, 24)
INSERT INTO Shipments (ShipmentId, SenderId, RecipientId, PackagingType, PackageId) VALUES (1, 1, 1, 'YOURPACKAGING', '1,2')
Once the needed input data is present, one can execute a stored procedure like GenerateLabels by running an Execute statement. The example below will use the data provided in earlier insert examples:
EXECUTE GenerateLabels ServiceType = 'FedEx_Ground', ShipmentId = 1
In addition to the input tables are tables that will accumulate the output of subsequent runs of a stored procedure. Among these tables are LabelHistory, RateHistory, and TrackHistory. A user may query these tables at any time to review the contents of successful stored procedures. Additionally, a user may join them with related a input table such as Recipients or Packages.
All of the tables will be stored in an underlying database in the local machine. The database's exact location will be determined by the CacheConnection connection property. For more information on all of the available tables, stored procedures, and the relationships between them, see the Data Model.