Migrate from Vite to Next.js 15 with SSR
- Replace Vite + React Router with Next.js 15 App Router - Implement i18n with next-intl (URL-based: /de, /en, /sr) - Add SSR/SSG for all pages (48 static pages generated) - Setup Supabase SSR client for auth - Migrate all pages: Home, About, Portfolio, Blog, Contact, Login, Dashboard, Imprint, Privacy, Terms - Add Docker support with standalone output - Replace i18next with next-intl JSON translations - Use next/image for optimized images Co-Authored-By: Claude Opus 4.5 <noreply@anthropic.com>
This commit is contained in:
Claude Opus 4.5
@@ -0,0 +1,175 @@
|
||||
// src/i18n/locales/en/blog/index.ts
|
||||
export const blog = {
|
||||
meta: {
|
||||
title: 'Blog - JTL Integration & Digital Solutions',
|
||||
description: 'Insights and Best Practices on JTL-WaWi, E-Commerce, and Digital Transformation',
|
||||
header: {
|
||||
title: 'Insights & Best Practices',
|
||||
subtitle: 'Insights and Best Practices on JTL-WaWi, E-Commerce, and Digital Transformation'
|
||||
}
|
||||
},
|
||||
posts: {
|
||||
'erp-integration-breuninger': {
|
||||
title: 'ApparelMagic and TradeByte: Analysis of Complex Integrations',
|
||||
date: '2024-02-09',
|
||||
excerpt: 'Detailed analysis of an e-commerce integration between Apparel Magic and Breuninger via TradeByte',
|
||||
category: 'System Integration',
|
||||
tags: ['ERP', 'Apparel Magic', 'TradeByte', 'API Integration', 'Python', 'MariaDB'],
|
||||
coverImage: '/images/posts/erp-integration-breuninger/cover.jpg',
|
||||
content: {
|
||||
intro: {
|
||||
title: 'Apparel Magic meets Breuninger: A Technical Analysis of the TradeByte Integration',
|
||||
description: 'The integration of e-commerce systems with established marketplaces poses unique challenges for companies. In this article, I share my experiences from a complex integration project between Apparel Magic as an ERP system and the Breuninger platform via TradeByte.'
|
||||
},
|
||||
background: {
|
||||
title: 'Project Background',
|
||||
systems: {
|
||||
erp: 'Apparel Magic as an ERP system for product data and inventory management',
|
||||
middleware: 'TradeByte as the middleware for the Breuninger platform'
|
||||
},
|
||||
challenges: {
|
||||
sync: 'Bidirectional synchronization of orders',
|
||||
customers: 'Automated customer creation',
|
||||
delivery: 'Management of delivery notes',
|
||||
inventory: 'Real-time inventory management'
|
||||
}
|
||||
},
|
||||
tech: {
|
||||
title: 'Technical Architecture',
|
||||
components: {
|
||||
title: 'Key Components'
|
||||
},
|
||||
database: {
|
||||
title: 'Middleware Database',
|
||||
description: 'The MariaDB database serves as the central data store for the integration:'
|
||||
}
|
||||
},
|
||||
api: {
|
||||
title: 'API Integrations',
|
||||
apparel_magic: {
|
||||
title: 'Apparel Magic API',
|
||||
description: 'The REST API of Apparel Magic is used for customer creation and inventory management:'
|
||||
},
|
||||
tradebyte: {
|
||||
title: 'TradeByte Integration',
|
||||
description: 'The TradeByte API uses a combination of REST and XML:'
|
||||
}
|
||||
},
|
||||
order_process: {
|
||||
title: 'Order Process',
|
||||
steps: {
|
||||
fetch: 'Regular retrieval of new orders from TradeByte',
|
||||
customers: 'Automatic customer creation in Apparel Magic',
|
||||
process: 'Order processing and status update',
|
||||
delivery: 'Generation and storage of delivery notes'
|
||||
},
|
||||
delivery_notes: {
|
||||
title: 'Delivery Note Management'
|
||||
}
|
||||
},
|
||||
challenges: {
|
||||
title: 'Challenges and Solutions',
|
||||
status: {
|
||||
title: '1. Status Management',
|
||||
description: 'A particular challenge was managing order statuses:'
|
||||
},
|
||||
error_handling: {
|
||||
title: '2. Error Handling and Monitoring',
|
||||
description: 'Robust error handling was essential for production operation:'
|
||||
}
|
||||
},
|
||||
best_practices: {
|
||||
title: 'Best Practices',
|
||||
api: {
|
||||
title: '1. API Communication',
|
||||
items: {
|
||||
retry: 'Implementation of retry mechanisms',
|
||||
errors: 'Careful error handling',
|
||||
logging: 'Comprehensive logging of all communications'
|
||||
}
|
||||
},
|
||||
data: {
|
||||
title: '2. Data Management',
|
||||
items: {
|
||||
storage: 'Central data storage in MariaDB',
|
||||
transactions: 'Transactional security for critical operations',
|
||||
validation: 'Regular data validation'
|
||||
}
|
||||
},
|
||||
automation: {
|
||||
title: '3. Process Automation',
|
||||
items: {
|
||||
customers: 'Automated customer creation',
|
||||
status: 'Automatic status updates',
|
||||
delivery: 'Systematic delivery note management'
|
||||
}
|
||||
}
|
||||
},
|
||||
lessons: {
|
||||
title: 'Lessons Learned',
|
||||
api: {
|
||||
title: '1. API Design',
|
||||
items: {
|
||||
docs: 'Thorough API documentation is essential',
|
||||
auth: 'Understanding of various authentication methods',
|
||||
limits: 'Consideration of rate limits'
|
||||
}
|
||||
},
|
||||
validation: {
|
||||
title: '2. Data Validation',
|
||||
items: {
|
||||
rules: 'Implementation of strict validation rules',
|
||||
edge_cases: 'Careful handling of edge cases',
|
||||
cleanup: 'Automated data cleanup'
|
||||
}
|
||||
},
|
||||
optimization: {
|
||||
title: '3. Process Optimization',
|
||||
items: {
|
||||
automation: 'Continuous improvement of automation',
|
||||
performance: 'Regular performance reviews',
|
||||
monitoring: 'Proactive monitoring'
|
||||
}
|
||||
}
|
||||
},
|
||||
conclusion: {
|
||||
title: 'Conclusion',
|
||||
requirements: {
|
||||
understanding: 'Deep understanding of both systems',
|
||||
implementation: 'Careful implementation of API communication',
|
||||
error_handling: 'Robust error handling',
|
||||
monitoring: 'Continuous monitoring'
|
||||
},
|
||||
results: 'The developed solution successfully processes orders and enables seamless integration between the systems. In particular, automated customer creation and delivery note management have proven to be efficiency boosters.'
|
||||
}
|
||||
}
|
||||
},
|
||||
},
|
||||
ui: {
|
||||
readMore: 'Read More',
|
||||
loading: {
|
||||
posts: 'Loading blog posts...',
|
||||
post: 'Loading blog post...'
|
||||
},
|
||||
errors: {
|
||||
posts: 'Error loading blog posts',
|
||||
post: 'The requested blog post does not exist or has been moved.'
|
||||
},
|
||||
backToBlog: 'Back to Blog',
|
||||
publishedOn: 'Published on',
|
||||
category: 'Category',
|
||||
tags: 'Tags',
|
||||
notFound: {
|
||||
title: 'Post Not Found',
|
||||
message: 'The requested blog post does not exist or has been moved.'
|
||||
}
|
||||
},
|
||||
categories: {
|
||||
'Integration': 'Integration',
|
||||
'Entwicklung': 'Development',
|
||||
'Automatisierung': 'Automation'
|
||||
}
|
||||
} as const;
|
||||
|
||||
export type BlogConfig = typeof blog;
|
||||
export type BlogPost = BlogConfig['posts'][keyof BlogConfig['posts']];
|
||||
@@ -0,0 +1,138 @@
|
||||
// src/i18n/locales/en/blog/posts/erp-integration-breuninger.ts
|
||||
export const erpIntegrationBreuninger = {
|
||||
posts: {
|
||||
erp_integration: {
|
||||
title: "ApparelMagic and TradeByte: Analysis of Complex Integrations",
|
||||
date: "2024-02-09",
|
||||
excerpt: "Detailed analysis of an e-commerce integration between Apparel Magic and Breuninger via TradeByte",
|
||||
category: "System Integration",
|
||||
tags: ["ERP", "Apparel Magic", "TradeByte", "API Integration", "Python", "MariaDB"],
|
||||
coverImage: "/images/posts/erp-integration-breuninger/cover.jpg",
|
||||
intro: {
|
||||
title: "Apparel Magic meets Breuninger: A Technical Analysis of the TradeByte Integration",
|
||||
description: "The integration of e-commerce systems with established marketplaces presents unique challenges for companies. In this article, I share my experiences from a complex integration project between Apparel Magic as an ERP system and the Breuninger platform via TradeByte."
|
||||
},
|
||||
background: {
|
||||
title: "Project Background",
|
||||
systems: {
|
||||
erp: "Apparel Magic as an ERP system for product data and inventory management",
|
||||
middleware: "TradeByte as middleware for the Breuninger platform"
|
||||
},
|
||||
challenges: {
|
||||
sync: "Bidirectional synchronization of orders",
|
||||
customers: "Automated customer creation",
|
||||
delivery: "Management of delivery notes",
|
||||
inventory: "Real-time inventory management"
|
||||
}
|
||||
},
|
||||
tech: {
|
||||
title: "Technical Architecture",
|
||||
components: {
|
||||
title: "Central Components"
|
||||
},
|
||||
database: {
|
||||
title: "Middleware Database",
|
||||
description: "The MariaDB database serves as the central data store for the integration:"
|
||||
}
|
||||
},
|
||||
api: {
|
||||
title: "API Integrations",
|
||||
apparel_magic: {
|
||||
title: "Apparel Magic API",
|
||||
description: "The REST API of Apparel Magic is used for customer creation and inventory management:"
|
||||
},
|
||||
tradebyte: {
|
||||
title: "TradeByte Integration",
|
||||
description: "The TradeByte API uses a combination of REST and XML:"
|
||||
}
|
||||
},
|
||||
order_process: {
|
||||
title: "Order Process",
|
||||
steps: {
|
||||
fetch: "Regular retrieval of new orders from TradeByte",
|
||||
customers: "Automatic customer creation in Apparel Magic",
|
||||
process: "Order processing and status update",
|
||||
delivery: "Generation and storage of delivery notes"
|
||||
},
|
||||
delivery_notes: {
|
||||
title: "Delivery Note Management"
|
||||
}
|
||||
},
|
||||
challenges: {
|
||||
title: "Challenges and Solutions",
|
||||
status: {
|
||||
title: "1. Status Management",
|
||||
description: "A particular challenge was managing order statuses:"
|
||||
},
|
||||
error_handling: {
|
||||
title: "2. Error Handling and Monitoring",
|
||||
description: "Robust error handling was essential for production operations:"
|
||||
}
|
||||
},
|
||||
best_practices: {
|
||||
title: "Best Practices",
|
||||
api: {
|
||||
title: "1. API Communication",
|
||||
items: {
|
||||
retry: "Implementation of retry mechanisms",
|
||||
errors: "Careful error handling",
|
||||
logging: "Comprehensive logging of all communications"
|
||||
}
|
||||
},
|
||||
data: {
|
||||
title: "2. Data Management",
|
||||
items: {
|
||||
storage: "Central data storage in MariaDB",
|
||||
transactions: "Transactional security for critical operations",
|
||||
validation: "Regular data validation"
|
||||
}
|
||||
},
|
||||
automation: {
|
||||
title: "3. Process Automation",
|
||||
items: {
|
||||
customers: "Automated customer creation",
|
||||
status: "Automatic status updates",
|
||||
delivery: "Systematic delivery note management"
|
||||
}
|
||||
}
|
||||
},
|
||||
lessons: {
|
||||
title: "Lessons Learned",
|
||||
api: {
|
||||
title: "1. API Design",
|
||||
items: {
|
||||
docs: "Thorough API documentation is essential",
|
||||
auth: "Understanding of various authentication methods",
|
||||
limits: "Consideration of rate limits"
|
||||
}
|
||||
},
|
||||
validation: {
|
||||
title: "2. Data Validation",
|
||||
items: {
|
||||
rules: "Implementation of strict validation rules",
|
||||
edge_cases: "Careful handling of edge cases",
|
||||
cleanup: "Automated data cleanup"
|
||||
}
|
||||
},
|
||||
optimization: {
|
||||
title: "3. Process Optimization",
|
||||
items: {
|
||||
automation: "Continuous improvement of automation",
|
||||
performance: "Regular performance reviews",
|
||||
monitoring: "Proactive monitoring"
|
||||
}
|
||||
}
|
||||
},
|
||||
conclusion: {
|
||||
title: "Conclusion",
|
||||
requirements: {
|
||||
understanding: "Deep understanding of both systems",
|
||||
implementation: "Careful implementation of the API communication",
|
||||
error_handling: "Robust error handling",
|
||||
monitoring: "Continuous monitoring"
|
||||
},
|
||||
results: "The developed solution successfully processes orders and enables seamless integration between the systems. In particular, the automated customer creation and delivery note management have proven to enhance efficiency."
|
||||
}
|
||||
}
|
||||
}
|
||||
};
|
||||
@@ -0,0 +1,253 @@
|
||||
// src/i18n/locales/en/blog/posts/fullstack-development-timetracking.ts
|
||||
export const fullstackDevelopmentTimetracking = {
|
||||
meta: {
|
||||
title: 'Fullstack Development with Python and React: Architecture of our Time Tracking Solution',
|
||||
date: '2024-02-09',
|
||||
excerpt: 'A technical deep dive into the implementation of a modern time tracking solution',
|
||||
category: 'System Architecture',
|
||||
coverImage: '/images/posts/fullstack-development-timetracking/cover.jpg',
|
||||
tags: ['Python', 'React', 'TypeScript', 'MSSQL', 'System Design']
|
||||
},
|
||||
content: {
|
||||
intro: {
|
||||
title: 'Fullstack Development with Python and React: Architecture of our Time Tracking Solution',
|
||||
description: 'Developing a robust time tracking solution requires not only technical expertise but also a deep understanding of complex business rules and user requirements. In this article, I share our experiences in implementing a modern fullstack time tracking solution with Python and React.'
|
||||
},
|
||||
systemArchitecture: {
|
||||
title: 'System Architecture',
|
||||
frontend: {
|
||||
title: 'Frontend (Next.js + TypeScript)',
|
||||
description: 'The frontend architecture is based on Next.js with TypeScript and follows a component-based approach:',
|
||||
code: {
|
||||
types: `// types/TimeEntry.ts
|
||||
interface TimeEntry {
|
||||
id: number;
|
||||
date: string;
|
||||
checkIn: string;
|
||||
checkOut: string | null;
|
||||
userId: number;
|
||||
status: 'complete' | 'incomplete';
|
||||
}`,
|
||||
component: `// components/TimeEntryForm.tsx
|
||||
const TimeEntryForm: React.FC<TimeEntryFormProps> = ({ onSubmit }) => {
|
||||
const [entry, setEntry] = useState<TimeEntry>({
|
||||
date: new Date().toISOString().split('T')[0],
|
||||
checkIn: new Date().toLocaleTimeString(),
|
||||
checkOut: null,
|
||||
status: 'incomplete'
|
||||
});
|
||||
const handleSubmit = async (e: React.FormEvent) => {
|
||||
e.preventDefault();
|
||||
if (!validateTimeEntry(entry)) return;
|
||||
try {
|
||||
await onSubmit(entry);
|
||||
} catch (error) {
|
||||
console.error('Error submitting time entry:', error);
|
||||
}
|
||||
};
|
||||
return (
|
||||
<form onSubmit={handleSubmit} className='space-y-4'>
|
||||
<DateInput
|
||||
value={entry.date}
|
||||
onChange={(date) => setEntry({ ...entry, date })}
|
||||
/>
|
||||
<TimeInput
|
||||
value={entry.checkIn}
|
||||
onChange={(time) => setEntry({ ...entry, checkIn: time })}
|
||||
/>
|
||||
{/* Additional form elements */}
|
||||
</form>
|
||||
);
|
||||
};`
|
||||
}
|
||||
},
|
||||
backend: {
|
||||
title: 'Backend (Flask + MSSQL)',
|
||||
description: 'The backend uses Flask for the API and MSSQL for data persistence:',
|
||||
code: {
|
||||
models: `# models/time_entry.py
|
||||
class TimeEntry(db.Model):
|
||||
__tablename__ = 'Stundenzettel'
|
||||
id = db.Column('ID', db.Decimal, primary_key=True)
|
||||
personal_id = db.Column('Personal_ID', db.Decimal)
|
||||
datum = db.Column('Datum', db.Date)
|
||||
kommen = db.Column('Kommen', db.Time)
|
||||
gehen = db.Column('Gehen', db.Time)
|
||||
@validates('gehen')
|
||||
def validate_checkout(self, key, value):
|
||||
if value and value < self.kommen:
|
||||
raise ValueError('Checkout time cannot be before checkin time')
|
||||
return value`,
|
||||
routes: `# routes/time_entries.py
|
||||
@app.route('/api/time-entries', methods=['POST'])
|
||||
@jwt_required
|
||||
def create_time_entry():
|
||||
data = request.get_json()
|
||||
user_id = get_jwt_identity()
|
||||
try:
|
||||
validate_time_entry_creation(data, user_id)
|
||||
entry = TimeEntry(
|
||||
personal_id=user_id,
|
||||
datum=data['date'],
|
||||
kommen=data['checkIn'],
|
||||
gehen=data.get('checkOut')
|
||||
)
|
||||
db.session.add(entry)
|
||||
db.session.commit()
|
||||
return jsonify(entry.to_dict()), 201
|
||||
except ValidationError as e:
|
||||
return jsonify({'error': str(e)}), 400`
|
||||
}
|
||||
}
|
||||
},
|
||||
businessLogic: {
|
||||
title: 'Business Logic Implementation',
|
||||
validation: {
|
||||
title: 'Time Entry Validation',
|
||||
description: 'The validation logic ensures that all business rules are followed:',
|
||||
code: `def validate_time_entry_creation(data: dict, user_id: int) -> None:
|
||||
'''Validates a new time entry according to business rules.'''
|
||||
# Check for existing incomplete entries
|
||||
incomplete_entry = TimeEntry.query.filter_by(
|
||||
personal_id=user_id,
|
||||
gehen=None,
|
||||
datum=data['date']
|
||||
).first()
|
||||
if incomplete_entry:
|
||||
raise ValidationError('Cannot create new entry while incomplete entry exists')
|
||||
# Check for time overlap with existing entries
|
||||
overlapping_entry = TimeEntry.query.filter(
|
||||
TimeEntry.personal_id == user_id,
|
||||
TimeEntry.datum == data['date'],
|
||||
TimeEntry.kommen <= data['checkIn'],
|
||||
TimeEntry.gehen >= data['checkIn']
|
||||
).first()
|
||||
if overlapping_entry:
|
||||
raise ValidationError('Time entry overlaps with existing entry')`
|
||||
}
|
||||
},
|
||||
databaseDesign: {
|
||||
title: 'Database Design',
|
||||
description: 'The MSSQL database schema is designed for efficiency and integrity:',
|
||||
code: `CREATE TABLE dbo.Stundenzettel (
|
||||
ID decimal NOT NULL PRIMARY KEY,
|
||||
Personal_ID decimal,
|
||||
Datum date,
|
||||
Kommen time,
|
||||
Gehen time,
|
||||
xStatus int,
|
||||
xBenutzer nvarchar(15),
|
||||
xDatum datetime,
|
||||
xVersion timestamp
|
||||
);
|
||||
CREATE INDEX idx_personal_datum
|
||||
ON dbo.Stundenzettel(Personal_ID, Datum);`
|
||||
},
|
||||
security: {
|
||||
title: 'Security Implementation',
|
||||
authentication: {
|
||||
title: 'JWT Authentication',
|
||||
code: `# auth/jwt_handler.py
|
||||
from flask_jwt_extended import create_access_token
|
||||
def authenticate_user(username: str, password: str) -> str:
|
||||
user = Personal.query.filter_by(
|
||||
Benutzername=username,
|
||||
Passwort=password # In production, use proper password hashing
|
||||
).first()
|
||||
if not user:
|
||||
raise AuthenticationError('Invalid credentials')
|
||||
return create_access_token(identity=user.ID)`
|
||||
}
|
||||
},
|
||||
bestPractices: {
|
||||
title: 'Best Practices and Learnings',
|
||||
points: [
|
||||
{
|
||||
title: 'Data Validation at Multiple Levels',
|
||||
items: [
|
||||
'Frontend validation for immediate feedback',
|
||||
'Backend validation for business rules',
|
||||
'Database constraints for data integrity'
|
||||
]
|
||||
},
|
||||
{
|
||||
title: 'Error Handling',
|
||||
items: [
|
||||
'Structured error messages',
|
||||
'User-friendly error messages in frontend',
|
||||
'Detailed logging in backend'
|
||||
]
|
||||
},
|
||||
{
|
||||
title: 'Performance Optimization',
|
||||
items: [
|
||||
'Indexing of critical database fields',
|
||||
'Frontend caching of time entries',
|
||||
'Lazy loading for historical data'
|
||||
]
|
||||
}
|
||||
]
|
||||
},
|
||||
challenges: {
|
||||
title: 'Challenges and Solutions',
|
||||
timezones: {
|
||||
title: '1. Timezone Handling',
|
||||
description: 'A particular challenge was the correct handling of timezones:',
|
||||
code: `// utils/dateTime.ts
|
||||
export const formatTimeForDisplay = (time: string): string => {
|
||||
return new Date(\`1970-01-01T\${time}\`).toLocaleTimeString('de-DE', {
|
||||
hour: '2-digit',
|
||||
minute: '2-digit'
|
||||
});
|
||||
};
|
||||
export const formatTimeForAPI = (time: string): string => {
|
||||
return new Date(\`1970-01-01T\${time}\`).toISOString().split('T')[1];
|
||||
};`
|
||||
},
|
||||
concurrency: {
|
||||
title: '2. Concurrent Updates',
|
||||
description: 'Handling concurrent updates required special attention:',
|
||||
code: `from sqlalchemy import and_, or_
|
||||
def update_time_entry(entry_id: int, data: dict) -> TimeEntry:
|
||||
entry = TimeEntry.query.filter_by(id=entry_id).with_for_update().first()
|
||||
if not entry:
|
||||
raise NotFoundError('Time entry not found')
|
||||
# Optimistic locking using version field
|
||||
if entry.xVersion != data['version']:
|
||||
raise ConcurrencyError('Entry was modified by another user')
|
||||
entry.gehen = data.get('checkOut')
|
||||
db.session.commit()
|
||||
return entry`
|
||||
},
|
||||
offline: {
|
||||
title: '3. Offline Capability',
|
||||
description: 'For offline functionality, we implemented a service worker strategy:',
|
||||
code: `// service-worker.ts
|
||||
const CACHE_NAME = 'timetracking-v1';
|
||||
self.addEventListener('fetch', (event) => {
|
||||
event.respondWith(
|
||||
caches.match(event.request).then(response => {
|
||||
return response || fetch(event.request).then(response => {
|
||||
return caches.open(CACHE_NAME).then(cache => {
|
||||
cache.put(event.request, response.clone());
|
||||
return response;
|
||||
});
|
||||
});
|
||||
})
|
||||
);
|
||||
});`
|
||||
}
|
||||
},
|
||||
conclusion: {
|
||||
title: 'Conclusion',
|
||||
description: 'Developing a time tracking solution requires careful planning and consideration of numerous business rules. By using modern technologies like Next.js, TypeScript, and Flask, we were able to implement a robust and user-friendly solution.',
|
||||
keyPoints: [
|
||||
'Strict typing with TypeScript',
|
||||
'Comprehensive validation logic',
|
||||
'Efficient database design',
|
||||
'User-friendly error handling'
|
||||
],
|
||||
results: 'The solution has been successfully in use for several months and reliably processes hundreds of time entries daily.'
|
||||
}
|
||||
}
|
||||
};
|
||||
@@ -0,0 +1,204 @@
|
||||
// src/i18n/locales/en/blog/posts/rfid-automation.ts
|
||||
export const rfidAutomation = {
|
||||
meta: {
|
||||
title: 'RFID Label Automation: From Database to Printer',
|
||||
date: '2024-02-09',
|
||||
excerpt: 'A detailed technical analysis of implementing an automated RFID label printing system with Python',
|
||||
category: 'System Integration',
|
||||
coverImage: '/images/posts/rfid-automation/cover.jpg',
|
||||
tags: ['RFID', 'Python', 'ZPL', 'Automation', 'Zebra Printer', 'EPC']
|
||||
},
|
||||
content: {
|
||||
intro: {
|
||||
title: 'RFID Label Automation: From Database to Printer',
|
||||
description: 'In modern logistics and retail environments, efficient and error-free labeling of products with RFID tags is crucial. In this article, I share my experiences implementing an automated solution for generating and printing RFID labels with chip encoding.'
|
||||
},
|
||||
requirements: {
|
||||
title: 'Project Background',
|
||||
points: [
|
||||
'Automatic generation of EPC codes (Electronic Product Code)',
|
||||
'Creation of ZPL code for Zebra printers',
|
||||
'Direct network communication with the printer',
|
||||
'Integration with existing product data',
|
||||
'Error handling and logging'
|
||||
]
|
||||
},
|
||||
implementation: {
|
||||
title: 'Technical Implementation',
|
||||
epcGeneration: {
|
||||
title: 'EPC Code Generation',
|
||||
description: 'The EPC codes are generated according to the SGTIN standard (Serialized Global Trade Item Number):',
|
||||
code: `def generate_encoded_epc(company_prefix, indicator, item_ref, serial):
|
||||
sgtin = SGTIN(company_prefix, indicator, item_ref, serial)
|
||||
return sgtin.encode()`
|
||||
},
|
||||
zplTemplates: {
|
||||
title: 'ZPL Template Management',
|
||||
description: 'ZPL templates were implemented for different label types:',
|
||||
code: `def generate_zpl_code(artikelnr, description, ean, price, material, water_resistance, glass_type, encoded_epc):
|
||||
formatted_price = f'{price:.2f}'
|
||||
return f'''
|
||||
CT~~CD,~CC^~CT~
|
||||
^XA
|
||||
~TA000
|
||||
~JSN
|
||||
^LT35
|
||||
^MNW
|
||||
^MTT
|
||||
^PON
|
||||
^PMN
|
||||
^LH0,0
|
||||
^JMA
|
||||
^PR2,2
|
||||
~SD23
|
||||
^JUS
|
||||
^LRN
|
||||
^CI27
|
||||
^PA0,1,1,0
|
||||
^RS8,,,3
|
||||
^XZ
|
||||
^XA
|
||||
^MMT
|
||||
^PW413
|
||||
^LL531
|
||||
^LS-24
|
||||
^FT150,57^A0N,33,33^FH\\^CI27^FD{artikelnr}^FS^CI27
|
||||
^FT44,86^A0N,21,20^FH\\^CI27^FD{description}^FS^CI27
|
||||
^FT130,141^A0N,50,51^FH\\^CI27^FD{formatted_price} €^FS^CI27
|
||||
^FT167,175^A0N,21,20^FH\\^CI27^FD{material}^FS^CI27
|
||||
^FT185,201^A0N,21,20^FH\\^CI27^FD{water_resistance}^FS^CI27
|
||||
^FT155,227^A0N,21,20^FH\\^CI27^FD{glass_type}^FS^CI27
|
||||
^BY3,2,113^FT73,420^BEN,,Y,N
|
||||
^FH\\^FD{ean}^FS
|
||||
^RFW,H,1,2,1^FD3000^FS
|
||||
^RFW,H,2,12,1^FD{encoded_epc}^FS
|
||||
^PQ1,0,1,Y
|
||||
^XZ'''`
|
||||
},
|
||||
printerCommunication: {
|
||||
title: 'Network Communication with the Printer',
|
||||
description: 'Communication with the Zebra printer is done via TCP/IP:',
|
||||
code: `def send_to_printer(data, printer_ip='192.168.68.50', printer_port=9100):
|
||||
try:
|
||||
with socket.socket(socket.AF_INET, socket.SOCK_STREAM) as sock:
|
||||
sock.connect((printer_ip, printer_port))
|
||||
sock.sendall(data.encode('utf-8'))
|
||||
logger.info('Data successfully sent to printer')
|
||||
except Exception as e:
|
||||
logger.error(f'Error sending data to printer: {e}')`
|
||||
},
|
||||
serialNumberManagement: {
|
||||
title: 'Data Processing and Serial Number Management',
|
||||
description: 'Managing serial numbers is critical for the uniqueness of EPC codes:',
|
||||
code: `def initialize_serial_number():
|
||||
global current_serial_number
|
||||
try:
|
||||
serial_log_content = SERIAL_NUMBER_LOG_PATH.read_text().strip()
|
||||
current_serial_number = int(serial_log_content)
|
||||
except (FileNotFoundError, ValueError):
|
||||
current_serial_number = START_SERIAL_NUMBER
|
||||
def get_next_serial_number():
|
||||
global current_serial_number
|
||||
current_serial_number += 1
|
||||
return current_serial_number
|
||||
def finalize_serial_number():
|
||||
SERIAL_NUMBER_LOG_PATH.write_text(str(current_serial_number))`
|
||||
}
|
||||
},
|
||||
features: {
|
||||
title: 'Implemented Features',
|
||||
errorHandling: {
|
||||
title: '1. Robust Error Handling',
|
||||
points: [
|
||||
'Input data validation',
|
||||
'Network connection verification',
|
||||
'Serial number persistence',
|
||||
'Detailed logging of all operations'
|
||||
]
|
||||
},
|
||||
configurability: {
|
||||
title: '2. Configurability',
|
||||
points: [
|
||||
'Adjustable printer IP and port',
|
||||
'Customizable ZPL templates',
|
||||
'Flexible EPC code generation',
|
||||
'Configurable serial number ranges'
|
||||
]
|
||||
},
|
||||
scalability: {
|
||||
title: '3. Scalability',
|
||||
points: [
|
||||
'Batch processing of product data',
|
||||
'Parallel print jobs possible',
|
||||
'Efficient resource management',
|
||||
'Modular code for easy extensibility'
|
||||
]
|
||||
}
|
||||
},
|
||||
bestPractices: {
|
||||
title: 'Best Practices',
|
||||
dataValidation: {
|
||||
title: '1. Data Validation',
|
||||
points: [
|
||||
'Strict typing for critical data fields',
|
||||
'Verification of required fields',
|
||||
'Format and plausibility checks'
|
||||
]
|
||||
},
|
||||
faultTolerance: {
|
||||
title: '2. Fault Tolerance',
|
||||
points: [
|
||||
'Automatic retry attempts',
|
||||
'Graceful degradation',
|
||||
'Detailed error logs'
|
||||
]
|
||||
},
|
||||
maintainability: {
|
||||
title: '3. Maintainability',
|
||||
points: [
|
||||
'Modular code structure',
|
||||
'Comprehensive documentation',
|
||||
'Clear separation of configuration and code'
|
||||
]
|
||||
}
|
||||
},
|
||||
lessonsLearned: {
|
||||
title: 'Lessons Learned',
|
||||
zplSpecifics: {
|
||||
title: '1. ZPL Specifics',
|
||||
points: [
|
||||
'Detailed knowledge of ZPL specifications necessary',
|
||||
'Careful validation of generated ZPL codes',
|
||||
'Regular testing with different printer models'
|
||||
]
|
||||
},
|
||||
rfidStandards: {
|
||||
title: '2. RFID Standards',
|
||||
points: [
|
||||
'Adherence to EPC standards critical',
|
||||
'Careful management of serial numbers',
|
||||
'Validation of generated EPC codes'
|
||||
]
|
||||
},
|
||||
networkCommunication: {
|
||||
title: '3. Network Communication',
|
||||
points: [
|
||||
'Robust error handling for network issues',
|
||||
'Timeouts and retry attempts',
|
||||
'Buffering of print jobs'
|
||||
]
|
||||
}
|
||||
},
|
||||
conclusion: {
|
||||
title: 'Conclusion',
|
||||
description: 'The implemented solution enables efficient and reliable automation of the RFID labeling process. Through the combination of EPC code generation, ZPL template management, and direct printer communication, a robust system has been created that has proven itself in practice.',
|
||||
keyPoints: [
|
||||
'Thorough planning of system architecture',
|
||||
'Comprehensive error handling',
|
||||
'Careful documentation',
|
||||
'Regular testing and validation'
|
||||
],
|
||||
results: 'The solution has been running stably in production for several months and processes hundreds of labels daily.'
|
||||
}
|
||||
}
|
||||
};
|
||||
Reference in New Issue
Block a user