Thursday, December 20, 2018

YubiKeys are neat, but have very limited the moment.

By Steve Endow

TL;DR: If you're a typical computer user, save your money and do not purchase U2F keys at the moment.  The technology is promising, but adoption is still so limited that it probably doesn't make sense for most people to use U2F on just one or two accounts.

January 2019 Update:  A security researcher has developed a tool that can intercept logins and 2FA codes through a man-in-the-middle attack.

This type of attack can apparently defeat most, if not all code based 2FA systems.  The article only mentions that the tool "is inefficient against U2F-based schemes that rely on hardware security keys."  I am not sure if author did mean inefficient, or if he meant ineffective, but I don't think U2F tokens would prevent the browser from authenticating with a YubiKey with the MITM in place.  This YubiKey article explains that U2F prevents authentication with a fake phishing site, but does not appear to directly address the MITM proxy attack used by the Modlishka tool, which accesses the real Google site.

If anyone has information indicating that U2F validates the URL and / or can prevent a MITM proxy attack, I would love to read about it.

I read about physical USB security keys quite a while ago, but it wasn't clear to me exactly how they worked and I couldn't fully understand the value that they provide.

They go by various names:  'security key', 'USB security key', U2F, or FIDO.  And then there are specific brand names for the keys, such as YubiKey (by Yubico) and Titan Security Key (by Google).

I had previously considered trying one, but couldn't figure out what I would use it for, until last month when Troy Hunt wrote an article on how he researched Google's new Advanced Protection Program and how it uses U2F.

The article is very informative and speaks well to how easy it is to setup the U2F keys.

Shortly after, I read some announcements claiming that Microsoft had added YubiKey support to Microsoft logins. Awesome, right? (I failed to read the fine print)

So I decided to buy some and give them a try.

The reviews I read about Google's Titan keys were mixed. While they are more economically priced, the key fob version is apparently cheap plastic that can fall apart or break if dropped.

So I decided to pay more and get the YubiKey version, which appears to be much higher quality.  And that's where the first issue becomes obvious.

Friday, November 30, 2018

eConnect Performance: Using GetNextDocNumbers vs taGetNext stored procedures

By Steve Endow

This one is definitely an obscure topic that nobody is asking about.

But hey, I was curious.

I was researching whether the eConnect GetNextGLJournalEntryNumber could handle a heavy load, and whether it would throw any errors when issuing lots of JE numbers.

Interestingly, I was unable to break it.  I was able to get one SQL exception error when running my test while also trying to get a new JE number in the GP Journal Entry window, but I was unable to reproduce that error.

This image shows 3 instances of my load test application simultaneously retrieving a total of 3,000 JE numbers over about 45 seconds.

3,000 JE Numbers

 public string GetNextJENumbereConn()  
   GetNextDocNumbers getNext = new GetNextDocNumbers();  
     string nextJE = getNext.GetNextGLJournalEntryNumber(IncrementDecrement.Increment, ConnectionStringWindows());  
     return nextJE;  
   catch (Exception ex)  
     throw ex;  

Testing just 1 instance of my load tester, I saw that it took about 16 seconds to generate 1,000 JE numbers using the eConnect method.

So, naturally, I wondered what the performance would be if I called the stored procedure directly.

Thursday, November 29, 2018

How long does it take to import Dynamics GP GL JEs with Analytical Accounting?

By Steve Endow

I recently did some tests to see how long it takes to import GL Journal Entries with large numbers of line items.

Those test results were fairly consistent, and showed that eConnect does a pretty good job of importing JEs with a large number of lines.  Only 8 seconds to import a JE with 2,000 lines seems pretty good to me, as I suspect most customers don't import JEs that large.

For anyone who is familiar with Dynamics GP integrations, the next obvious question is how eConnect handles imports of GL JEs when there is Analytical Accounting data involved.

From experience, I know that GL JEs with AA do not import terribly quickly or efficiently.

Here are the results of importing a single JE with varying line counts.  Every line in the JE has one AA code assigned.

100 lines:  3-8 seconds
200 lines:  3-9 seconds
500 lines:  9-17 seconds
1,000 lines:  21-47 seconds 
2,000 lines:  174-222 seconds

There are two obvious differences when you add Analytical Accounting codes to your GL JE import.

First, they take much, much longer.  A standard JE with 500 lines takes 2 seconds, but when you add AA, that same JE takes 9-17 seconds.

A standard JE with 2,000 lines takes 8 seconds, but when you add AA, that same JE takes 174-222 seconds.

HUUUUUGE decrease in import performance.

The second issue is the incredible variance in import times for the single JEs with AA data.  When importing the standard JEs, the import times were completely consistent.  Over 10 runs, I might have seen a 1 second variance, if any.

In this test with AA data, I imported the same JE at least 10 times for each line count, and you can see how different the times are.  The durations seem almost random.  The import times did not gradually increase or decrease--they would just increase on one run, and then decrease on the next.

The times varied from 89% to 200%, which is pretty wild.  I don't know how a stored procedure could have so much variance in performance from one run to the next.  If it wasn't such a nightmare to trace the activity from the eConnect procedures, I'd look into it.

So there you have it.  If you have to import transactions with Analytical Accounting data, you have been warned.  It seems that the eConnect procs for AA do not perform well.

Steve Endow is a Microsoft MVP in Los Angeles.  He is the owner of Precipio Services, which provides Dynamics GP integrations, customizations, and automation solutions.

