Asper School of Business University of Manitoba Systems Analysis & Design Instructor: Bob Travica System interfaces Updated: November 2014

3510 Systems Analysis & Design * Bob Travica2 of 10 Outline System interface concept Electronic Data Interchange eXtensible Markup Language Rules for system inputs Rules for system outputs

3510 Systems Analysis & Design * Bob Travica3 of 10 System interface concept 1) Interface with no or minimal participation of users AND 2) Destination is another system, not user (System-to-system link; Inputs & outputs exchanged b/w systems).* Examples: Inputs from other systems & external databases Automated inputs (e.g., bar code reader) Outputs to other systems & external databases Note: In contrast to book, reports are part of user interface (see slides for the previous class).

3510 Systems Analysis & Design * Bob Travica4 of 10 Technologies for system interfaces - From EDI to Internet of Things Electronic data interchange (EDI) input/output files (More...)More... Automatically formatted text files that represent business documents Since 1960s Auto industry big user Can link to electronic funds transfer (EFT) Both sender and receiver must use same EDI system. Was complex, expensive; cheaper Internet-based solutions today.

3510 Systems Analysis & Design * Bob Travica5 of 10 eXtensible Markup Language eXtensible Markup Language (XML) input/output files Text files with embedded markup that describes content Since late 1990s Sender and receiver share definition of content (Data Type Definition) Simple, cheap Security issues

3510 Systems Analysis & Design * Bob Travica6 of 10 XML example

Internet of Things (IoT) An expandable network of devices connected via the Internet to support remote control, automation, and new services at work, home, and in settlements Systems Analysis & Design * Bob Travica7 of 11

3510 Systems Analysis & Design * Bob Travica8 of 10 Identifying system interfaces System Sequence Diagram can indicate system interfaces

3510 Systems Analysis & Design * Bob Travica9 of 10 Rules for system inputs 1. Must come from a trusted source 2. Be secure (encryption) 3. Be validated for accuracy (values’ range, data type, completeness, algorithms) 4. Capture data close to the source 5. Use automatic entry and avoid human involvement as much as possible electronic input rather than manual reentering of data (e.g., bar-code scanner, radio frequency identifier)

3510 Systems Analysis & Design * Bob Travica10 of 10 Rules for system outputs System output must go to a right address and be secure (encryption)

3510 Systems Analysis & Design * Bob Travica11 of 10 Encryption and decryption Single-key encryption/decryption Key sharing complicated with many trading partners and in B2C e-commerce

Encryption and decryption 3510 Systems Analysis & Design * Bob Travica12 of 11 Sender (Client) can generate a private shared key for the session, encrypt it by Server’s public key, and send it to Server. Receiver (Server) can send Digital Certification issued by Certifying Authority and encrypted by CA’s private key, to get authenticated by Client. Client's browser usually has CA’s public key built in and thus decrypts the certificate. Double-key encryption/decryption

3510 Systems Analysis & Design * Bob Travica Encryption and decryption Double-key encryption/decryption 4. Client sends its public key to the Server. Connection is secured from that point on as both will encrypt messages with public keys. 2. Receiver (Server) sends Digital Certification issued by Certifying Authority (CA) and encrypted by CA’s private key, to get authenticated by Client. Possible secure communication process: 1. Sender (Client) requests Receiver’s (Server) authentication and secure connection. 3. Client's browser decrypts message using CA’s public key built into Client's browser. Or: Either side generates a private key for the session, encrypts it by the other side’s public key, & sends it over. Connection is secured as in single private key encryption model.