1. The document describes how WAS400 can be used to implement a modern business services layer on top of an AS/400 system for purchase order processing. 2. It shows how WAS400 generates web services from AS/400 tables and RPG programs, replicates transactional data, and supports integrating the AS/400 with modern applications and systems. 3. The example implementation creates web services for AS/400 sales order entry and implements new purchasing and warehousing solutions using business rules and workflow that integrate with the AS/400 through WAS400.

1. WAS400: Web services Adapter AS/400
Fast path to modernization & integration
How to implement a business services layer on top of the
AS/400
Showcase purchase order processing
Audience: RPG developers and system engineers
Harmony Services for IBM i

2. • Benefits of WAS400: what does it do?
• AS400: “5250”/RPG situation (slide 7 onwards)
– “co”-existence of RPG and modern (rules)
• Animated (short) demo – using slides
– Solution in action (slide 12 onwards)
• How it works (slide 20 onwards)
• Other interesting features (slide 29 onwards)
– Standard Harmony features
• WAS400 Configuration (slide 35 onwards)
Contents

3. • “Opens” up the AS/400 to other systems
• Simple 3 step approach to connect your AS400 to
the internet/cloud
• Integrate with Windows, Unix, open source
• Easy web services generation
• Turns tables into web services
• Turns RPG *pgms into “headless” programs with a
web service interface
(Removing/ignoring the [5250] UI )
• Replicates/mirrors AS400 transaction data
• To support your new process /new applications
• To run your BI / data warehouse
• Easy, fast, reliable “must-do” modernization step
• Web services are de-facto standard for any app
Why WAS400 ?

4. 1. monitoring services
a.Specify which modifications to the database
(tables) are to be replicated
2. mapping services
a.Map AS400 data structures to web services
i. Table (file) structures
ii. Program parameters
b.Map web services to AS400 data structures
i. Table (file) structures
ii. Program parameters
3. (out of the box) ESB support
WAS400 features

5. Showcase WAS400
• Goal:
– Implement a smart, efficient and easy to maintain
solution for purchase order processing
• Implementation
– Create web services for AS/400 sales order entry
– (new) Purchasing solution
• using business rules and workflow
– Warehousing: goods received modern UI
• Benefits
– Fast , implementation in < 2weeks)
– Smallest possible learning curve
– Low cost
• For business case linked on last slide
– The new AS400 - a modernization scenario for the IBM i (powerpoint)

6. AS/400 “OLD” AND “NEW”
Sales orders & purchase order systems (RPG/5250)

7. Purchasing
(inlcl warehousing)
Sales Order Entry
(Old) System overview AS400
• Sales Order Entry
– Records article, quantity and
delivery date
• Purchasing
– If stock levels are too low
• Raises a PO (Purchase Order)
which has to be signed & sent
– Supports the reception of
goods
• Implemented at multiple
warehouses
– Supported by 5250

8. Sales Order Entry – main screen
The RPG “maintain sales order” system records the sales order1
1

9. Sales Order Entry - orders
Maintain / create sales order lines:
product
stock quantity
shipment date
1
1
2
3
1
2
3

10. New situation
• Business goals / requirements:
– Implement a Cloud solution to support purchase order
processing
• Flexible business rules (easy to modify when business
changes )
• Mobile support
– Support warehousing / goods reception
• Transporters data must be captured
• Replace 5250 workstations
• Mobile support
• Technical Implementation
– Create web services for AS/400 sales order entry
– Purchasing & warehousing solutions
• using business rules and workflow

11. Sales Order Entry
“co”-existence old & new
Harmony purchasing
business rules
WAS400 web services for AS/400
Modern UI
-browser AND
mobile
Business logic &
business rules
-easy to maintain
Web services
1
2
3
“Headless”
Copy of
*pgm

12. Sales Order EntryWAS400: monitors database & applies changes
Business services layer (all Logic)
The solution in action
RPG program started; user enters data, order files + stock are updated0
0

13. Sales Order EntryWAS400: monitors database & applies changes
HARMONY Business services layer (all Logic)
The solution in action
If WAS400 detects a database change it sends the change to Harmony1
1

14. Sales Order EntryWAS400: monitors database & applies changes
HARMONY Business services layer (all Logic)
Issue an
PO?
The solution in action
Harmony receives the transaction – calculates stock level and issues a PO
(Purchase Order) when stock level falls below threshold
2
2