You can also find him on Twitter and YouTube

How long does it take to import a Dynamics GP GL Journal Entry with LOTS of lines?

By Steve Endow

I received a question about the performance of eConnect when importing large GL Journal Entries, such as a JE with 1,000 lines.

In some prior eConnect / GP load testing, I had only imported JEs with up to 500 lines, so I didn't know the answer.

I just fired up my Batch Load Test import tool and tested some eConnect imports of GL JEs with lots of lines.

Here's what I found.  Your import times may vary depending on your environment, but this is some baseline data to consider.

Importing a single JE with these line counts took:

500 lines:  2 seconds
1,000 lines:  4 seconds
2,000 lines:  8 seconds
4,000 lines:  16 seconds
8,000 lines:  31 seconds
10,000 lines:  39 seconds
15,000 lines:  54 seconds
20,000 lines:  77 seconds

So it looks like eConnect can pretty easily import a standard JE with quite a few lines without any issues.

CAN you import a JE with 20,000 lines?  Yes.

SHOULD you import a JE with 20,000 lines?  I would not recommend it as a routine process.  Break up the data into more manageable JE sizes.  If nothing else, it will make reconciliations and research more manageable.

Note that this is a standard GL JE without Analytical Accounting.  In my experience, eConnect performance for a JE with AA is horrible.  Definitely keep your JEs small and your batches small when importing with AA data.

Steve Endow is a Microsoft MVP in Los Angeles.  He is the owner of Precipio Services, which provides Dynamics GP integrations, customizations, and automation solutions.

You can also find him on Twitter and YouTube

Friday, November 16, 2018

My source code control is better than yours!

By Steve Endow

Today I received an email from someone who had just inherited a GitHub account from a former employee.  He asked, "What do I do with this?"

His organization is not a "development" shop.  They support business systems, ERP systems, SQL Servers, SharePoint, PowerApps, SSRS, etc.  They don't code C# and JavaScript and Python.

So the GitHub repositories under this account were being used to store various files that are ostensibly "source code", but they were not Visual Studio projects with 6 branches and 5 developers flinging code around.  They were files like SQL scripts.

One question was: How do I access and work with SQL scripts in GitHub?  Can I use SQL Server Management Studio to access the files in GitHub?

Interesting question.  I don't think SSMS can work with GitHub, but...

At GPUG Summit 2018 in Phoenix, Jonathan Cox demonstrated during the SQL Server shootout that VS Code can be used to work with SQL scripts, and it can also work with GitHub.  So in theory, you could use VS Code to work with SQL scripts in GitHub.

But what about the other file types that are not related to VS Code?

Thursday, November 15, 2018

.NET code to create a Dynamics GP batch with eConnect

By Steve Endow

I just posted a story about how I discovered that sometimes I need to explicitly create Dynamics GP batches using eConnect in order to control the batch posting date.

Here's the code that I used.

First, I check to see if the batch exists.

 public static bool BatchExists(string database, int series, string batchSource, string batchID)   
     SqlParameter[] sqlParameters = new SqlParameter[3];  
     sqlParameters[0] = new SqlParameter("@SERIES", System.Data.SqlDbType.Int);  
     sqlParameters[0].Value = series;  
     sqlParameters[1] = new SqlParameter("@BCHSOURC", System.Data.SqlDbType.VarChar, 15);  
     sqlParameters[1].Value = batchSource.Trim();  
     sqlParameters[2] = new SqlParameter("@BACHNUMB", System.Data.SqlDbType.VarChar, 15);  
     sqlParameters[2].Value = batchID.Trim();  
     string result = DataAccess.ExecuteScalar(database, CommandType.Text, commandText, sqlParameters);  
     int recordCount = Convert.ToInt32(result);  
     if (recordCount > 0)  
       return true;  
       return false;  
   catch (Exception ex)  
     Log.Write("An unexpected error occurred in DataAccess.BatchExists: " + ex.Message, true);  
     return false;  

If the batch does exist, I make sure to update the posting date.

Sometimes you have to explicitly create Dynamics GP Batches with eConnect

By Steve Endow

You just can't know everything.

Maybe I never took the time to look at this one field when using that particular Dynamics GP batch posting setting, and never knew about this quirk.

Maybe I did know about this quirk at some point over the last 12 or 13 years working with eConnect, but forgot about it.

Either way, I didn't know about it when I needed to know about it.

Last week I had a call with a customer to try and troubleshoot a weird posting date issue.  They import a bunch of AP Invoices every Monday morning into dozens of batches, review the batch that Monday or Tuesday, and then post the batch.  Simple, right?

But when they were reconciling the GL for their month end close, they were seeing AP Invoice transactions post to prior weeks and prior fiscal periods.  An invoice imported on November 5 posted to October 30.  Another invoice imported on November 5 posted to November 1.

It was weird.

We looked at their GP posting settings for Payables Transaction Entry, and it looked pretty normal.

Typical Batch Posting Date

The customer is using the Posting Date from the Batch.  Okay, so that rules out an issue with the invoices posting based on the Transaction posting date.

But, that doesn't explain why invoices imported at the same time on Monday morning would post to different dates.

Troubleshooting a Dynamics GP SQL Posting Error

By Steve Endow I recently had a call with my friend Windi Epperson to troubleshoot an odd SQL error that was occurring when posting a Dyna...