Configuration

In the ConfigConnect table, we will configure which systems we interface with, and what their connection strings are. There are two columns "ConnectCode" and ConnectDesc that serve no purpose only to provide additional information about the connection. For the Repete connection for Zeigler, these were both set to "Repete CNX".

We added code that will skip attempting to connect to the repete web services if the ConnectCode is set to "Test". When this is set, a dummy interface will be created on the web services that acts more like a pass-through to test our code without requiring a running Repete service.

Execution

With this test interface configured, we can now test the "Send" and "Receive" features without encountering errors. The drawback is that the test interface is limited in what it reports back. Here's what we can expect:

On Send:

• The Ticket ID always starts at 1 and increments by one.

• The Ticket number is always "NOREPETE"+ the ticket id.

• The receipt id and number are copied from the stage record.

On Receive:

• The lot number is always "TEST_LOT".

• The actual amount produced is always 11.11.

• Cancelled is always "false".

We can always go back and add features to the test interface to make it robust, for the purpose of hitting our sprint goals we needed to compete an mvp to step through the code and review our changes.

This process should not be used as a suitable replacement for acceptance testing against an actual Repete service! Until we perform those tests, we will not know how changes will affect the Repete service. This configuration should only be used to test changes internally up to the point that we are prepared to perform these types of tests with Repete, knowing that these tests can take some time to schedule, coordinate and perform.