15. Sales Order EntryWAS400: monitors database & applies changes
Business services layer (all Logic_
Issue an
PO?
PO
>
10.000?
The solution in action
PO value more than 10,000 ?
-> approval required
3
3

16. Sales Order EntryWAS400: monitors database & applies changes
Business services layer (all Logic)
Issue an
PO?
PO
>
10.000?
The solution in action: warehousing
Manually start “Receive
goods” process
4

17. Sales Order EntryWAS400: monitors database & applies changes
Business services layer (all Logic_
all goods
received?
Issue an
PO?
PO
>
10.000?
The solution in action
Rules checks if
“open” PO quantity
5
5

18. Sales Order EntryWAS400: monitors database & applies changes
Business services layer (all Logic)
all goods
received?
Issue an
PO?
PO
>
10.000?
The solution in action
Harmony submits
goods received to WAS
WAS400 sends data to
AS/400
6
7
6
7

19. WAS400 & HARMONY
How it works: new purchasing with AS400 integration

20. WAS400 sends data to Harmony
Sales order is put on Harmony queue1
1
WAS400: monitors database changes

21. WAS400 sends data to Harmony
Sales order is put on Harmony queue
The content of the queue
1
1
2
2
WAS400: monitors database changes

22. WAS400 sends data to Harmony
Sales order is put on Harmony queue
The content of the queue
The details of case [3nyte]
1
1
2
3
3
2
WAS400: monitors database changes

23. Harmony “sensors” changes
Harmony “picks” the sales order from the queue
starts the purchase order [task]
(simultaneously) starts Approve purchase order [task]
1
3
2
1
3
2

24. Workflow and decision support
Approval = YES next step is scheduled1
Harmony’s decision support turns business
logic and business rules into information
1

25. Workflow is started
2 When Approval = NO Decision support
changes immediately – showing the
steps that will be schedule next
2

26. Next in workflow: supplier must confirms
Suppliers have access to their own cases or queues
Confirms delivery quantity, date and time
1
2
1
2

27. Warehouse: receives stock
When goods received is submitted
WAS400 will update AS400 stock by 81
1
2
2
1
WAS400: commits changes to database

28. OTHER INTERESTING FEATURES
Workflow, History, Google DOCS, ESB, cloud verus enterprise

29. Workflow history
• Process history:
– Overview of all process steps
is maintained by Harmony
– Per step [data] changes are
shown
– Outputs (like email sent) can
be seen by “hovering over”
with your mouse)

30. Case history
• Data history:
– All data that is created / updated by
the business process is “logged”
– Distinction is made between
Reference data and process data

31. Harmony replicates to Google DOCS
• Automatic update/synchronization:
– All data can be saved in spreadsheets
– Use pivot tables/reports
Harmony is the “single source of truth”, maintaining data integrity between all systems

32. WAS400 uses ESB
• Why ESB ?
• ESB is optional, but recommended, since this part of
the SOA model. ESB offers:
• application de-coupling
• routing
• protocol and data conversion

33. Deployment options
1
2
1
2
• Deployment options:
Implement your new
process in the cloud
Implement within your
firewall. Share data using
Google DOCS
(spreadsheets, documents)

34. WAS400 SETUP & OPERATION
Implementation aspects

35. What must be done
• Goal I: to invoke the Purchasing process
o How: when a sales order is created
• Goal II: support “goods received”
• Create new application + process (rules)
• Using Harmony
• Commit received goods to AS400 database
• Using WAS400
• For business case see
• The new AS400 - a modernization scenario for the IBM i
(powerpoint)

36. 1) Map AS400 data structures to web services
Table (file) structure mapped to webservice
(optional) Program parameters
2) Map web services to AS400 data structures
Case data to RPG program parameters
(optional) Table (file) structures
3) Configure Harmony
Create and map “data capture sensor” and process
4) Configure WAS400 monitoring services
The database updates (tables) are to be
monitored
• Implement network infrastructure
• Cloud or private enterprise network
How this is done

37. Documentation: data model & functions
1
1

38. 1) Create web service / map order
• Mapping is stored in Google spreadsheets
• Map AS400 [order_details] to business terms
1. Article ID
2. Quantity sold
3. Delivery date
• All other data is stored in Harmony
1
1

39. 2) Link webservice to Harmony

40. 3) Map goods received
• The Goods received will be mapped
to an RPG program
• Case data is mapped to variables
1. Article ID
2. Received quantity
3. Delivery date
4. Warehouse ID

41. 4. Monitoring the AS/400
Order_details file is updated when a sales order is created/changed1
1

42. WAS pre-requisites AS/400
• ILE RPG
• Java 1.5
• RPG Open Access
• SQL

43. For more information
• Visit
– www.liquidsequence.com
• Release overview
– (all new features)
• Contact us
– http://liquidsequence.com/Contact.html
– Business process flowchart
– https://www.lucidchart.com/documents/view/48d3-c748-50c6fb88-
ab71-3fb70a7cdee7
– AS400 website info (including architecture diagrams)
– http://liquidsequence.com/AS400-webservices-adapter.html
– Business case presentation (management)
– The new AS400 - a modernization scenario for the IBM I
– Pricing
– http://liquidsequence.com/Pricing.html