CardExchange Technical Webinar
•Download as PPT, PDF•
0 likes•167 views
This webinar is intended as a look at more advanced techniques that can be used within CardExchange. It assumes some understanding of the basic usage of the software, but assistance can be given on all aspects if required.
Recommended
More Related Content
Similar to CardExchange Technical Webinar
Similar to CardExchange Technical Webinar (20)
More from Michael Miller
More from Michael Miller (9)
Recently uploaded
Recently uploaded (20)
CardExchange Technical Webinar
- 1. CardExchange Interactive Demonstration Presented by: Mark Phelan – Group Development & Integration Manager Start Time: 9.15am Shortly before the start time shown above, the presenter will arrive. Please hold until then.
- 2. o Can you hear me? • If not, please advise via the question panel o Questions + feedback • Send in via the panel as you think of them • Invite input at the end of each Section • Off-line discussions o Presentation Slides: Available on request Formalities
- 3. Contents • Mappings • Managing data • Custom designer functions with Python • Contactless encoding • Your questions This webinar is intended as a look at more advanced techniques that can be used within CardExchange. It assumes some understanding of the basic usage of the software, but assistance can be given on all aspects if required.
- 4. Mappings A mapping is the link for a variable data item. Mappings fall in to one of these categories: Visible An item that appears on the card layout Storage Something that is written to the DB during printing Magnetic Data written to a magstripe on the card Contactless Information written to a smartcard during printing
- 5. Mappings Each data item needs to be configured so that CardExchange knows what information should be recorded or displayed. CardExchange can use the following data sources: •.NET function (some external code to produce data) •Concatenation of various data •Database column •Manual data entry •Environment variable (such as the username / PC name) •Counter •Print Date •Variable Image/Photo •Card Preview Image
- 6. Mappings .NET Functions Relies on vb.net code, which can be called to perform external actions when the card is previewed or printed. Examples of code we have written: -To calculate an expiry date based on the current date and the yeargroup of a student -Produce a specific barcode format for a library system -To check if a user’s photo exists and if not download it from an external system and store it on the disk. The use of scripts in this way is normally reserved for more complex tasks that cannot be carried out with the built-in functionality.
- 7. Mappings Manual Data Entry This mapping type has a couple of different uses: -Prompting for some information from the operator prior to printing -Setting a fixed value to be stored in the database for all cards -Prompting for confirmation prior to each print It’s useful for creating “adhoc cards” where a database may not be in use – eg for visitors/contractors the details can simply be keyed in.
- 8. Managing Data Database views vs. tables Views are typically “read-only” and may require the use of triggers to store any information, or a separate table. Dropdown selections for data items Where a choice of data on the card needs to be made the operator can be given a dropdown box to select from. Storing a print counter Useful for keeping track of how many cards have been issued to each user. Writing to multiple databases If cards are used with disparate systems separate links can be created – only one database can be the “read” source. Working without a database of users
- 9. Managing Data Dropdown selections for data items You need a data source configured for this to work, however it can simply be a table in a file or DB that records printed cards. Dropdown options can be stored in a table/database … or simply a pre-defined list
- 10. Managing Data Storing a print counter To track issue numbers for each user, a column is required to hold the counter for each user. When configuring the database connection, you must select a column to be incremented each time a card is printed as a Storage Item:
- 11. Managing Data Working without a DB of users Where cards need to be produced on-the-fly, there are numerous ways to quickly create cards without having a pre-defined list of user details. -Use manual data entry - Prompts for relevant data items, some of which can be configured to not be left blank -Configure the DB to add new records - Adding rows to the table isn’t quite as intuitive but allows for storing of information for future re-printing -Alter the card design - Requires launching the card designer software and making changes, then saving and printing.
- 12. Custom designer functions Uses a .NET implementation of Python called IronPython - Not all Python functions are supported - Allows use of some .net assemblies - Perfect for calculating or manipulating data Examples of usage: Changing the format of text eg. “surname, forename” to “forename surname” Calculating an expiry date Changing colours of objects/text based on data values Calculating checksums/barcodes
- 13. Custom designer functions When writing Python observe the use of indentations (tabs or spaces) as it’s crucial to the correct execution of the code. Any syntax errors will be reported in the “content” tab of the properties window. Simply click any text object that is linked to a script to view any errors. To show text based on the output of a script, create a text object and set the value to be “Script”. Match the script name to the function name:
- 14. Custom designer functions A simple example - First initial from a forename def firstChar(text): return text[:1]
- 15. Custom designer functions Insert a new text field Set the type to “Script” Configure the value to be FunctionName(VariableData) Configure the named variable to link to a database field
- 16. Custom designer functions Highlighting if a user is under 18 based on their date of birth: This function will return the words “U18” to be shown on the card, or nothing if the individual is over the age of 18. import datetime, time, System def isUnder18(dob): dob = System.DateTime.Parse(dob) today = System.DateTime.Today age = today.Year - dob.Year if (age < 18): return "U18" else: return None
- 17. Custom designer functions Generate an Expiry Date: def expiryDate(): import datetime now = datetime.datetime.now() from datetime import timedelta diff = datetime.timedelta(days=(365*2)) future = now + diff return future.strftime("%d/%m/%Y")
- 18. Custom designer functions Reversing order of name def FlipName(name): nameTokens=name.split(',',1) return (nameTokens[1]+' '+nameTokens[0]).strip()
- 19. Custom designer functions Using functions to change colours Use the “Expressions” tab to customise attributes for objects such as colour, border, font, etc. Create a function that returns the appropriate data, such as an HTML colour code (32-bit ARGB, eg #FFFF0000 for red) def u18Colour(dob): dob = System.DateTime.Parse(dob) today = System.DateTime.Today age = today.Year - dob.Year if (age < 18): return "#FFFF0000" else: return "#FF000000"
- 20. Contactless Encoding Mifare Classic & DESfire - Overview Classic – memory is split in to “sectors”, each sector contains a series of blocks. Each block is 16 bytes. In 1K cards there are 16 sectors, each contains 4 blocks. One of these holds the access keys giving 48 usable bytes for data in each sector. 16 sectors x 4 blocks x 16 bytes = 1024 bytes = 1K In 4K cards there are 32 sectors with 4 blocks and the last 8 sectors contain 16 blocks. (32 sectors x 4 blocks x 16 bytes) + (8 sectors x 16 blocks x 16 bytes) = 4096 bytes = 4K
- 21. Contactless Encoding Mifare Classic & DESfire - Overview DESfire – memory is managed by using applications, each having a unique ID. Think of each application as a folder on a hard drive. Each application then has numbered files, each contains data. There are various encryption methods that can be utilised, along with numerous keys to protect the card, application, and files and provide read or write access. Card can have 2K, 4K or 8K of memory Mifare Classic cards typically have a 4 or 7-byte serial number hard- coded (regardless of 1K or 4K capacity). Mifare DESfire cards have a 7-byte serial number.
- 22. Contactless Encoding How CardExchange manages encoding Most printer manufacturers now fit OEM modules from 3rd parties to handle the encoding of cards during printing. CardExchange communicates with the encoders via the Windows Smartcard Service. All encoding is performed via USB connection, so the printer must be local to a Windows PC. CardExchange offers a “Print Server” to allow remote clients to print & encode via the network.
- 23. Contactless Encoding How CardExchange manages encoding Contactless encoding has two main tasks: -To read the chip serial number -To write to the card’s internal memory (or to read from it if the cards are pre-encoded) The chip serial number is often used as a unique identifier for each card and cardholder. It is useful to record this information at the time of print (even if it is not to be used immediately) as it will ensure future use of the card is simple. The cards internal memory can be utilised to store data – such as a unique ID for each individual (such as a staff/student number) or other details like their name or date of birth.
- 25. www.ait.co.uk/support Email: support@ait.co.uk Call: 0113 273 0300 Thank You For more information, how-to guides and support:
Editor's Notes
- Good morning everyone and thanks for joining today’s session. My name’s Mark and I’m the integration manager at AIT, and I’ve been working with CardExchange for over 5 years now, and the purpose of this webinar is to to share some of the more advanced functionality that it can offer. Today’s webinar is designed to give some details and demonstration of the more advanced features of CardExchange, and highlight some of the things that it can do to enhance the use of cards in your organisation.
- First and foremost I hope everyone can hear me. – CLICK If you can’t hear me then please notify me via the question function in the control panel. CLICK. Due to the large number of people attending today&apos;s webinar and for the comfort of other listeners I will be running the session in Listen Only mode in order to minimize any background noise. If you have any questions please note them down as they come up and submit them via the questions function on the go to webinar panel and we will answer at the end of each section. These will be treated anonymously or alternatively we can take any individual in-depth discussions that may be required offline. CLICK. We will also make available a recorded version of todays webinar so you can re-visit any of the information in future. NEXT SLIDE
- We have a mixed audience today from various different sectors, so I’m going to try and keep the webinar fairly generic but I’m going to assume that you already have some exposure to CardExchange so that I can demonstrate the more advanced features of the software. There’s a few snippets of code in the slides ahead which are to be used as a reference – if you don’t understand them then please don’t panic, I’ll be explaining what they do and if you would like further details or assistance with implementing any of the things I’m going to cover then you can get in touch with us after the webinar. – CLICK So the key areas that I’ll be talking about today are: Mappings – what they are and how they work Managing data – The best way to use the information you’ve got and capturing information Custom designer functions – This shows some ways you can make the card design more dynamic and responsive Contactless encoding will briefly look at the card technologies we usually work with and how CardExchange works when it comes to cards. We’ll finish up with any questions you may have or and I’ll do my best to answer them, or if there’s any configuration that you’d like me to try and demonstrate I’d be more than happy to do so.
- OK, so let’s look at Mappings. In a nutshell a mapping is the link for CardExchange to handle a piece of variable information. There are 4 categories – Visible, Storage, Magnetic and Contactless. Each category provides the facility to read or write information to a specific area of the card – either the physical print, or something behind the scenes such as writing data to the chip or the magnetic stripe.
- Each mapping item can be linked to a different source of data, I’ve listed the most common examples on the slide but there are a couple of others such as biometric fingerprint capture or a signature written on a digital pad. It’s just telling CardExchange what to do with various pieces of information. Mappings are used a lot as we saw on the last slide, they’re the things that tie the card and the data together and can get quite complicated for more advanced setups where there’s a lot of information on and in the card.
- One type of mapping is a .net function. This is a piece of code that can be executed to perform a routine, and optionally return some data for CardExchange to deal with. I’ve listed a couple of examples for projects I’ve worked on previously where I’ve had to write some code to generate data outside of CardExchange. I’m not going to go in to the details about .NET today or we’ll be here for weeks, but it’s a comprehensive programming language that is widely used for a lot of Windows applications.
- Manual data entry pretty much does what it says on the tin. It requires the operator to input details prior to printing the card. I’ll put together a quick example card now which doesn’t use a database connection but instead allows the operator to key in a name and employer for a visitor card – DEMO … OK, so that’s an overview of mappings in CardExchange. They’re not too scary once you understand what they do and hopefully that quick example has shown how visible mapping items work in a card design.
- Next I’m going to look at managing data within CardExchange. Again, I’ll try to keep this quite high-level but if you have any queries then send a question via the control panel and I’ll get back to you at the end of the presentation. So, when working with a database we’ll often be provided with what’s called a “view” – this is a reall yuseful way of drawing in information from various different tables or even different databases and presenting it as a single entity. For example you may have a table which holds personal details of a user such as their name, but then a different table has information relating to their enrolment or employment details so you can use a view to join this information together. This works well in most cases, however if we’re wanting to write information back somewhere then we’d have to give consideration to where this is going to go. Because a view is often “virtual” and comprised of data from multiple sources its not always possible to write back to it. Often we’ll read from a view and write back to another separate table. Dropdown menus can speed up data entry for operators – there may be a situation where a choice needs to be made for some information on a card which can only be done manually. By presenting a drop-down menu instead of a text box entry time is reduced and keying-errors can be prevented. A print counter is useful for keeping track of how many cards each user has had printed. Writing to multiple databases is one of the strengths of CardExchange and it can be used to simultaneously update different systems, which may also have different database technologies. Finally, something I already covered earlier with the demo is working without a database – often useful for producing cards quickly for guests or new staff.
- Dropdown menus can be configured in a couple of different ways – they need to link to a specific column in a table of data, so unfortunately can’t be used without a database of some kind – but even if you’re creating manual cards it’s useful to store the details at the time of print for future use. We can either create a dropdown by querying a table – the table would typically just have two columns, once showing the list for the dropdown box and the other giving the actual value that will be displayed or stored in to the database after selection. The list can also just be keyed or imported from a text file if it doesn’t exist in a database already.
- A print counter should not be confused with a global counter. The print counter increments a count for each individual, which reflects how many times they have had a card printed. A global counter is stored within the card design and just counts up every time a card is printed. It’s useful for numbering cards or keeping track of total number of prints, but should not be used for tracking issue numbers for each user. It’s set up as a storage item, and once this is completed the update happens automatically and the storage item does not appear in the mappings list since it’s already “mapped”.
- As we touched on earlier it’s possible to use CardExchange without a database at all. There’s a few ways to alter the information shown on the card but the best way is the use of manual data entry that I demonstrated earlier, though it’s not the only way it’s certainly the simplest.
- We’re now going to step up a gear and look at how we can alter the card design programmatically with CardExchange. This enables the card design to be altered automatically at the time of print. Python is another programming language, much like .NET, and although I’m not going to go in to the in’s and out’s of it I will provide examples that can be used or adjusted in future. It’s very popular with the Raspberry Pi platform which you may have heard of as a way of engaging students in programming. I’ve highlighted a few simple things that can be done with the use of custom functions and I’ll show you how they work.
- Just a few things to note first… Python is very fussy about indentations. It’s crucial that each line matches up, and usually if it follows a loop or a statement which ends with a ‘colon’ then it’ll need indenting on the line after. If you make a mistake, the error will be shown in the “content” box for any of the text objects that link to a custom script to help troubleshoot the issue. To use a custom function simply create a text object as you would for any other text, and set the data type to be “script”. Type the function name in, followed by brackets to call it. If the function requires some external input then you’ll need to put some variable names in the brackets, separated by commas if necessary. I’ve shown a very simple example on the screen of a function called myFunction that returns the word “Hello”. I created a text object and mapped it to the script called myFunction() and the text returned by it was displayed.
- So the last example was pretty useless really, you’d never write a function that just returned fixed text as it’s easier just to add the text directly to the design. In this example we do something a bit more useful and we strip all but the first character of a word and display that. This is useful where a database may contain the full name of an individual but you want to print just the initial on the card.
- Creating this dynamic text is easy – just create a text field, set it to be a Script, give it the script name and optionally any variables that may be required by the function. Again, this may seem a bit complicated but we’re happy to help if you’d like some assistance in getting this setup.
- So this time we’re going a bit more complicated – we want to highlight if an individual is under 18 on a card. What this function does is receives the date of birth of the user from a database column, and then does some maths compairng it to the current date to look at whether the person is over 18. If they’re not then the letters “U18” are returned and printed on the card, otherwise nothing is returned. You can see there are some libraries that get imported at the top of the code – this is often necessary with Python so that it knows what functionality is required. DEMO
- Sticking with dates, this function calculates an expiry date 2 years in to the future and prints it on the card. This is constantly updated so that cards are always valid for exactly 2 years from the time of print. I’ve used a “concatenation” field here to put the word Expires before the date – this is just a way of merging two pieces of information together (in this case some fixed text followed by the calculated date) DEMO
- This is quite a weird function that I had to write for a customer who’s database always stored the names as surname, firstName. It splits the name in half (by the comma) and then re-orders the words and strips off any spaces. It took a bit of figuring out but seems to work well! DEMO
- The last thing that we use functions for is to alter the appearance of a card, rather than the content. As a simple example here I’ve modified the bit of code that works out if a user is under 18, and it instead returns a colour code – highlighting text in red if the user is under 18.
- If I haven’t completely lost you with that last bit then I wanted to quickly touch on the main contactless technologies we encounter and just give a quick overview of them before moving on to your questions. So Mifare Classic is a card technology that’s a very open platform, in use in a lot of places and is very cost-effective. It comes in a couple of different flavours – 1K and 4K and this simply refers to the amount of memory inside the card for storing data. The memory is split up in to sectors and blocks, the amount of which depends on the size of card you opt for but 1K and 4K are the most common. 1K cards are now becoming more difficult to source and 4K is a “drop-in” replacement for these which should not require any changes to card-reading hardware in most instances where we are just reading the unique ID from a card.
- The next step up from Classic is DESfire EV1. This card technology is a bit more intelligent than classic and manages the internal memory much more effectively. It also offers far superior protection of the data with communications between the card and reader being encrypted. It’s the technology that’s used for the Oyster card around London and is becoming more popular as an upgrade from Mifare Classic cards in other sectors. In addition to the various memory sizes available for cards there is also a choice of 4-byte or 7-byte unique IDs. 4-bytes of data for the unique ID permitted around 4 billion card numbers – which is a lot, but eventually, worldwide they ran out of numbers and in some cases the card manufacturers just started over again so the numbers cannot be guaranteed to be unique. Remember that this technology isn’t just used in smartcards – but also in parcel tracking and other asset management systems so the numbers can quickly add up. To overcome this the 7-byte unique ID was created allowing something ridiculous like 72 quadrillion combinations – if that’s even a real number?!
- To talk to the cards CardExchange usually goes via the Windows Smartcard service in order to communicate with the card reader. This being the case, the printer must be connected to a PC via a USB cable. Most printers have a network port but this can only be used for printing – encoding of cards is not possible through this. Where the printer does need to be removed from the PC, or shared with multiple PCs, there is a component called PrintServer which can handle one or more printers through a “server” PC which other instances of CardExchange can communicate with. This negates the need for the printer to be connected via a USB cable to the operator’s PC.
- And finally, the main purpose of contactless encoding is to prepare the card for use once printed. This is often simply a matter of capturing the card’s unique ID or serial number, but sometimes the card will be prepared for use with a 3rd-party system such as a catering solution or a door access system. Even if, at the time of print, the card is not going to be used for anything other than a visible ID it’s worth capturing the card details so that future use of the card doesn’t require recalling cards or getting users to associate their card to them.
- So that’s enough talking from me, I want to hand over to you and answer any questions you might have. A couple of queries were raised during the slides so I’ll just answer them.. Q: Firstly, do all the features you’ve talked about require special licenses? A: No, not a special license but I am assuming that you’ve got the Ultimate edition of CardExchange – this is what we most often supply as it’s the only version that will support Contactless encoding of cards. Q: Next, what’s the latest CardExchange version and is it possible to upgrade from an older version? A: It depends how old your version is and whether you’ve got an SBS license for more than 1 PC. It might be best to drop us an email with your details and we can see if there’s any costs involved in upgrading you. 9.3 is the latest version and if you’ve got Version 8 or Version 9 as a standalone license I know you can upgrade it for free, but please contact us so we can go through the process with you and make sure everything works as it should. Q: Is there any documentation for the things covered today A: There is a manual available online, which can be accessed by clicking on Service Center in CardExchange and then the Help button. It is quite comprehensive but doesn’t go in to as much detail on many of the aspects I’ve covered today Q: Are the slides available to download? A: Yes, we’ll be uploading the webinar shortly so you can review it at a later date (or if you’re struggling to get to sleep one night!)
- OK well that’s all from me. I hope you’ve found it useful and if you have any other queries once we’re finished then please get in touch with us – the details are on the screen now. Thanks for listening, and I’ll let you get on .