0% found this document useful (0 votes)
9 views

Application Platform Configuration Guide

application platform

Uploaded by

meghana dodla
Copyright
© © All Rights Reserved
Available Formats
Download as PDF, TXT or read online on Scribd
0% found this document useful (0 votes)
9 views

Application Platform Configuration Guide

application platform

Uploaded by

meghana dodla
Copyright
© © All Rights Reserved
Available Formats
Download as PDF, TXT or read online on Scribd
You are on page 1/ 690

Sterling Selling and Fulfillment Foundation



Application Platform Configuration Guide


Release 9.1.0.13
Sterling Selling and Fulfillment Foundation


Application Platform Configuration Guide


Release 9.1.0.13
Note
Before using this information and the product it supports, read the information in “Notices” on page 667.

Copyright
This edition applies to the 9.1 Version of IBM Sterling Selling and Fulfillment Foundation and to all subsequent
releases and modifications until otherwise indicated in new editions.
© Copyright IBM Corporation 1999, 2011.
US Government Users Restricted Rights – Use, duplication or disclosure restricted by GSA ADP Schedule Contract
with IBM Corp.
Contents
Chapter 1. Introducing Sterling Creating and Modifying an Organizational
Application Platform . . . . . . . . . 1 Hierarchy. . . . . . . . . . . . . . . 116
Business Models . . . . . . . . . . . . . 1 Creating an Organizational Hierarchy . . . . 116
Multi-Divisional Corporation . . . . . . . . 1 Creating Node Types . . . . . . . . . . . 117
Third-Party Logistics . . . . . . . . . . 2 Creating a Node Type . . . . . . . . . 117
Marketplace . . . . . . . . . . . . . 2 Modifying a Node Type . . . . . . . . . 117
Application Platform Platform Configuration . . . 2 Deleting a Node Type . . . . . . . . . 118
Participant Modeling . . . . . . . . . . 2
Process Modeling . . . . . . . . . . . . 3 Chapter 4. Configuring Process
Security . . . . . . . . . . . . . . . 3 Models . . . . . . . . . . . . . . 119
System Administration . . . . . . . . . . 3 Document Type Configuration. . . . . . . . 119
Unit of Measure . . . . . . . . . . . . 3 The Process Modeling Tree . . . . . . . . 121
Internationalization . . . . . . . . . . . 3 Defining a New Document Type . . . . . . 121
Presentation . . . . . . . . . . . . . 3 Modifying a Document Type's Description . . 123
Communication . . . . . . . . . . . . 4 Modifying a Process Type . . . . . . . . 123
Nomenclature . . . . . . . . . . . . . 4 Defining Process Type Pipelines . . . . . . . 132
Queue Management . . . . . . . . . . . 4 Defining Pipeline Determination . . . . . . 132
Region Definition . . . . . . . . . . . . 4 Creating a Pipeline . . . . . . . . . . 133
Alert Management . . . . . . . . . . . 4 Saving a Pipeline as a Draft . . . . . . . 134
Modifying a Pipeline . . . . . . . . . . 135
Chapter 2. Navigating the Configurator Defining a Pipeline's Monitoring Rules . . . . 136
Applications Manager . . . . . . . . . 5 Defining Transactions . . . . . . . . . 140
Starting the Applications Manager . . . . . . . 5 Defining Statuses . . . . . . . . . . . 167
The Applications Manager Layout . . . . . . . 5 Defining Conditions . . . . . . . . . . 170
Application Rules Side Panel . . . . . . . . 7 Defining Actions . . . . . . . . . . . 176
Work Area. . . . . . . . . . . . . . 14 Defining Service Definitions . . . . . . . 180
Actions Available in the Applications
ManagerConfigurator . . . . . . . . . . . 17 Chapter 5. Configuring User Security 187
Using the Applications Manager's Lookup Defining Users . . . . . . . . . . . . . 187
Functionality . . . . . . . . . . . . . 18 Creating a User. . . . . . . . . . . . 187
Viewing the Document Types Associated with an Modifying a User . . . . . . . . . . . 190
Application . . . . . . . . . . . . . 18 Setting Up Printer Preferences for a User . . . 190
Viewing the User Logged into the Applications Deleting a User. . . . . . . . . . . . 192
Manager . . . . . . . . . . . . . . 20 Defining User Groups . . . . . . . . . . 193
Using Lists and List Filtering . . . . . . . 20 Creating a User Group . . . . . . . . . 193
Date and Time Entry . . . . . . . . . . 21 Modifying a User Group . . . . . . . . 194
Using Context-Sensitive Help . . . . . . . 21 Deleting a User Group . . . . . . . . . 203
Troubleshooting Errors . . . . . . . . . 22 Defining Data Security Groups . . . . . . . 204
Using Special Characters . . . . . . . . . 22 Creating a Data Security Group . . . . . . 204
Modifying a Data Security Group . . . . . 206
Chapter 3. Configuring Participants . . 23 Deleting a Data Security Group . . . . . . 206
Creating and Modifying an Organization . . . . 23 Defining Teams. . . . . . . . . . . . . 206
Defining an Organization's Primary Information 26 Creating a Team . . . . . . . . . . . 207
The Organization's Roles and Participant Modifying a Team . . . . . . . . . . . 209
Associations . . . . . . . . . . . . . 28 Deleting a Team . . . . . . . . . . . 210
Assigning a Yard's Roles and Participant Defining Data Access Policies . . . . . . . . 210
Associations . . . . . . . . . . . . . 97 Enterprise User Access . . . . . . . . . 210
Defining Communication Protocols . . . . . 97 Buyer User Access. . . . . . . . . . . 212
Defining an Organization's Payment Seller User Access . . . . . . . . . . . 214
Information . . . . . . . . . . . . . 106 Node User Access . . . . . . . . . . . 214
Viewing an Organization's Child Organizations 108 Configuring API Security . . . . . . . . . 214
Defining an Organization’s Calendars . . . . 108 Viewing API Security Resources . . . . . . 215
Viewing an Organization’s Departments . . . 114 Creating an API Security Resource . . . . . 215
Modifying an Organization . . . . . . . . 115 Modifying an API Security Resource: . . . . 216

© Copyright IBM Corp. 1999, 2011 iii


Chapter 6. Configuring System Modifying a Unit of Measure Conversion Rate for
Administration Components . . . . . 219 Volume . . . . . . . . . . . . . . . 247
System Administration Components: Defining Deleting a Unit of Measure Conversion Rate for
Purge Criteria . . . . . . . . . . . . . 219 Volume . . . . . . . . . . . . . . . 248
Modifying a System Purge Criteria Rule . . . 219 Deleting a Unit of Measure for Volume . . . . . 248
System Administration Components: Defining User Creating a Unit of Measure for Weight . . . . . 248
Exit Implementations . . . . . . . . . . . 221 Modifying a Unit of Measure for Weight . . . . 248
Defining a User Exit . . . . . . . . . . 223 Creating a Unit of Measure Conversion Rate for
System Administration Components: Defining Weight . . . . . . . . . . . . . . . 249
Installation Rules . . . . . . . . . . . . 226 Modifying a Unit of Measure Conversion Rate for
Creating an Agent Criteria Group . . . . . . 233 Weight . . . . . . . . . . . . . . . 249
Modifying an Agent Criteria Group . . . . . 234 Deleting a Unit of Measure Conversion Rate for
Deleting an Agent Criteria Group . . . . . 234 Weight . . . . . . . . . . . . . . . 249
Defining Initial Context Factory Codes . . . . . 234 Deleting a Unit of Measure for Weight . . . . . 250
Creating an Initial Context Factory Code . . . 235 Creating a Unit of Measure for Time . . . . . 250
Modifying an Initial Context Factory Code . . 235 Modifying a Unit of Measure for Time . . . . . 250
Deleting an Initial Context Factory Code . . . 235 Creating a Unit of Measure Conversion Rate for
Defining Health Monitor Rules . . . . . . . 236 Time . . . . . . . . . . . . . . . . 250
Viewing the List of Configured Servers . . . . . 237 Modifying a Unit of Measure Conversion Rate for
List of Sub Flows or Criteria ID Configured for Time . . . . . . . . . . . . . . . . 251
Server . . . . . . . . . . . . . . . 238 Deleting a Unit of Measure Conversion Rate for
Defining Item Configurator Properties . . . . . 238 Time . . . . . . . . . . . . . . . . 251
Defining Application Version . . . . . . . . 238 Deleting a Unit of Measure for Time . . . . . 251
Creating an Application Version . . . . . . 239
Modifying an Application Version . . . . . 239 Chapter 8. Configuring
Deleting an Application Version . . . . . . 239 Internationalization Rules . . . . . . 253
Defining Country or Region Codes . . . . . . 253
Chapter 7. Configuring Units of Creating a Country or Region Code Definition 253
Measure . . . . . . . . . . . . . 241 Modifying a Country or Region Code Definition 254
Creating a Unit of Measure for Quantity . . . . 241 Deleting a Country or Region Code Definition 254
Modifying a Unit of Measure for Quantity . . . 241 Defining Language Codes . . . . . . . . . 254
Creating a Unit of Measure Conversion Rate for Creating a Language Definition . . . . . . 255
Quantity . . . . . . . . . . . . . . . 241 Modifying a Language Definition . . . . . 255
Modifying a Unit of Measure Conversion Rate for Deleting a Language Definition . . . . . . 256
Quantity . . . . . . . . . . . . . . . 242 Defining Date Formats . . . . . . . . . . 256
Deleting a Unit of Measure Conversion Rate for Creating a Date Format . . . . . . . . . 256
Quantity . . . . . . . . . . . . . . . 242 Modifying a Date Format . . . . . . . . 256
Deleting a Unit of Measure for Quantity . . . . 242 Deleting a Date Format . . . . . . . . . 257
Creating a Unit of Measure for Service Quantity 243 Defining Time Formats . . . . . . . . . . 257
Modifying a Unit of Measure for Service Quantity 243 Creating a Time Format . . . . . . . . . 257
Creating a Unit of Measure Conversion Rate for Modifying a Time Format . . . . . . . . 258
Service Quantity . . . . . . . . . . . . 243 Deleting a Time Format . . . . . . . . . 258
Modifying a Unit of Measure Conversion Rate for Defining Date/Time Formats . . . . . . . . 258
Service Quantity . . . . . . . . . . . . 244 Creating a Date/Time Format . . . . . . . 259
Deleting a Unit of Measure Conversion Rate for Modifying a Date/Time Format . . . . . . 259
Service Quantity . . . . . . . . . . . . 244 Deleting a Date/Time Format . . . . . . . 259
Deleting a Unit of Measure for Service Quantity 244 Defining Currency Definitions . . . . . . . . 260
Creating a Unit of Measure for Dimension . . . 244 Creating a Currency Definition . . . . . . 260
Modifying a Unit of Measure for Dimension . . . 245 Modifying a Currency Definition . . . . . . 261
Creating a Unit of Measure Conversion Rate for Deleting a Currency Definition . . . . . . 261
Dimension . . . . . . . . . . . . . . 245 Defining Currency Conversions . . . . . . . 262
Modifying a Unit of Measure Conversion Rate for Creating a Currency Conversion . . . . . . 262
Dimension . . . . . . . . . . . . . . 245 Modifying a Currency Conversion . . . . . 263
Deleting a Unit of Measure Conversion Rate for Deleting a Currency Conversion . . . . . . 264
Dimension . . . . . . . . . . . . . . 246
Deleting a Unit of Measure for Dimension. . . . 246 Chapter 9. Configuring Presentation
Creating a Unit of Measure for Volume. . . . . 246 Components . . . . . . . . . . . . 265
Modifying a Unit of Measure for Volume . . . . 247 Defining Locales . . . . . . . . . . . . 265
Creating a Unit of Measure Conversion Rate for Creating a Locale . . . . . . . . . . . 265
Volume . . . . . . . . . . . . . . . 247 Modifying a Locale . . . . . . . . . . 267

iv Sterling Selling and Fulfillment Foundation: Application Platform Configuration Guide


Deleting a Locale . . . . . . . . . . . 267 Chapter 11. Configuring Nomenclature
Defining Menus . . . . . . . . . . . . 267 Components . . . . . . . . . . . . 297
Saving a Menu Group as a New Menu Defining Nomenclature Codes. . . . . . . . 297
Grouping. . . . . . . . . . . . . . 267 Defining Nomenclature Definitions . . . . . . 298
Modifying Application Menu Details . . . . 268 Creating Mappings Between Nomenclature
Defining Submenus . . . . . . . . . . 268 Definitions . . . . . . . . . . . . . 299
Defining Menu Items . . . . . . . . . . 269 Defining Nomenclature Configuration . . . . . 300
Modifying a Menu Item . . . . . . . . . 270
Deleting a Menu Item . . . . . . . . . 271
Defining Resources . . . . . . . . . . . 271
Chapter 12. Configuring Alert Queues 305
Sterling Selling and Fulfillment Creating an Alert Queue. . . . . . . . . . 305
FoundationSterling Application Platform Defining How Unresolved Alerts are Handled
Resources . . . . . . . . . . . . . 271 Based on Size . . . . . . . . . . . . 306
Application Consoles Entity . . . . . . . 273 Defining How Unassigned Alerts are Handled
Application Consoles Related Entity . . . . . 274 Based on Time . . . . . . . . . . . . 307
Application Consoles Search View . . . . . 275 Defining How Unresolved Alerts are Handled
Application Consoles Detail View . . . . . 276 Based on Time . . . . . . . . . . . . 308
Application Consoles List View . . . . . . 277 Viewing an Alert Queue's User List . . . . . 308
Application Consoles API . . . . . . . . 278 Modifying an Alert Queue . . . . . . . . . 309
Application Consoles Inner Panel. . . . . . 280 Deleting an Alert Queue. . . . . . . . . . 309
Application Consoles Action . . . . . . . 281
Application Consoles Link . . . . . . . . 282 Chapter 13. Configuring Region
Application Consoles Icon . . . . . . . . 282 Definitions. . . . . . . . . . . . . 311
Rich Client Platform Action . . . . . . . 283 Defining Region Levels . . . . . . . . . . 311
Rich Client Platform Task . . . . . . . . 284 Creating a Region Level . . . . . . . . . 311
Defining Themes . . . . . . . . . . . . 284 Modifying a Region Level . . . . . . . . 312
Creating a Theme . . . . . . . . . . . 284 Deleting a Region Level . . . . . . . . . 312
Modifying a Theme . . . . . . . . . . 285 Defining Region Match Preferences . . . . . . 313
Deleting a Theme . . . . . . . . . . . 285 Setting a Region Match Preference . . . . . 313
Defining Custom Common Code Types . . . . 286 Deleting a Region Match Preference . . . . . 313
Creating a Custom Common Code Type . . . 286 Defining Region Schemas . . . . . . . . . 313
Modifying a Custom Common Code Type. . . 287 Creating a Region Schema . . . . . . . . 313
Deleting a Custom Common Code Type . . . 287 Modifying a Region Schema . . . . . . . 315
Defining Custom Common Code Values . . . . 287 Deleting a Region Schema . . . . . . . . 316
Adding Values to a Custom Common Code . . . 287
Modifying a Custom Common Code's Values. . . 288 Chapter 14. Configuring Devices . . . 317
Deleting a Custom Common Code's Values . . . 288 Defining a Device Type . . . . . . . . . . 317
Defining Custom Error Codes . . . . . . . . 289 Creating a Device Type . . . . . . . . . 317
Searching for a Customer Error Code . . . . 289 Modifying a Device Type . . . . . . . . 319
Adding a Custom Error Code . . . . . . . 289 Deleting a Device Type . . . . . . . . . 319
Modifying a Custom Error Code . . . . . . 290 Defining a Device Sub Type . . . . . . . . 319
Deleting a Custom Error Code . . . . . . 290 Creating a Device Sub Type . . . . . . . 319
Modifying a Device Sub Type . . . . . . . 321
Chapter 10. Configuring Business Deleting a Device Sub Type . . . . . . . 321
Communication Components . . . . 291 Defining a Device . . . . . . . . . . . . 321
Defining Protocol Codes. . . . . . . . . . 291 Creating a Device Overview . . . . . . . 321
Creating a Protocol Code . . . . . . . . 291 Creating a Device . . . . . . . . . . . 323
Modifying a Protocol Code . . . . . . . . 291 Overview of Creating a New Device from a
Deleting a Protocol Code . . . . . . . . 292 Device. . . . . . . . . . . . . . . 325
Defining Document Format Codes . . . . . . 292 Creating a New Device from a Device . . . . 326
Creating a Document Format Code . . . . . 292 Modifying a Device . . . . . . . . . . 327
Modifying a Document Format Code . . . . 293 Deleting a Device . . . . . . . . . . . 327
Deleting a Document Format Code . . . . . 293
Defining Business Document Codes . . . . . . 293 Chapter 15. Configuring Prints . . . . 329
Creating a Business Document Code . . . . 293 Defining Print Documents . . . . . . . . . 329
Modifying a Business Document Code . . . . 294 Creating a Print Document . . . . . . . . 330
Deleting a Business Document Code . . . . 294 Modifying a Print Document . . . . . . . 331
Classifying an Existing Business Document . . 294 Deleting a Print Document . . . . . . . . 331
Defining Label Formats . . . . . . . . . . 332
Creating a Label Format . . . . . . . . . 332

Contents v
Modifying a Label Format . . . . . . . . 334 Configuring Communication Between an Agent
Deleting a Label Format . . . . . . . . . 334 and a JMS Server . . . . . . . . . . . . 361
Prerequisites. . . . . . . . . . . . . 361
Chapter 16. Managing Password Create an Initial Context Factory Code . . . . 361
Policies . . . . . . . . . . . . . . 335 Define the Transaction Information . . . . . 362
Business Process Time-Triggered Transactions . . 363
Asynchronous Request Processor . . . . . . 363
Chapter 17. Configuring Alerts . . . . 337 Case Insensitive Data Loader . . . . . . . 365
Creating an Exception Type . . . . . . . . 337 Change Data Export Agent . . . . . . . . 367
Modifying an Exception Type . . . . . . . . 339 Change Data Import Agent . . . . . . . . 368
Deleting an Exception Type. . . . . . . . . 339 Change Load Status . . . . . . . . . . 369
Defining Exception Type Role . . . . . . . . 339 Change Shipment Status. . . . . . . . . 370
Creating an Exception Type Role . . . . . . 340 Close Delivery Plan . . . . . . . . . . 372
Modifying an Exception Type Role . . . . . 340 Close Load . . . . . . . . . . . . . 373
Deleting an Exception Type Role . . . . . . 341 Close Manifest . . . . . . . . . . . . 374
Defining Organization Exception Type Close Order . . . . . . . . . . . . . 376
Configuration . . . . . . . . . . . . . 341 Close Receipts . . . . . . . . . . . . 378
Creating an Exception Type for an Organization 341 Close Shipment. . . . . . . . . . . . 379
Modifying an Exception Type for an Collect Shipment Statistics . . . . . . . . 381
Organization . . . . . . . . . . . . 342 Consolidate Additional Inventory . . . . . 382
Creating an Exception Routing Rule . . . . . 342 Consolidate To Shipment . . . . . . . . 384
Modifying an Exception Routing Rule . . . . 343 Create Catalog Index . . . . . . . . . . 386
Deleting an Exception Routing Rule . . . . . 344 Create Chained Order . . . . . . . . . 390
Deleting an Exception Type for an Organization 344 Create Derived Order . . . . . . . . . 391
Create Order Invoice . . . . . . . . . . 392
Chapter 18. Configuring Data Version Create Shipment Invoice. . . . . . . . . 394
Labels . . . . . . . . . . . . . . 345 ESP Evaluator . . . . . . . . . . . . 395
Creating Configuration Data Version Labels . . . 345 Item Based Allocation . . . . . . . . . 397
Modifying Configuration Data Version Labels 346 Mark Load as Trailer Loaded . . . . . . . 400
Deleting Configuration Data Version Labels . . 346 Match Inventory . . . . . . . . . . . 402
Payment Collection . . . . . . . . . . 403
Chapter 19. Configuring Qualified Tag Payment Execution . . . . . . . . . . 405
Post Inventory Match. . . . . . . . . . 407
Information . . . . . . . . . . . . 349 Process Order Hold Type . . . . . . . . 408
Creating a Qualified Tag Type . . . . . . . . 349 Process Work Order Hold Type . . . . . . 410
Modifying a Qualified Tag Type . . . . . . 350 Publish Negotiation Results . . . . . . . 411
Deleting a Qualified Tag Type . . . . . . . 350 Release . . . . . . . . . . . . . . 413
Defining Qualified Tags . . . . . . . . . . 351 Route Shipment . . . . . . . . . . . 415
Creating a Qualified Tag. . . . . . . . . 351 Schedule . . . . . . . . . . . . . . 416
Modifying a Qualified Tag . . . . . . . . 351 Send Invoice . . . . . . . . . . . . 419
Deleting a Qualified Tag. . . . . . . . . 352 Send Item Changes . . . . . . . . . . 421
Configuring Qualified Tag Version Compatibility 352 Send Customer Changes. . . . . . . . . 422
Modifying Qualified Tag Version Compatibility 353 Send Order . . . . . . . . . . . . . 424
Deleting Qualified Tag Version Compatibility 353 Send Release . . . . . . . . . . . . 425
Start Order Negotiation . . . . . . . . . 426
Chapter 20. Configuring Attribute Synchronize Colony Map . . . . . . . . 427
Postfix Rules . . . . . . . . . . . 355 Update Best Match Region . . . . . . . . 429
Creating an Attribute Postfix Definition . . . . 355 PopulateOwnershipTransferSummary . . . . 431
Modifying an Attribute Postfix Definition . . . . 355 Time-Triggered Purge Transactions . . . . . . 432
Deleting an Attribute Postfix Definition . . . . 356 Purge Strategy . . . . . . . . . . . . 432
Configuring Purge Transaction Log Files . . . 432
Chapter 21. Configuring Analytics . . 357 Available Purges . . . . . . . . . . . 433
Defining Analytics Region Usage . . . . . . . 357 Task Queue Syncher Time-Triggered Transactions 514
Load Execution Task Queue Syncher . . . . 514
Order Delivery Task Queue Syncher. . . . . 515
Chapter 22. Time-Triggered Order Fulfillment Task Queue Syncher . . . . 516
Transaction Reference . . . . . . . 359 Order Negotiation Task Queue Syncher . . . 517
Time-Triggered Transaction Reference . . . . . 359 Quote Fulfillment Task Queue Syncher . . . . 518
Running Time-Triggered Transactions . . . . . 360 Monitors . . . . . . . . . . . . . . . 519
Steps to Complete Before Scheduling Availability Monitor . . . . . . . . . . 519
Time-Triggered Transactions . . . . . . . 360 Exception Monitor. . . . . . . . . . . 521

vi Sterling Selling and Fulfillment Foundation: Application Platform Configuration Guide


Inventory Monitor. . . . . . . . . . . 522 Router. . . . . . . . . . . . . . . 612
Negotiation Monitor . . . . . . . . . . 524 Text Translator . . . . . . . . . . . . 613
Enhanced Order Monitor . . . . . . . . 525 XSL Translator . . . . . . . . . . . . 614
Enhanced Quote Monitor . . . . . . . . 528 Defaulting Component . . . . . . . . . 615
Enhanced Return Monitor . . . . . . . . 530 Data Security . . . . . . . . . . . . 617
Real-time Availability Monitor . . . . . . . 532 Jasper Printer Component . . . . . . . . 618
Shipment Monitor . . . . . . . . . . . 539 Adapter Nodes . . . . . . . . . . . . . 620
Work Order Monitor . . . . . . . . . . 541 Sterling GISIBM Sterling B2B Integrator . . . 620

Chapter 23. Inventory and Capacity Chapter 25. Text Translator Reference 623
Change Transaction Reference . . . . 543 Understanding File Formats . . . . . . . . 623
The Inventory Change Transaction . . . . . . 543 Positional Flat Files . . . . . . . . . . 623
The Capacity Change Transaction . . . . . . 544 Delimited Flat Files . . . . . . . . . . 623
XML Flat Files . . . . . . . . . . . . 624
Chapter 24. Transport Nodes. . . . . 547 Text Translator Components . . . . . . . 624
Verifying the Text Translator Setup . . . . . . 626
Database . . . . . . . . . . . . . . . 547
Error Messages . . . . . . . . . . . . 626
Database Sender . . . . . . . . . . . 547
Text Translator XSD Files . . . . . . . . . 628
Database Receiver . . . . . . . . . . . 549
Text Translator Positional Receiver XSD File . . . 628
DCS 6.2 Database . . . . . . . . . . . . 551
Text Translator Delimited Receiver XSD File . . . 632
DDCS 6.2 Database Sender . . . . . . . . 552
Text Translator Positional Sender XSD File. . . . 634
DCS 6.2 Database Receiver . . . . . . . . 552
Text Translator Delimited Sender XSD File. . . . 636
Component Object Model (COM). . . . . . . 553
Running the Text Translator . . . . . . . . 637
Enterprise Java Beans (EJB) . . . . . . . . . 554
File Input/Output (File I/O) . . . . . . . . 556
File I/O Sender. . . . . . . . . . . . 556 Chapter 26. Document Types. . . . . 639
File I/O Receiver . . . . . . . . . . . 557
Enabling EOF Messages in the Application Chapter 27. Condition Builder
Platform Framework . . . . . . . . . . 559 Attributes . . . . . . . . . . . . . 641
File Transfer Protocol (FTP). . . . . . . . . 562 Condition Builder Attributes . . . . . . . . 641
FTP Sender . . . . . . . . . . . . . 562 Sales Order . . . . . . . . . . . . . . 642
FTP Receiver . . . . . . . . . . . . 564 Order Fulfillment . . . . . . . . . . . 642
Hypertext Transport Protocol (HTTP) . . . . . 566 Order Negotiation . . . . . . . . . . . 644
WebService . . . . . . . . . . . . . . 567 Outbound Shipment . . . . . . . . . . 645
Synchronous Oracle WebLogic and MQSeries. . . 570 Receipt . . . . . . . . . . . . . . 646
Oracle WebLogic, MQSeries, and TIBCO JMS Planned Order . . . . . . . . . . . . . 646
Queue . . . . . . . . . . . . . . . . 573 Planned Order Execution . . . . . . . . 646
Oracle WebLogic, MQSeries, and TIBCO JMS Planned Order Negotiation . . . . . . . . 646
Queue Sender . . . . . . . . . . . . 573 Return Order . . . . . . . . . . . . . 646
Oracle WebLogic, MQSeries, and TIBCO JMS Reverse Logistics . . . . . . . . . . . 646
Receiver . . . . . . . . . . . . . . 578 Return Shipment . . . . . . . . . . . 648
IBM WebSphere Default Messaging JMS Queue 582 Return Receipt . . . . . . . . . . . . 648
IBM WebSphere Default Messaging JMS Queue Template Order. . . . . . . . . . . . . 649
Sender. . . . . . . . . . . . . . . 582 Purchase Order. . . . . . . . . . . . . 649
IBM WebSphere Default Messaging JMS Queue Purchase Order Execution . . . . . . . . 649
Receiver . . . . . . . . . . . . . . 585 Purchase Order Negotiation . . . . . . . 650
JBoss Default Messaging JMS Queue . . . . . 589 Inbound Shipment. . . . . . . . . . . 651
JBoss Default Messaging JMS Queue Sender . . 589 Purchase Order Receipt . . . . . . . . . 651
JBoss Default Messaging JMS Queue Receiver 593 Transfer Order . . . . . . . . . . . . . 651
Synchronous IBM WebSphere Default Messaging 596 Transfer Order Execution . . . . . . . . 651
Microsoft Message Queue (MSMQ) . . . . . . 599 Transfer Order Delivery . . . . . . . . . 651
MSMQ Sender . . . . . . . . . . . . 599 Transfer Order Receipt . . . . . . . . . 652
MSMQ Receiver . . . . . . . . . . . 600 Master Order Fulfillment . . . . . . . . . 652
Receiver Link Exception Handling . . . . . . 601 Quote Fulfillment . . . . . . . . . . . . 653
Component Nodes . . . . . . . . . . . 603 Load Execution. . . . . . . . . . . . . 653
Alert . . . . . . . . . . . . . . . 603 General . . . . . . . . . . . . . . . 654
Application Programming Interface (API) . . . 606 WMS Putaway . . . . . . . . . . . . . 655
Composite Service . . . . . . . . . . . 608 WMS Layout Definition . . . . . . . . . . 655
Condition . . . . . . . . . . . . . 608 WMS Inventory . . . . . . . . . . . . 655
E-Mail . . . . . . . . . . . . . . . 609 Trailer Loading . . . . . . . . . . . . . 655
Nomenclature Runtime Component . . . . . 611 Task Execution . . . . . . . . . . . . . 655

Contents vii
Move Request Execution . . . . . . . . . 655 Exporting Database Changes . . . . . . . . 663
Manifesting . . . . . . . . . . . . . . 656 Configuring Rules for Publishing Database
Over Pack Build . . . . . . . . . . . . 656 Changes . . . . . . . . . . . . . . . 663
Count Execution . . . . . . . . . . . . 656 Properties to be Set Before Publishing Database
Pack Process. . . . . . . . . . . . . . 657 Changes . . . . . . . . . . . . . . . 665
Outbound Picking . . . . . . . . . . . . 659
VAS Process . . . . . . . . . . . . . . 659 Notices . . . . . . . . . . . . . . 667
Opportunity Fulfillment . . . . . . . . . . 660
Item-Based Allocation (IBA) Order . . . . . . 660
Index . . . . . . . . . . . . . . . 671
Chapter 28. Configuring Change
Project Management . . . . . . . . 663

viii Sterling Selling and Fulfillment Foundation: Application Platform Configuration Guide
Chapter 1. Introducing Sterling Application Platform
This book concentrates on the rules and setup configurations that make up the
Applications ManagerConfigurator. This book is intended for both Hub and
Enterprise administrators using the Applications ManagerConfigurator to set up
the IBM® Sterling Selling and Fulfillment FoundationSterling Application Platform
environment. Business analysts should also use this book to plan appropriate
business practices as they pertain to Sterling Selling and Fulfillment
FoundationSterling Application Platform. Programmers should refer to the Sterling
Selling and Fulfillment Foundation: Customization Basics for information about
extending Sterling Selling and Fulfillment FoundationSterling Application Platform.
System Integrators should refer to the Sterling Selling and Fulfillment Foundation:
Integration Guide for information about integrating external applications with
Sterling Selling and Fulfillment FoundationSterling Application Platform.

This book assumes that you have read and are familiar with the concepts and
business functionality detailed in the Sterling Selling and Fulfillment Foundation:
Product Concepts Guide.

The Applications ManagerConfigurator is a collection of all the rules and setup


configurations necessary to implement Sterling Selling and Fulfillment
FoundationSterling Application Platform, organized in such a way that
configuration can be done for each business application separately. The following
business applications can be configured within the Applications
ManagerConfigurator:
v IBM Sterling Distributed Order Management
v IBM Sterling Global Inventory Visibility
v Catalog Management
v IBM Sterling Logistics Management
v IBM Sterling Supply Collaboration
v IBM Sterling Reverse Logistics
v IBM Sterling Warehouse Management System
v IBM Sterling Application Platform

Business Models
There is no single business model that encompasses the environment in which all
the Sterling Selling and Fulfillment FoundationSterling Application Platform
applications can be used. Therefore, there is no single way to configure your
Sterling Selling and Fulfillment FoundationSterling Application Platform
environment.

For example, your company might be considered a multi-divisional corporation, a


third-party logistics company, or a marketplace business. Each of these business
models require a different conceptual approach to the Sterling Selling and
Fulfillment FoundationSterling Application Platform configuration.

Multi-Divisional Corporation
The multi-divisional corporation model is a business corporation whose primary
focus is managing purchase and sales activities. A typical multi-divisional

© Copyright IBM Corp. 1999, 2011 1


corporation can be a buyer, a seller, or both. It could also be a retailer, a
manufacturer, or both. Whatever form the multi-divisional corporation takes, it
normally has multiple channels with different types of customers, such as,
consumers, retailers, dealers, and original equipment manufacturers.

In the multi-divisional corporation model, each division might be set up as an


Enterprise in Sterling Selling and Fulfillment FoundationSterling Application
Platform. This setup allows both segregation of transactions by division and global
visibility at the corporate level. Each Enterprise configures their own business
rules, workflow, and transaction processing.

Third-Party Logistics
Traditional third-party logistics companies provide a range of outsourced services
such as warehousing, transportation, and contract manufacturing.

Large companies can gain the competitive advantage through the real-time
management of their supply chains. These advantages include lower costs and
improved customer service. Additionally, new sales channels such as web stores,
hand-held devices, and in-store kiosks provide companies new methods of
reaching their customers. All of these issues have increased the complexity of the
fulfillment process.

In the third-party logistics model, each client might be set up as an Enterprise. This
setup allows the third-party logistics Hub to have visibility of all transactions in
the Hub environment, while the clients that are set up as Enterprises only have
visibility to their own transactions. This allows the third-party logistics business to
provide unique transaction processing to its clients.

Marketplace
A marketplace is an online intermediary that connects Buyers and Sellers.
Marketplaces eliminate inefficiencies by aggregating offerings from many Sellers or
by matching Buyers and Sellers in an exchange or auction. For Buyers, they lower
purchasing costs and help them reach new Sellers. For Sellers, they lower sales
costs and give them access to new customers. It is a central location, or Hub,
where a trusted intermediary integrates both procedures and technology to lower
the costs and enhance the effectiveness of Buyer and Seller transactions.

In the marketplace model, each market might be set up as an Enterprise. This


setup allows each market to be unique with their own product or service handling.

Application Platform Platform Configuration


Sterling Selling and Fulfillment FoundationSterling Application Platform is a
collection of common components used across the application. These components
are the infrastructure upon which all other business application modules in
Sterling Selling and Fulfillment FoundationSterling Application Platform are built.

In the Applications ManagerConfigurator you can use the Application Platform


configuration grouping to establish various aspects of Sterling Selling and
Fulfillment FoundationSterling Application Platform for your business applications.

Participant Modeling
The Applications ManagerConfigurator’s Participant Modeling is used to create
and maintain organizations and their relationships. Once an organization has been

2 Sterling Selling and Fulfillment Foundation: Application Platform Configuration Guide


created, it is possible to define each organization’s role, the services they provide
and utilize, and the business elements required to support the collaborative
processes between all of the participating organizations in the Hub. For more
information about Participant Modeling, see Chapter 3, “Configuring Participants,”
on page 23.

Process Modeling
The Process Modeling defines process type details pipelines for business document
types. A process type consists of one or more pipelines with the different statuses
that a specific document type, such as a Sales Order, goes through during the life
cycle of that process type. For more information about the Process
ModelingProcess Modeling, see Chapter 4, “Configuring Process Models,” on page
119.

Security
Security must be set up to allow users access to the actions, views, and data within
the user interface of the Application ConsoleConsole and the Applications
ManagerConfigurator. A user’s access is limited to only those to which they have
permission and data security rights.

Security is used to create users, user groups, and teams. For more information, see
Chapter 5, “Configuring User Security,” on page 187.

System Administration
System Administration is used to configure system level information used
throughout the Sterling Selling and Fulfillment FoundationSterling Application
Platform infrastructure. Through system administration system purge criteria, user
exit implementations, and installation-time rules can be defined. For more
information, see Chapter 6, “Configuring System Administration Components,” on
page 219.

Unit of Measure
Unit of Measure is used to define standard units of measure to associate with your
items and locales. Sterling Selling and Fulfillment FoundationSterling Application
Platform provides unit of measure classifications for dimension, volume, weight,
and time. In addition to defining new units of measure, Sterling Selling and
Fulfillment FoundationSterling Application Platform provides the ability to create
conversion rates between different units of measure. For more information, see
Chapter 7, “Configuring Units of Measure,” on page 241.

Internationalization
Internationalization provides a set of rules and common codes that can be used
when implementing Sterling Selling and Fulfillment FoundationSterling
Application Platform in different international locales. Internationalization can be
used to define country or region codes, language codes, date and time formats,
and currency conversion rates. For more information, see Chapter 8, “Configuring
Internationalization Rules,” on page 253.

Presentation
Presentation is used to configure locales, menus, themes, and resources necessary
for user interface extensibility. For more information, see Chapter 9, “Configuring
Presentation Components,” on page 265.

Chapter 1. Introducing Sterling Application Platform 3


Communication
Communication is used to configure business communication components that
define the codes and documents used to communicate between Sterling Selling and
Fulfillment FoundationSterling Application Platform and external systems as well
as different business organizations within a business model. For more information,
see Chapter 10, “Configuring Business Communication Components,” on page 291.

Nomenclature
Nomenclature provides components used to create a mapping of unique terms you
use in your business model to a set of unique terms your trading partners use. For
more information, see Chapter 11, “Configuring Nomenclature Components,” on
page 297.

Queue Management
Queue ManagementQueue Management is used to create queues for different users
and types of alerts. These queues can be designed to notify specified users of alerts
at configured levels and times. Queue ManagementQueue Management is also
used to define how the configured users are notified. For more information, see
Chapter 12, “Configuring Alert Queues,” on page 305.

Region Definition
Region Definition provides the components that are used by the Sterling Selling
and Fulfillment FoundationSterling Application Platform geography engine. The
individual components, consisting of regions and region levels, can be used to
create region schemas that can then be used throughout the Sterling Selling and
Fulfillment FoundationSterling Application Platform business application models
whenever geography is considered. For more information about Region Definition,
see Chapter 13, “Configuring Region Definitions,” on page 311.

Alert Management
Alert management allows a user to create new exception types, organization
exception types, queues, and exception routing rules. Exception types are
maintained at the Hub level and contain information such as which queue the
exception is assigned to, the default priority of the exception, and the high priority
threshold. The lower the priority number, the higher the alert's priority is. The high
priority threshold value is used to determine what alerts are of a high priority. Any
alert with a priority number lower than that of the high priority threshold is
considered high priority. There are also several PCA specific fields that can be
configured here, such as Consolidation Hook, Resolution Hook, and Resolution
Wizard.

When overriding an exception type for a particular organization in order to enable


it to route to a different queue or be raised with a different priority, you can create
a new organization exception type. On the organization exception type, you can
configure complex routing rules to determine what queue the exception is placed
in upon creation. The organization exception type can also be configured to send
an email notification if an exception of its type is raised. These organization
exception types are maintained at the organization level. You can only override an
exception once for a particular organization.

For more information about alerts, see Chapter 17, “Configuring Alerts,” on page
337.

4 Sterling Selling and Fulfillment Foundation: Application Platform Configuration Guide


Chapter 2. Navigating the Configurator Applications Manager
Starting the Applications Manager
About this task

To access the Applications Manager:

Procedure
1. Point your browser to http://<hostname>:<portname>/
smcfs<application_name>/console/start.jsp
where,
v hostname is the computer name or IP address of the computer where Sterling
Selling and Fulfillment FoundationSterling Application Platform is installed.
v portnumber is the listening port of the computer where Sterling Selling and
Fulfillment FoundationSterling Application Platform is installed.
The browser displays the Sign In window.
2. Enter your login ID and password and choose the Sign In button. The Console
Home Page is displayed.
3. From the menu bar, choose Configuration > Launch Configurator. The
Applications Manager opens in a new window.
Additionally, enterprise users who maintain an enterprise can access the
Applications Manager by means of http://<Sterling Selling and Fulfillment
FoundationSterling Application Platform installation server>/
smcfs<application_name>/console/login.jsp.
If both the Applications ManagerConfigurator and the monitor in the System
Management Console Application System Management are opened at the same
time, and if a dialogue window is opened in either application, the other stops
responding to user input until that dialogue window is closed. This is due to a
bug in the Java platform.

The Applications Manager Layout


The Applications Manager is a graphical user interface that can be used to
configure different aspects of Sterling Selling and Fulfillment FoundationSterling
Application Platform. The different configurations are defined by logical groupings
called applications that can be accessed from the Applications Manager menu bar.

© Copyright IBM Corp. 1999, 2011 5


Figure 1. Applications Menu

Each application focuses on a particular aspect of Sterling Selling and Fulfillment


FoundationSterling Application Platform and contains all of the rules, common
codes, and settings necessary for Sterling Selling and Fulfillment
FoundationSterling Application Platform to work in a real-world business setting.

The following applications can be configured in this version of Sterling Selling and
Fulfillment FoundationSterling Application Platform:
v Distributed Order Management
v Global Inventory Visibility
v Catalog Management
v Logistics Management
v Supply Collaboration
v Reverse Logistics
v Warehouse Management
v Application Platform

When you select the application that you want to configure, the Applications
Manager displays a side panel containing all of the available configuration rules
for the selected application and a work area in which these rules can be
configured.

6 Sterling Selling and Fulfillment Foundation: Application Platform Configuration Guide


Figure 2. The Standard Applications Manager Interface

Application Rules Side Panel


The application rules side panel displays a hierarchical tree of elements specific to
processes used within the application.

Figure 3. Example of Application Rules Side Panel

Chapter 2. Navigating the Configurator Applications Manager 7


The application rules side panel also identifies the organization you are
configuring rules for and what, if any, rules are inherited from another
organization.

You can use the application rules side panel for accessing configuration screens,
determining inheritance, and loading another organization's rules.

Accessing Configuration Screens


The main purpose of the application rules side panel is to provide an interface to
access the application’s individual configuration screens. To access a configuration
screen, browse through the application tree and double-click on the applicable
configuration element, the element’s configuration screen displays in the work
area.

Determining Inheritance
In Sterling Selling and Fulfillment FoundationSterling Application Platform, when
an Enterprise is created it can inherit all or part of an existing Enterprise's
configuration rules. This inheritance is done at the configuration group level. A
configuration group is a classification of similar configuration elements. For
example, all of the rules and configurations dealing with items are grouped
together into one configuration group and all of the rules and configurations
dealing with organizations are grouped into another.

An administrator organization is set for every organization defined within the


system. Only the administrator organization can modify the rules defined for a
particular organization. If a particular organization administers multiple
organizations, then they can load the rules of organization that it administers
within the application tree. For more information about loading another
organization's rules, see “Loading Another Organization's Rules” on page 13.

Configuration groups are associated with organization levels. Organization levels


determine how configuration groups are inherited and which organizations can
maintain them. The organization levels defined in Sterling Selling and Fulfillment
FoundationSterling Application Platform are:
v Hub Level - Configuration groups that are associated with the Hub organization
v Enterprise Level - Configuration groups that are associated with the individual
Enterprise organizations within the Hub environment
v Catalog Organization - Configuration groups that are associated with the
organization(s) that maintains the catalog(s) within the Hub environment
v Inventory Organization - Configuration groups that are associated with the
organization(s) that maintains the inventory within the Hub environment
v Pricing Organization - Configuration groups that are associated with the
organization(s) that maintains the pricing within the Hub environment
v Organization - Configuration groups that are associated with any organization
within the Hub environment

The Applications Manager does not load configuration data and permissions based
on Data Access Policies that are described in the Sterling Selling and Fulfillment
Foundation: Application Platform Configuration Guide.

Enhanced Inheritance for Process Models

An Enterprise can inherit the configurations of the following entities from other
Enterprises:

8 Sterling Selling and Fulfillment Foundation: Application Platform Configuration Guide


v Pipelines
v User Exits
v Services
v Actions
v Conditions
v Statuses
v Transactions
v Events

When an Enterprise inherits these entities from some other Enterprise, the current
Enterprise can view the configurations that are inherited from all other Enterprises
(including the Hub) in the inheritance hierarchy. In addition, the current Enterprise
can view the configurations that are defined for the Hub.

For example, consider the following inheritance hierarchy:

In this hierarchy, Enterprise E1 is inheriting from Enterprise E2, which in turn is


inheriting from Enterprise E3. Enterprise E1 can view the configurations that are
defined for Enterprise E2 and Enterprise E3. In addition, Enterprise E1 can view
the configurations that are defined for the Hub.

Organization Level Rules


The following table details the rules used to determine which organizations can
maintain a configuration group as defined by the organization level. The table also
describes the rules that determine how configuration groups are inherited when an
organization is created.
Table 1. Organization Level Rules
Organization Organizations That Can Modify
Level at this Level... Inheritance Details
Hub Level Only the Hub organization can All organizations share this
modify configuration groups at information.
the Hub level. All other
organizations have read-only
access.

Chapter 2. Navigating the Configurator Applications Manager 9


Table 1. Organization Level Rules (continued)
Organization Organizations That Can Modify
Level at this Level... Inheritance Details
Enterprise Level Only Enterprise organizations An Enterprise can inherit this
can modify configuration groups configuration from another
at the Enterprise level. Enterprise. Additionally, this
configuration can be overridden at a
Any business transaction configuration group level.
requiring Enterprise
configuration is picked up from An Enterprise can view the
the Enterprise established by the configurations that are defined for
transactional context. For the other Enterprises (including the
example, order documents have Hub) in the inheritance hierarchy. In
a specific Enterprise. addition, the Enterprise can view the
configurations that are defined for
the Hub.
Catalog Organizations that are designated None.
Organization as catalog organizations can
modify configuration groups at
the catalog organization level.
Inventory Organizations that are designated None.
Organization as inventory organizations can
modify configuration groups at
the inventory organization level.
Pricing Organizations that are designated None.
Organizations as pricing organizations can
modify configuration groups at
the pricing organization level.
Organization Any organization assigned a role None.
(Seller, Buyer, etc.) can modify
configuration groups at the
organization level.

You cannot inherit from an Enterprise that does not have the same inventory,
capacity, and catalog organizations as the organization you are configuring.

Applications Rule Side Panel


The application rules side panel displays rules that have been inherited as grayed
out.

10 Sterling Selling and Fulfillment Foundation: Application Platform Configuration Guide


Figure 4. Inherited Rules in the Application Rules Side Panel

As stated in the table above, depending on the organization you are logged in as,
you may be able to override some inherited rules. If a rule can be overridden, the
Override Configuration icon becomes available in the application rule side panel
when you highlight the rule.

Figure 5. Override Configuration Icon

When you choose to override a rule you also override any other rules in the
configuration group the rule you are overriding is associated with. When you
choose the Override Configuration icon the Configuration Override Details pop-up
window displays. This window provides the list of rules that are overridden.

Chapter 2. Navigating the Configurator Applications Manager 11


Figure 6. Example of Configuration Override Details Pop-Up Window

Overriding a Configuration Group


If you override a configuration group and then decide to "re-inherit" the original
rules, you can choose the Give Back Configuration Ownership icon. This icon
becomes available in the application rules side panel for rules that have been
overridden.

Figure 7. Give Back Configuration Ownership Icon

12 Sterling Selling and Fulfillment Foundation: Application Platform Configuration Guide


When you select the Give Back Configuration Ownership Icon, the Configuration
Override Details pop-up window displays. This window provides the list of rules
that are re-inherited.

Note: If you select the Delete Rules field on the Configuration Override Details
pop-up window, you give back rule ownership to the organization you originally
inherited from, but you do not retain any of the rules that you inherited from
them. If you do not select this field, you give back rule ownership to the
organization you originally inherited from, but you retain the rules that you
inherited from them.

Loading Another Organization's Rules


About this task

An administrator organization is set for every organization defined within the


system. Only the administrator organization can modify the rules defined for a
particular organization. If a particular organization administers multiple
organizations, then they can load the rules of organization that it administers
within the application tree. See Table 1 on page 9 for the rules that determine
which organizations you can administer.

The rules that are available from the tree in the application rules side panel may
vary depending on the type of organization you select and the roles it has been
assigned.

To load another organization's rules:

Procedure

1. From the applicable application rules side panel, choose . The Load
Organizations for Configuration pop-up window displays.

2. From Organization, select the organization that you want to work with.
3. Choose OK. The organization's rules display in the application rules side panel.

Results

The application rules side panel displays the organization you are working with in
parentheses.

Chapter 2. Navigating the Configurator Applications Manager 13


Work Area
The work area is the main area in which different configuration screens appear.
The main types of screens that you can see in the work area are the Search, List,
Details, and Drag and Drop windows.

Search Window
A search window provides you with a means to perform a filtered search. The
upper panel of a search window offers criteria applicable to the entity you are
searching through which you can narrow your search. The lower panel lists the
results of a search once it has been performed.

Figure 8. Search Window Example

List Window
When you choose to configure a specific rule or code that does not require a
search, the Applications Manager may display a basic list window of the rules and
codes that have previously been configured.

14 Sterling Selling and Fulfillment Foundation: Application Platform Configuration Guide


Figure 9. List Window Example

Details Window
A details window is the main interface through which a bulk of the configuration
is done. A details window can contain editable fields and tables, tabs to configure
different aspects of an entity, and additional actions that can be performed on an
entity.

Chapter 2. Navigating the Configurator Applications Manager 15


Figure 10. Details Window Example

Drag and Drop Window


You can use a graphical drag and drop window to ease the construction of
pipelines, pipeline determination, event handlers, status monitoring rules, and
services. A drag and drop window consists of a pallet and a graphical work area.

16 Sterling Selling and Fulfillment Foundation: Application Platform Configuration Guide


Figure 11. Drag and Drop Window Example

To begin building any of these entities, choose a component, such as a transaction,


from the pallet. Drag the component into the graphical work area. The transaction
is now displays as a graphical representation of itself.

To connect one component to another, you must drag the mouse from the outgoing
port of a component until it forms a connecting line with the incoming port of
another component. The links between components can be set up either
horizontally or vertically.

To delete components or links, right-click on the component and choose Delete.


Once components and links have been established you can move them around by
dragging them, the links redraw themselves according to the new position. If you
press and hold the CTRL key while dragging a component, the component is
copied within the graphical work area.

Actions Available in the Applications ManagerConfigurator


Through the Applications ManagerConfigurator, you can use the lookup
functionality, view logged in users, use lists and list filtering, use Context-Sensitive
Help, troubleshoot errors, and use special characters.

Chapter 2. Navigating the Configurator Applications Manager 17


Using the Applications Manager's Lookup Functionality
Throughout the Applications Manager there are many fields that have a lookup
functionality to find or create additional records as they pertain to that field. For
example, on the Primary Info tab of the Organization Details screen, the Locale
field has a lookup functionality to create a new locale from that screen. When you
choose the Create New lookup button the Locale Details information displays in a
pop-up screen for you to modify.

Figure 12. Lookup Icon Example

The information that displays in a lookup field varies depending on how many
records you have pertaining to that particular field. When there are 20 or less
records, the lookup displays as a drop-down list with a Create New button. When
there are between 21 and 75 records, the lookup displays as a drop-down list with
a Search button.

When there are more than 75 records, the lookup displays as a text box with a
Search button. You can type the value in the text box or search for the value using
the Search button. If you enter a value, it is validated when it is saved. You should
always type the value as it would appear if it was displayed as a drop-down list.
For example, for a currency lookup, you should type the currency description in
the text box even though the currency code is saved in the table. An error displays
on save if the user has entered an invalid value.

When you use a lookup for a particular field in the Applications Manager, you
should refer to the corresponding section in this guide to set up the particular
information.

Viewing the Document Types Associated with an Application


In the Distributed Order Management, Supply Collaboration, Reverse Logistics,
and Logistic Management configuration applications, you can view all of the
document types associated with the application. Sales Order, Transfer Order,
Master Order, Quote, and Purchase Order are all examples of document types.

To view an application's associated document types, open the applicable


application from the menu and choose from the application rules side panel.
The Associated Document Types window displays displaying a list of all of the
document types associated with the application you are working in.

18 Sterling Selling and Fulfillment Foundation: Application Platform Configuration Guide


Figure 13. Associated Document Types Window

Adding a Document Type to an Application


About this task

You can add a document type that is associated with another application to the
application you are currently working in.

An added document type's associated screens may be irrelevant to the application


you are associating it with.

To add a document type to an application:

Procedure

1. From the Associated Document Types window, choose . The Associated


Document Type pop-up window displays.

2. From Document Type, select the document type that you want to associate with
the application.
3. Select Enable Access To This Document Through This Application's Console.

Chapter 2. Navigating the Configurator Applications Manager 19


4. Choose .

Viewing the User Logged into the Applications Manager


About this task

You can view the user logged into the Applications Manager and their locale at
any time. To view this information, move your mouse over the User icon and
Locale icons in the bottom right-hand corner of the application to display the tool
tips.

Using Lists and List Filtering


About this task

When viewing any list in the Applications Manager, it is possible to filter the
contents of the list based in criteria that you define. Filtering is accomplished by
right-clicking anywhere on the list's column headings and using the Table Filter
Editor associated with the list.

Figure 14. Column Headings in a List

Table 2. Table Filter Editor Window


Field Description
Apply To Existing Records Checking this box applies a new filter set of results that have
been previously filtered instead of the whole set.
Max Records Specify the maximum number of records that are to be
returned from a filter. The default number is 100
Dynamic Fields Fields such as "Hold Type" and "Hold Type Description" in
Figure 15 on page 21 are dynamically populated based on the
list you are currently viewing.

These fields can be searched using text strings combined with


criteria such as Is, Starts With, or Contains.

Table Filter Editor Window Example:

20 Sterling Selling and Fulfillment Foundation: Application Platform Configuration Guide


Figure 15. Hold Type: Sales Order

Search strings are case sensitive. For example, "Item" does not return the same
values as "item".

Date and Time Entry


Date fields through the Applications Manager have a calendar icon that can be
used to find dates as it pertains to that field. When you click on this icon, a small
calendar displays. You can navigate through this calendar to determine the
appropriate date. For example, on the Create Calendar window, the Default
Effective To field has a calendar icon that you can use to verify the appropriate
ship by date to populate the field.

Figure 16. Calendar Icon example

You can also enter time of day information throughout the Applications
ManagerConfigurator. To do this, double click on the time field, and enter the time
of day.

Figure 17. Time Field example

Time should be entered in a 24 hour time format everywhere throughout the


Applications Manager Configurator.

Using Context-Sensitive Help


About this task

You can access the Sterling Selling and Fulfillment FoundationSterling Application
Platform Context-Sensitive Help by clicking the Help button.

Chapter 2. Navigating the Configurator Applications Manager 21


Troubleshooting Errors
About this task

You can view the description and cause of any error raised in Sterling Selling and
Fulfillment FoundationSterling Application Platform, as well as the actions to
troubleshoot it.

To view the Sterling Selling and Fulfillment FoundationSterling Application


Platform system error descriptions:

Procedure
1. From the menu bar, choose Help > Troubleshooting. The Error Search window
displays.

2. Enter the applicable search criteria and choose . A list of error codes and
their descriptions display.

3. Choose to view the cause of the error and action to troubleshoot it.

Using Special Characters


Throughout the Applications Manager there may be instances where you need to
use special characters in data entry. For information about the use of special
characters in Sterling Selling and Fulfillment FoundationSterling Application
Platform, see the Sterling Selling and Fulfillment Foundation: Customization Basics.

22 Sterling Selling and Fulfillment Foundation: Application Platform Configuration Guide


Chapter 3. Configuring Participants
Trading partners using Sterling Selling and Fulfillment FoundationSterling
Application Platform to perform supply chain collaborative commerce are called
Participants. Each Participant is considered an organization with a defined role.

Creating and Modifying an Organization


About this task

To create an organization:

Procedure
1. From the tree in the application rules side panel, choose Participant Modeling >
Participant Setup. The Organization Search window displays in the work area.

2. Choose . The Create Organization pop-up window displays.


3. Enter information in the applicable fields. Refer to Table 3 on page 24 for field
value descriptions.
4. Choose . The Organization Details window displays.

© Copyright IBM Corp. 1999, 2011 23


Table 3. Create Organization Popup
Field Description
Organization Code Enter a unique code that identifies the organization.
Organization Name Enter the name of the organization.
DUNS Number Enter a unique nine-digit identification sequence, which
provides unique identifiers of single business entities. Sterling
Selling and Fulfillment FoundationSterling Application
Platform does not associate any logic with the DUNS number.
Account Number With Hub If the organization is not the Hub, enter the account number
that the organization has with the Hub.
Locale Choose the organization's geographic location from the
drop-down list.
Parent Organization Choose the parent organization from the drop-down list.
Organization Is An Check this box to configure the organization as an Enterprise.
Enterprise Note: The Primary Enterprise drop-down list is disabled
when you select this checkbox.

24 Sterling Selling and Fulfillment Foundation: Application Platform Configuration Guide


Table 3. Create Organization Popup (continued)
Field Description
Assigned Colony Id From the drop-down list, select the Colony ID or DEFAULT
Colony ID. The DEFAULT Colony ID is installed
automatically with Sterling Selling and Fulfillment
Foundation. If you do not make a selection, DEFAULT is
assumed.
Note: This selection is available only if the Organization Is
An Enterprise check box is enabled and if this organization is
part of a multi-schema deployment.
Primary Enterprise Select the appropriate primary enterprise from the drop-down
list when the 'Organization Is An Enterprise' checkbox is not
selected.

This Primary Enterprise is the default enterprise displayed on


the entry point for order console screens (for example, on
search screens and create screens).

On the Organization Details screen, when creating or


modifying a node organization, the actions that appear on the
Primary Info tab of the node attributes tab are the actions
created for that enterprise. Whenever any enterprise level
configuration is retrieved for a specific organization, the rules
are always retrieved for the Primary Enterprise of that
organization.
Note: The 'Primary Enterprise must be specified.' error is
thrown while saving, if neither 'Organization Is An
Enterprise' checkbox nor an appropriate primary enterprise is
selected from the drop-down list.
Organization is a Check this box to indicate that the organization is a
Fulfillment Node fulfillment node.

In Node, select the node type from the drop-down list.


Choose to create a node type. For more information
about creating node types, see “Creating Node Types” on
page 117.
Organization is a Yard Check this box to indicate that the organization is a yard.
Address Enter the address of the organization's corporate
headquarters. This information is mandatory.

Choose to enter the address.

Choose the Contact tab to view additional contact


information.

You can also specify Latitude and Longitude coordinates for


this address.

Latitude and Longitude need to be entered using decimal


format with a range of -90 to +90 for latitude and -180 to
+180 for longitude.

Note: A user cannot create a node unless the node that is being created will be
automatically accessible to the user after creation.

The newly created node will be automatically accessible to the user in the
following scenarios:

Chapter 3. Configuring Participants 25


v The user who creates the node is an Enterprise user, and
– no team is associated to the user
– the user's team's ShipNode access is set to "All Nodes"
– the user's team's ShipNode access is set to "User's Node", and the user's
enterprise is the parent of the node that is being created
– the user's team's ShipNode access is set to "Nodes Accessible to Team
Creator", and the user who has created the team has automatic access to
the newly created node
v The user who creates the node is a Node user, the user's team's ShipNode
access is set to "Nodes Accessible to Team Creator", and the user who has
created the team has automatic access to the newly created node.

Any user who has access to a restricted set of nodes in the user's team
configuration cannot create a ship node. Also, if the user is a Node user, and no
team is associated to that user, the user cannot create a ship node.

Defining an Organization's Primary Information


About this task
An organization's primary information provides general information about the
organization and the organization's corporate and contact addresses.

To set up an organization's primary information:

Procedure
1. In the Organization Details window, choose the Primary Info tab.
2. Enter information in the applicable fields. Refer to Table 4 on page 27 for field
value descriptions.
3. Choose .

26 Sterling Selling and Fulfillment Foundation: Application Platform Configuration Guide


Table 4. Primary Info Tab
Field Description
DUNS Number Enter the unique nine-digit identification sequence, which
provides unique identifiers of the business entity.
Primary URL Enter the URL of the organization's Internet address, if
applicable.
Administered By Select the organization code of the organization that you
want to administer this organization. Only the selected
organization can make any changes to this organization in the
Applications Manager.
Locale Select the organization's geographic location.
Resource Identifier Enter the Resource Identifier for the organization.
Parent Organization Choose in the organization hierarchy who is the parent
organization.
Organization Suffix Enter the organization suffix for the organization. The
organization suffix is used when creating a buyer
organization for a business customer.
Legal Entity Select this field if this organization is its own legal entity.

A legal entity is an organization unit identified by local


governments as operating units and are typically instituted
for each country or region a business operates in. The
organizational unit is typically self-contained and is involved
in recording all relevant transactions and generating all
supporting documents for financial statements.

For example, if you are a 3PL and have configured your 3PL
as a Hub organization comprised of two Enterprises, one in
the United States and one in India, both the US and Indian
Enterprise organizations are their own legal entities.

Important: If you are configuring a Seller organization, be


aware that the Seller organization of one legal entity cannot
fulfill orders by sourcing directly from another legal entity. In
this case you would need to create a procurement purchase
order with the organization.

A procurement purchase order is a type chained order that is


created when the final shipping point to the customer is a
node within your organization and the shipping node does
not have enough stock and needs to be replenished from an
external organization's node.
Assigned Colony Id A read-only field that displays the Colony ID that was
selected in the Create Organization screen. If no selection was
made, DEFAULT is assumed.
Note: This field displays only in a multi-schema deployment.

Chapter 3. Configuring Participants 27


Table 4. Primary Info Tab (continued)
Field Description
Address The address of the organization's corporate headquarters.
This information is mandatory.

Choose to enter an address.

Choose the Contact tab to view additional contact


information.

You can also specify Latitude and Longitude coordinates for


this address.

Latitude and Longitude need to be entered using decimal


format with a range of -90 to +90 for latitude and -180 to
+180 for longitude.
Contact Address The address of the organization's main contact. This may be
different than the Corporate Address. This information is
mandatory.

Choose to enter an address.

Choose the Contact tab to view additional contact


information.

You can also specify Latitude and Longitude coordinates for


this address. If specified for a node, these coordinates are
used to plot the node on the Fulfillment Network Model. For
more information about the Fulfillment Network Model, see
the Sterling Selling and Fulfillment Foundation: Distributed Order
Management Configuration Guide.

Latitude and Longitude need to be entered using decimal


format with a range of -90 to +90 for latitude and -180 to
+180 for longitude.

The Organization's Roles and Participant Associations


For an organization to function as desired it must be given one or more roles. Each
organization is assigned at least one role. A role is a well-defined set of activities
that can be performed by an organization. Each organization performs at least one
role. Sterling Selling and Fulfillment FoundationSterling Application Platform
supports the following organization roles:
v Buyer
v Carrier
v Enterprise
v Hub
v Node
v Seller

Buyer

An organization is assigned the Buyer role when it purchases product from the
Enterprise or other organizations set up as Sellers.

28 Sterling Selling and Fulfillment Foundation: Application Platform Configuration Guide


A Buyer organization can participate with multiple Enterprises, but must assign a
primary Enterprise with whom it participates. When it assigns its primary
Enterprise, it takes on that Enterprise's inventory and catalog consolidation rules.
When it interacts with multiple Enterprises it acts within the boundaries of the
individual Enterprise's business rules.

Buyers can configure relationships with Seller organizations as well as Buyer


services.

Carrier

An organization is assigned the Carrier role when it provides delivery services


between buyers, sellers, and customers. Special services, such as Next Day Air, can
be offered dependant on the Carrier. United Parcel Service, Federal Express®, and
the United States Postal Service are all examples of carrier organizations.

Carriers can configure the services they provide such as truckload, less-than
truckload, and parcel services.

Enterprise

An Enterprise brokers business. Each organization in an organizational structure


must be either an Enterprise or designate an Enterprise as its primary Enterprise.

Each Enterprise in a Hub can have many organizations that are assigned many
roles.

Note: The Hub also acts as an Enterprise.

Whether or not an entity in a Hub is assigned an Enterprise role depends on the


Hub's business model. For example, in the marketplace model, each market might
be assigned an Enterprise role. This setup allows each market to be unique with
their own product or service handling.

An Enterprise can define organizations that interact within their Enterprise. They
can also set up document definitions to be available across all organizations and
configure an Enterprise's carrier preferences.

An Enterprise in Sterling Selling and Fulfillment FoundationSterling Application


Platform controls the flow of order and logistics documents and is considered the
owner of the various business documents throughout Sterling Selling and
Fulfillment FoundationSterling Application Platform.

An Enterprise defines most of the business rules and fulfillment processes for the
orders. In many cases, such as a sales order, the Enterprise may be the Seller
organization, and for purchase orders, the Enterprise may be the Buyer
organization on the document. In other cases, if a higher level organizational unit
wants to control and enforce business rules and document flow of all it
subsidiaries, an Enterprise can represent this organizational unit and Seller/Buyer
organization would be the subsidiary.

Hub

The Hub is the central organization around which all the other organizations are
built is assigned the role of Hub. There is only one Hub. Typically the Hub is the
entity that purchased Sterling Selling and Fulfillment FoundationSterling

Chapter 3. Configuring Participants 29


Application Platform. The Hub determines what kind of business model is used
during configuration, for example, multi-divisional corporation, third-party
logistics (3PL), or marketplace.

The Hub has the ability to configure the other organizations that interact with
multiple Enterprises and assign their roles. The Hub also determines the document
definitions available to all organizations and configures installation-level rules. The
Hub can be assigned multiple roles, for example, Hub and Seller.

Node

A Node represents a physical location (for example, a manufacturing plant, small


stock room, or warehouse). A node can also play the role of Buyer or Seller.

A node organization is able to see orders for which its parent organization is the
buyer, seller, enterprise, ship node, or receiving node.

Node roles are specified as follows:


v A child Node belongs to a parent organization. It cannot have any child
organizations.
v A Buyer or Seller Node may belong to a parent organization, but it is not
required to. It may have child organizations.

Note: If the organization you are creating participates in one or more


Enterprises, you must identify each Enterprise as an associated participant.

Seller

An organization is assigned the Seller role when it sells product to the Enterprise
or other organizations set up as Buyers. Sellers can configure payment types,
payment rules, and pricing for their organization.

When processing orders, a Seller organization can use the order, planned order,
and purchase order process-type pipelines.

A seller organization can only see orders for which it is the buyer, seller or the
enterprise.

Assigning the Organization's Roles and Participant Associations


About this task

To assign the organization's roles and participant associations:

Procedure
1. In the Organization Details window, choose the Roles & Participation tab.

30 Sterling Selling and Fulfillment Foundation: Application Platform Configuration Guide


2. In the Roles box, select the roles that apply to this organization.

3. In the Enterprises box, choose and select the Enterprises that this
organization participates with from the Participating Enterprises pop-up
window.
4. Select the primary Enterprise for the organization from the Enterprises box, if
applicable.

Defining Enterprise Attributes


If you chose Enterprise as a role for the organization, you can indicate the
organization’s that participate in the Enterprise as well as add and remove the
participation with other organizations. You can also set up the Enterprise’s carrier
preferences.

Defining an Enterprise's Primary Information:


About this task

To define an Enterprise's primary information:

Procedure
1. From the Roles & Participation tab in the Organization Details window, choose
Enterprise Attributes.

2. In Enterprise Name, enter the name of the Enterprise you are configuring.
3. If you want to inherit Enterprise level rules from another Enterprise, from
Inherit Configuration From Enterprise, select the Enterprise whose
configuration you want to inherit.

Chapter 3. Configuring Participants 31


Note: If you do not specify an Enterprise to inherit from, you must configure
all of the rules for the Enterprise you are creating.
4. In UCC Prefix, enter the UCC code to be used when identifying the Enterprise
on a shipment container marking (SCM).
5. In Password Policy, select the password policy that you want to associate with
the enterprise.
For additional information about password policies, see the Sterling Selling and
Fulfillment Foundation: Password Policy Management .
6. If you want to suppress chained order creation even if the seller requires
chained orders, select the Suppress Chained Order Creation Even If Seller
Requires Chained Order check box.

Identifying Organizations that Participate in an Enterprise:


About this task

Many organizations can participate in an Enterprise, such as a Carrier organization


or a Buyer organization.

To identify organizations that participate in an Enterprise:

Procedure
1. From the Roles & Participation tab in the Organization Details window, choose
Enterprise Attributes. The Participants list displays.

2. Choose . The Find Participants to Add Organization pop-up window


displays.

32 Sterling Selling and Fulfillment Foundation: Application Platform Configuration Guide


3. Enter the applicable search criteria and choose . A list of organizations
displays.
4. Select the organization you want to participate in the Enterprise and choose
.

Modifying Organizations Associated with an Enterprise:


About this task

The Enterprise has the ability to modify an associated organization's details.

To modify an organization associated with an Enterprise:

Procedure
1. From the Roles & Participation tab in the Organization Details window, choose
Enterprise Attributes. The Participants list displays.

2. Select the applicable organization and choose . The Organization Details


window for that organization displays.
3. Refer to topics throughout “Creating and Modifying an Organization” on page
23.

4. Choose .

Removing an Organization from Participation in an Enterprise:


About this task

To remove an organization from participation in an Enterprise:

Procedure
1. From the Roles & Participation tab in the Organization Details window, choose
Enterprise Attributes. The Participants list displays.

2. Select the applicable Organization and choose .

Chapter 3. Configuring Participants 33


Defining an Enterprise's Print Format Preferences:
About this task

You can establish default print format preferences for documents and labels.

To set up an Enterprise's Print Format Preferences:

Procedure
1. From the Roles & Participation tab in the Organization Details window, choose
Enterprise Attributes Tab.
2. Select the Print Format Preferences Tab.
3. Enter information in the applicable fields. Refer to Table 5 for field value
descriptions.
4. Choose .

Table 5. Enterprise Attributes Print Format Preferences Tab


Field Description
Print Document From the drop down, select the print document for which
you what to configure preferences.
Default No of Copies Enter the number of copies that should be printed.
Label Format Select which label format should be used with this document
type.

Setting Up an Enterprise's Cost Factor Preferences:


About this task

You can identify the Inventory Costing Factors an Enterprise uses in its business
model. If you define cost factors at the vendor level, you do not need to configure
Enterprise Cost Factor Preferences.

To specify an Enterprise's Cost Factor preferences:

34 Sterling Selling and Fulfillment Foundation: Application Platform Configuration Guide


Procedure
1. From the Roles & Participation tab in the Organization Details window, choose
Enterprise role.
2. Choose the Cost Factor Preferences tab. The Cost Factor Preferences list
displays.

3. Enter information in the applicable fields. Refer to Table 6 for field value
descriptions.

4. Choose .
Table 6. Enterprise's Cost Factor Preference List
Field Description
Cost Factor Group to be Select the cost factor group you want to use for this
Used for Standard Cost enterprise's standard cost calculations from the drop-down
Calculations list.
Cost Factor Group to be Select the cost factor group you want to use for this
Used for Landed Cost enterprise's landed cost calculations from the drop-down list.
Calculations
Cost Factor Group to be Select the cost factor group you want to use for this
Used for Physical Kit Cost enterprise's physical kit cost calculations from the drop-down
Calculations list.

Enterprise Attributes: Defining an Enterprise's Inventory Monitoring Rules:


About this task

If an item is tracked at an Enterprise's node, you can set up minimum and


maximum inventory levels using inventory monitoring rules for an item. When the
item reaches one of these levels, a corresponding event is raised if an action is
configured. That event can then be configured to trigger an alert, if applicable.

For example, you can set a minimum quantity of 75 for a particular item. When
the inventory starts to drop and reaches the minimum level of 75, you can
configure the minimum action to raise the Send E-Mail action. This sends an e-mail
message to notify a manager of the decreasing inventory level.)

You can add, modify, and delete inventory monitoring rules.

To add an inventory monitoring rule to an Enterprise:

Procedure
1. From the Roles & Participation tab in the Organization Details window, choose
Enterprise Attributes.
2. Choose the Inventory Monitor Rules tab. The Inventory Monitor Rules list
displays.

Chapter 3. Configuring Participants 35


3. Choose . The Inventory Monitor Rule pop-up window displays.
4. Enter information in the applicable fields. Refer to for field value descriptions.

5. Choose .

Modifying an Enterprise's Inventory Monitoring Rules:


About this task

To modify an Enterprise's inventory monitoring rule:

Procedure
1. From the Roles & Participation tab in the Organization Details window, choose
Enterprise Attributes.
2. Choose the Inventory Monitor Rules tab. The Inventory Monitor Rules list
displays.

3. Select the applicable inventory monitor rule and choose . The Inventory
Monitor Rule pop-up window displays.
4. Enter information in the applicable fields. Refer to for field value descriptions.

5. Choose .

Deleting an Enterprise's Inventory Monitoring Rules:

36 Sterling Selling and Fulfillment Foundation: Application Platform Configuration Guide


About this task

To delete an Enterprise's inventory monitoring rule:

Procedure
1. From the Roles & Participation tab in the Organization Details window, choose
Enterprise Attributes.
2. Choose the Inventory Monitor Rules tab. The Inventory Monitor Rules list
displays.

3. Select the applicable inventory monitor rule and choose .

Defining Seller Attributes


About this task

If you choose Seller as a role for the organization, you indicate if the Seller requires
payment processing and chained orders as well as set its default payment rule. On
the Seller Attributes tab, if you choose Payment Processing Required, then you
must also select a Default Payment Rule from the drop-down list.

To define a Seller organization's attributes:

Procedure
1. From the Roles & Participation tab in the Organization Details window, choose
Seller Attributes.

Note: The Default Price Program drop-down list is displayed only when you
use the legacy pricing service. For more information about enabling the legacy
pricing service, refer to System Administration Components: Defining
Installation Rules.
2. Enter information in the applicable fields.

Defining a Seller's Print Format Preferences:


About this task

You can establish default print format preferences for documents and labels.

To set up a Seller's Print Format Preferences:

Procedure
1. From the Roles & Participation tab in the Organization Details window, choose
Seller Attributes Tab.
2. Select the Print Format Preferences Tab.
3. Enter information in the applicable fields. Refer to Table 7 on page 38 for field
value descriptions.

4. Choose .

Chapter 3. Configuring Participants 37


Table 7. Seller Attributes Print Format Preferences Tab
Field Description
Print Document From the drop down, select the print document for which
you what to configure preferences.
Default No of Copies Enter the number of copies that should be printed.
Label Format Select which label format should be used with this document
type.

Setting Up a Seller's Cost Factor Preferences:


About this task

You can identify the Inventory Costing Factors a Seller organization uses in its
business model. If you define cost factors at the vendor level, you do not need to
configure Enterprise Cost Factor Preferences.

To specify a Seller's Cost Factor preferences:

Procedure
1. From the Roles & Participation tab in the Organization Details window, choose
the Seller role.
2. Choose the Cost Factor Preferences tab. The Cost Factor Preferences list
displays.

3. Enter information in the applicable fields. Refer to Table 8 on page 39 for field
value descriptions.
4. Choose .

38 Sterling Selling and Fulfillment Foundation: Application Platform Configuration Guide


Table 8. Seller's Cost Factor Preference List
Field Description
Cost Factor Group to be Select the cost factor group you want to use for this seller's
Used for Standard Cost standard cost calculations from the drop-down list.
Calculations
Cost Factor Group to be Select the cost factor group you want to use for this seller's
Used for Landed Cost landed cost calculations from the drop-down list.
Calculations

Seller Attributes: Defining an Enterprise's Inventory Monitoring Rules:


About this task

If an item is tracked at an Enterprise's node, you can set up minimum and


maximum inventory levels using inventory monitoring rules for an item. When the
item reaches one of these levels, a corresponding event is raised if an action is
configured. That event can then be configured to trigger an alert, if applicable.

For example, you can set a minimum quantity of 75 for a particular item. When
the inventory starts to drop and reaches the minimum level of 75, you can
configure the minimum action to raise the Send E-Mail action. This sends an e-mail
message to notify a manager of the decreasing inventory level.)

You can add, modify, and delete inventory monitoring rules.

To add an inventory monitoring rule to an Enterprise:

Procedure
1. From the Roles & Participation tab in the Organization Details window, choose
Enterprise Attributes.
2. Choose the Inventory Monitor Rules tab. The Inventory Monitor Rules list
displays.

3. Choose . The Inventory Monitor Rule pop-up window displays.


4. Enter information in the applicable fields. Refer to for field value descriptions.

5. Choose .

Chapter 3. Configuring Participants 39


Defining Buyer Attributes
If you chose Buyer as a role for the organization, you can indicate the Buyer
requirements for inbound compliance. Inbound compliance are the conditions the
buyer has established for shipping and routing.

Defining Consolidation Parameters:


About this task

To set up a Buyer's Inbound Compliance Consolidation parameters:

Procedure
1. From the Roles & Participation tab in the Organization Details window, choose
the Inbound Compliance Tab.
2. Select the Consolidation Tab.
3. Enter information in the applicable fields. Refer to Table 9 on page 41 for field
value descriptions.

4. Choose .

40 Sterling Selling and Fulfillment Foundation: Application Platform Configuration Guide


Table 9. Inbound Compliance Consolidation Tab
Field Description
Appointment Required Check this box if the buyer requires an appointment to accept
deliveries.
Do not mix in Shipment If any of the following are selected, separate shipments must
be created for items that have different values for these
attributes.

For example, if Department Code is selected, items that are


for different departments can not be included in the same
shipment.
Buyer mark for Check this box if separate shipments must be created based
Node ID on the buyer mark for node id.
Customer PO # Check this box if separate shipments must be created based
on the Customer's Purchase Order number.
Department Code Check this box if separate shipments must be created based
on the department for which the item is intended.
Gift Flag Check this box if separate shipments must be created if the
order line is a gift item.
Level of Service Check this box if separate shipments must be created based
on the order's level of service.
Mark For Check this box if separate shipments must be created based
on the person for whom this shipment is marked for.
Order # Check this box if separate shipments must be created based
on the order number.
Order Type Check this box if separate shipments must be created based
on the buyer defined order type.
Transportation optimization

Chapter 3. Configuring Participants 41


Table 9. Inbound Compliance Consolidation Tab (continued)
Field Description
Economic shipping Economic Shipping Parameters (ESP) are used in shipping
parameters maintained consolidation. Select this field to enable the following
Economic Shipping Parameters fields.

ESP support consolidation of shipments until a weight or


volume threshold is met, or until an certain time elapses. By
consolidating shipments, shipping costs can be reduced

For example, you can set that shipments should be


consolidated until the shipment weight is 300 pounds, or 50
cubic feet in volume. To ensure that eventually the shipment
is set, you can establish a maximum number of days to wait
until the conditions are met.

When either the weight, volume or delay shipment threshold


is met, the shipment is moved to the next stage in shipping.
Expedite shipment by not If shipments can be shipped earlier than their currently
more than __ Days planned shipment date, Enter the number of days the
shipment date can be moved forward.

For example, if shipments can be shipped up to three days


earlier than their current planned shipment date, enter ‘3'.
Delay shipment by not Enter the number of days this shipment can be delayed
more than __ Days before it should be shipped. For example, if a value is set for
weight threshold of 300 pounds, and this field has been set to
3 days, the shipment is shipped after 3 days, regardless of
whether the weight threshold has been met.
Consolidate up to weight Enter a weight.
threshold of
Consolidate up to volume Enter a volume.
threshold of
Do not mix in a load

If any of the following attributes are unselected, a shipment can be consolidated to a load
based on the attribute.

For example, if Addr Line 1 and Name are unselected, shipments that have different first
address line but the same address line 2 and 6 can be included in the same load.
Addr Line 1 Uncheck this box if you want to consolidate the shipment to
a load based on the same first line of address.
Addr Line 2 Uncheck this box if you want to consolidate the shipment to
a load based on the same second line of address.
Addr Line 6 Uncheck this box if you want to consolidate the shipment to
a load based on the same sixth line of address.
Name Uncheck this box if you want to consolidate the shipment to
a load based on the first, middle and last name.

Defining Carrier Preferences Parameters:


About this task

To set up a Buyer's Inbound Compliance Carrier Preferences parameters:

42 Sterling Selling and Fulfillment Foundation: Application Platform Configuration Guide


Procedure
1. From the Roles & Participation tab in the Organization Details window, choose
the Inbound Compliance Tab.
2. Select the Parcel Carrier Preferences Tab.

Results

Defining Carrier Preferences is described in “Defining a Node's Parcel Carrier


Preferences” on page 71. Use those procedures to define and maintain the Carrier
preferences for the Buyer.

Defining Routing Parameters: The Routing Parameters for a Buyer consist of


routing guides. Routing Guides are a list of conditions which determine how a
shipment should be routed. A routing guide has a time period for which is
effective, and conditions for when it should be applied. These conditions are based
on Freight Terms and Department.

Each routing guide contains a list of routing guide lines, each of which describe
detailed conditions for selecting a Carrier. The routing guide information is based
on data used by VICS (Voluntary Interindustry Commerce Standards) routing.

Setting Routing Preferences:


About this task

To set the over all routing preferences of the buyer:

Procedure
1. From the Roles & Participation Tab in the Organization Details window, choose
the Inbound Compliance Tab.
2. Select the Routing Tab.
3. Set the Routing Guide value, as described in Table 10.
Table 10. Routing Guide Preferences
Fields Description
Region Schema For Routing Select the applicable region schema for routing.

Select . The Region Schema Details window displays. For


more information about modifying the region schema details,
see “Defining Region Schemas” on page 313.
Routing Guide
Not Maintained Select this to use manual routing. Shipments are managed in
the shipment console, and any routing guides are not
consulted.
Maintained in Sterling Select this to use the Routing Guides maintained in Sterling
Selling and Fulfillment Selling and Fulfillment FoundationSterling Application
FoundationSterling Platform to determine how shipments should be routed.
Application Platform
In addition to the routing guide maintained here by the
enterprise, there may be a routing guide for the buyer
organization.

Chapter 3. Configuring Participants 43


Table 10. Routing Guide Preferences (continued)
Fields Description
Maintained Externally Select this to indicate that an external routing system is used.
The routing guides maintained in Sterling Selling and
Fulfillment FoundationSterling Application Platform are not
consulted.

Examples of external routing systems include using an


integrated Transportation Management System (TMS), or
implementing a User Exit which consults with the buyer
organization.

Creating a Routing Guide:


About this task

Routing Guides are a list of conditions which determine how a shipment should be
routed. A routing guide has a time period for which is effective, and conditions for
when it should be applied. These conditions are based on Freight Terms and
Department.

Each routing guide contains a list of routing guide lines, each of which describe
detailed conditions for selecting a carrier. The routing guide information is based
on data used by VICS (Voluntary InterIndustry Commerce Standards) routing.

To create a routing guide:

Procedure
1. From the tree in the application rules side panel, choose Cross Application >
Logistics > Outbound Constraints. The Outbound Constraints window displays
in the work area.

2. Select on the Routing Guides list window. The Routing Guide Details
window displays in the work area.
3. Enter information in the applicable fields. Refer to Table 11 on page 45 for field
value descriptions.
4. Choose .

Figure 18. Routing Guide Details Window

44 Sterling Selling and Fulfillment Foundation: Application Platform Configuration Guide


Table 11. Routing Guide Details Window
Field Description
Name Enter a name for the routing guide.
Routing Guide # A number for the routing guide.
Publish Date When this routing guide is available within the system.
Supersedes Routing Tracking information. For example, if a minor revision is
Guide # made to routing guide "1234", you might create a routing
guide "1234-A", and enter that it supersedes routing guide
"1234". This field is for informational purposes and is not
used to determine the effective routing guide.
Effective Date The start date for applying the routing information in this
routing guide. You can use the effective date and expiration
date to apply routing guidelines for particular periods of
time.
Expiration Date The end date for applying the routing information in this
routing guide.
Apply this Routing Guide when
Freight Terms Apply this routing guide when this condition is met. Select is,
is in, or is not. Use:
v is to specify a single Freight Term.
v is in to specify a group of Freight Terms, one of which
must be matched.
v is not in to specify a group of Freight Terms. The routing
guide is used if the Freight Term does not match one of
these values.
Item Classification Items can be classified.

This field displays when valid item classifications have been


set up for Routing Guide.

Modifying a Routing Guide:


About this task

To modify a routing guide:

Procedure
1. From the tree in the application rules side panel, choose Cross Application >
Logistics > Outbound Constraints. The Outbound Constraints window displays
in the work area.

2. Select a routing guide in the Routing Guide list window, and select .
3. The Routing Guide Details window displays in the work area.
4. Enter information in the applicable fields. Refer to Table 11 for field value
descriptions.
5. Choose .

Deleting a Routing Guide:


About this task

To delete a routing guide:

Chapter 3. Configuring Participants 45


Procedure
1. From the tree in the application rules side panel, choose Cross Application >
Logistics > Outbound Constraints. The Outbound Constraints window displays
in the work area.
2. Select the applicable Routing Guide and choose .

Creating a Routing Guide Line:


About this task

Routing guide lines contain the specific conditions to use when routing a shipment.
A routing guide can contain multiple routing guide lines.

When routing occurs, the shipment is matched against the routing guide lines.
Based on the criteria specified, a carrier and carrier service is selected.

When routing results in a change to the shipment destination, the system re-routes,
with the revised destination as the factor for routing. This type of configuration is
used for consolidator nodes. While routing the second time, system looks for the
routing guide entry that contains destination node, but without any other
destination parameters filled out (such as address, etc.).

To create a routing guide line:

Procedure
1. From the Routing Guide Details window, select the Routing Guidelines Tab. To
have access to the Routing Guidelines Tab, save the information you have
entered on the Primary Info Tab.
2. A Routing Guide Line search window displays.

46 Sterling Selling and Fulfillment Foundation: Application Platform Configuration Guide


Figure 19. Routing Guide Details Window

3. Select . A Routing Guide Line Details screen displays in the work area.
4. Enter information in the applicable fields. Refer to Table 12 for field value
descriptions.
5. Choose .
Table 12. Routing Guide Line Details
Setting conditions:

In many of the following fields, you can select is, is in, or is not in and then specify a
value. Use:
v is to specify that a single value must be matched
v is in to specify a group of values, one of which must be matched.
v is not in to specify a group of values. The routing guide line is used if none of these
values match.

For example to match any one of a group of states, specify State is in California,
Washington, Oregon, Nevada. When assessing the condition, California would match,
Florida would not.

Chapter 3. Configuring Participants 47


Table 12. Routing Guide Line Details (continued)
Field Description
Ship From
Node Select the node.
When ship from is not Enter this option if not shipping from the node and then
node, select the following enter one or more of the following conditions.
attribute(s)
Country/Region Select the country or region name(s).
State Enter the state name(s).
City Enter the city name(s).
Zip Code Enter the zip code or zip code range.
Ship To
Node Select the node.
Region Enter the region.
When ship to is not node Select this option if not shipping to a node within a specific
and region, select the region and then select one or more of the following
following attribute(s) conditions.
Country/Region Select the country or region name(s).
State Enter the state name(s).
City Enter the city name(s).
Zip Code Enter the zip code or zip code range.
Consolidator Select the consolidator name(s).
Store# Select the store number(s).
And weight is in the range: You can match weight. For example, if you want packages
that weigh between 100 and 500 pounds to be shipped using
a specific carrier, you would specify From as ‘100' and To as
‘500'.
From Enter the minimum value.
To Enter the maximum value.
And volume is in the You can match volume. For example, if you want packages
range: that are between 3 and 10 cubic feet to be shipped using a
specific carrier, you would specify From as ‘3' and To as ‘10'.
From Enter the minimum value.
To Enter the maximum value.
And handling units are in Number of containers.
the range:
From Enter the minimum value.
To Enter the maximum value.
And if requested carrier
service code is
Carrier Service Code Select a carrier service code.
For more information about defining carrier services, see “Defining Carrier Services” on
page 50.
Then ship via:

48 Sterling Selling and Fulfillment Foundation: Application Platform Configuration Guide


Table 12. Routing Guide Line Details (continued)
Priority Indicates the number to give this rule a relative importance.

When a shipment is compared to the routing guide lines,


there may be two carrier services that could be used. This
priority serves as a tie breaker. The carrier service with the
lowest number is used.
Carrier / Service Indicates the carrier and service code that is desired.
Break Bulk Node The break bulk node that is close to the buyer.
Contact Specified Indicates whether the contact details for the shipment is
specified.
With overrides:
Override Freight Terms Select to override the shipment's Freight Term.
Override Ship To To override the Ship To value, select this field, and then select
one of the following. This is only used when performing
routing again due to a revised ship to address.
Node Select the node name.
Consolidator Select the consolidator name.
Store# Select the store number.

Results

When the conditions set are assessed, the routing guide line which matches the
most conditions is used. For example, imagine there are three routing guide lines:

Routing guide line A - What to do when shipping from Massachusetts

Routing guide line B - What to do when shipping from Massachusetts, and when
shipping from the zip code 01810.

Routing guide line C - What to do when shipping from Massachusetts or NY.

If the shipment originates from the zip code 01810, it matches all of these routing
guide lines. The actions specified in Routing guide line B is used, as more conditions
are met (both the state and the zip code).

If the shipment originates from Massachusetts, but not from zip code 01810, then
both Routing guideline A and Routing guide line C match. The priority on the
guidelines are used to determine which is used, with the lowest numbered priority
being selected. If Routing guideline A had a priority number of 3, and Routing
guideline C had a priority number of 5, Routing guideline A is used.

Modifying a Routing Guide Line:


About this task

To modify a routing guide line:

Procedure
1. From the Routing Guidelines Details window, select the Routing Details Tab. A
Routing Guide Line search window displays.
2. Select a routing guide line in the Routing Guide Line list window, and select
. The Routing Guide Line Details window displays.

Chapter 3. Configuring Participants 49


3. Enter the new information in the applicable fields. Refer to the "Routing Guide
Line Details" table for field value descriptions.
4. Choose .

Deleting a Routing Guide Line:


About this task

To delete a Routing Guide Line:

Procedure
1. From the Routing Guide Lines Details window, select the Routing Details Tab.
A Routing Guide Line search window displays.
2. Select a routing guide line in the Routing Guide Line list window, and choose
.

Defining Carrier Services: When routing occurs, the shipment is matched against
the routing guidelines. Based on the criteria specified, you select a carrier service
to use.

You can use the Carrier Services panel for creating, modifying, or deleting a carrier
service.

Creating a Carrier Service:


About this task

To create a carrier service:

Procedure
1. From the Routing Guidelines Details window, in the Carrier Services panel,
select . The Carrier Services window displays.

50 Sterling Selling and Fulfillment Foundation: Application Platform Configuration Guide


2. Enter information in the applicable fields. Refer to Table 13 for field value
descriptions.
3. Choose .
Table 13. Carrier Services
Field Description
Priority Enter a number to give this rule a relative importance.

When a shipment is compared to the routing guide lines,


there may be two carrier services that could be used. This
priority serves as a tie breaker. The carrier service with the
lowest number is used.
Carrier/Service Select the carrier or service code that is desired.
Break Bulk Node Select the break bulk node that is close to the buyer.
Contact Address This is used to specify the address information for the carrier
service's contact person. Click to change the contact
Address.

Modifying a Carrier Service:


About this task

To modify a carrier service:

Procedure
1. From the Routing Guidelines Details window, in the Carrier Services panel,
select a carrier service from the list in the Carrier Services list window, and
select . The Carrier Services window displays.
2. Enter the new information in the applicable fields. Refer to Table 13 for field
value descriptions.
3. Choose .

Deleting a Carrier Service:


About this task

To delete a carrier service:

Procedure
1. From the Routing Guidelines Details window, in the Carrier Services panel,
select a carrier service in the Carrier Services list window and select .

2. Choose .

Defining Packaging Parameters:


About this task

To set up a Buyer's Inbound Compliance Packaging parameters:

Procedure
1. From the Roles & Participation tab in the Organization Details window, choose
the Inbound Compliance Tab.
2. Select the Packaging Tab.

Chapter 3. Configuring Participants 51


3. Enter information in the applicable fields. Refer to Table 14 for field value
descriptions.

4. Choose .

Table 14. Inbound Compliance Packaging Tab


Field Description
Use units of measure from The buyer may specify units of measure, such as the number
buyer catalog of packages contained in a case, or the number of cases in a
pallet in the buyer catalog.

Select this field to ensure that shipments match these


requirements. If this field is not selected, then the enterprise's
units of measure are used.
Mandate tag information The buyer may mandate tag information for all tag-controlled
for all tag-controlled items items.

Select this field to ensure that the tag information is provided


whenever you ship tag-controlled items to a buyer.
Mandate Serial information The buyer can mandate vendors to provide serial information
for serialized items for all the serialized items shipped to them.

Select this field to ensure that the serial information is


provided whenever you ship serialized items to this buyer.
Shipping Container Marking
SCM not required Select this field if a shipping container marking is not
required on a container.

52 Sterling Selling and Fulfillment Foundation: Application Platform Configuration Guide


Table 14. Inbound Compliance Packaging Tab (continued)
Field Description
SCM required without Select this field if a shipping container marking is required on
content a container but does not have to contain information.
SCM required with content Select this field if a shipping container marking is required on
a container with all applicable information filled out.
SCM Label Level
Do not apply SCM If you selected ‘SCM not required', this field is automatically
chosen.
Apply SCM on all cases If you specified that shipment container markings are
required, choose this field if you want to apply them on cases
only.
Apply SCM on all shipping If you specified that shipment container markings are
units (cases or pallets) required, choose this field if you want to apply them on cases
and pallets.
Do not mix in a case
Customer PO # Select this field if you do not want SKUs for shipments with
different customer purchase order numbers to be packed into
the same case.
Department Code Select this field if you do not want SKUs for shipments with
different department codes to be packed into the same case.
Item ID Select this field if you do not want SKUs with different item
IDs to be packed into the same case.
Mark For Select this field if you do not want SKUs for shipments with
different mark for addresses to be packed into the same case.
Unit Of Measure Select this field if you do not want SKUs with different units
of measure to be packed into the same case.
Product Class Select this field if you do not want SKUs with different
product classes to be packed into the same case.
Do not mix in pallet
Customer PO # Select this field if you do not want SKUs for shipments with
different customer purchase order numbers to be packed onto
the same pallet.
Department Code Select this field if you do not want SKUs for shipments with
different department codes to be packed onto the same pallet.
Item ID Select this field if you do not want SKUs with different item
IDs to be packed onto the same pallet.
Mark For Select this field if you do not want SKUs for shipments with
different mark for addresses to be packed onto the same
pallet.
Unit Of Measure Select this field if you do not want SKUs with different units
of measure to be packed onto the same pallet.
Product Class Select this field if you do not want SKUs with different
product classes to be packed onto the same pallet.

Defining Compliance Services Parameters:


About this task

Compliance service parameters describe additional services that a buyer wants


performed on certain items. A few examples are customization of the items, such

Chapter 3. Configuring Participants 53


as placing a security tag on the item, adding promotional materials in the item's
packaging, or monogramming the item with a corporate logo.

To set up a Buyer's Inbound Compliance Services parameters:

Procedure
1. From the Roles & Participation tab in the Organization Details window, choose
Inbound Compliance Tab.
2. Select the Compliance Services Tab.
3. To enable the use of Compliance services, select the Requires VAS Compliance
box, and specify one or more compliance services that the Buyer wants to be
performed on items.

Creating Compliance Services:


About this task

To create a Compliance Service:

Procedure
1. From the Compliance Services Tab, select .
2. In the Compliance Service Details popup that displays, enter information in the
applicable fields. Refer to Table 15 for field value descriptions.
3. Choose .

Table 15. Compliance Services Details


Field Description
Enterprise Code Indicates the Enterprise for which these criteria should be
applied. A buyer may set up different compliance
requirements interacting with different enterprises.

The Enterprise selected determines the available service items


and classifications based on their catalog organization.

54 Sterling Selling and Fulfillment Foundation: Application Platform Configuration Guide


Table 15. Compliance Services Details (continued)
Field Description
Item Classification The classification code for a group of items. For example, if a
security tag is applied to jewelry worth more than $200, you
may establish an Item Classification “Expensive Jewelry”, and
then classify items as being members of the “Expensive
Jewelry” classification.

When an item of expensive jewelry is ordered, the


compliance service is run. The compliance service defines
what compliance services should be performed on the
jewelry, including adding the security tag.
Compliance Service Identifies the compliance service. The compliance service
describes a series of activities that are performed to meet the
buyer's requirements. These could include adding custom
logos, inserting advertisements, using seasonal promotion
boxes, or many other activities which customize the item for
the buyer.
Run Quantity The number of items to be made when a compliance service
is run. By grouping the production of an item that has
compliance services applied to it, inventory can be created in
anticipation of the buyer's need.

The run quantity is a number that indicates how many items


to batch together: the actual request for product and available
inventory determine how many items should have the
compliance service applied.

For example, if the run quantity is 10, the buyer requests 8 of


the item, and there's only 1 on hand, 10 items have the
compliance services applied. The result is the buyer receives 8
items, 1 from current inventory, 7 that is newly created, and
there are 3 newly created items now available in inventory.

If the buyer requires more than the run quantity produces,


the run quantity is used to create several runs. For example,
if the buyer were to request 22 items, and only 1 item is in
stock, doing a run of 10 would not satisfy the request. Doing
two runs of 10 each would still not satisfy the request, but
doing 3 runs would satisfy the request. Therefore, a single
run of 30 is done.

The run quantity should be set based on the anticipated


buyer requirements. For example, for bulky items such as
refrigerators or washing machines, the number might be low.
For items that the buyer purchases in large quantities, such as
T-shirts embroidered with a sports team logo, the number
might be higher.
Note: When the run quantity is not equal to an actual work
order's ordered quantity, an additional inventory check is
performed during scheduling.

Modifying Compliance Services:


About this task

To modify a Compliance Service:

Chapter 3. Configuring Participants 55


Procedure
1. From the Inbound Compliance window, select the Compliance Services Tab.

2. Select a Compliance Service from the Compliance Services list, and select .
The Compliance Service Details popup window displays.
3. Enter information in the applicable fields. Refer to Table 15 on page 54 for field
value descriptions.
4. Choose .

Deleting Compliance Services:


About this task

To delete a Compliance Service:

Procedure
1. From the Inbound compliance window, select the Compliance Services Tab.

2. Select a Compliance Service from the Compliance Services list, and select .

Defining a Buyer's Print Format Preferences:


About this task

You can establish default print format preferences for documents and labels.

To set up a Buyer's Inbound Compliance Print Format Preferences:

Procedure
1. From the Roles & Participation tab in the Organization Details window, choose
the Inbound Compliance Tab.
2. Select the Print Format Preferences Tab.
3. Enter information in the applicable fields. Refer to Table 16 on page 57 for field
value descriptions.

4. Choose .

56 Sterling Selling and Fulfillment Foundation: Application Platform Configuration Guide


Table 16. Inbound Compliance Print Format Preferences Tab
Field Description
Print Document From the drop down, select the print document for which
you what to configure preferences.
Default No of Copies Enter the number of copies that should be printed.
Label Format Select which label format should be used with this document
type.

Defining Carrier Attributes


If you chose Carrier as a role for the organization, you can specify the types of
services a Carrier provides for truckload, less-than truckload, and parcel
shipments. A carrier service is the service a Carrier provides for the delivery of an
order, such as, Second Day Air.

Defining Carrier Services for Truckload Shipments:


About this task

A Truckload is the largest of the shipping modes. A truckload is normally


considered a shipment of over 10,000 pounds. You can add, modify, and delete
carrier services for the Truckload ship mode.

To create carrier services for truckload shipments:

Procedure
1. From the Roles & Participation tab in the Organization Details window, choose
Carrier Attributes.
2. Choose the TL Services tab, the Truckload Services list displays.

3. Choose . The Truckload Service Details pop-up window displays.


4. Enter information in the applicable fields. Refer to Table 17 on page 58 for field
value descriptions.

5. Choose .

Chapter 3. Configuring Participants 57


Figure 20. Truckload Service Details

Table 17. Truckload Service Details Pop-Up Window


Field Description
Service Select the appropriate service from the drop-down list.
Scac and Service Enter the name of the SCAC and service.
Note: This is populated when the carrier service code is
chosen. You can then edit it as necessary.
Scac and Service Enter a brief description of the carrier SCAC and service.
Description Note: This is populated when the carrier service code is
chosen. You can then edit it as necessary.
Electronic Code Enter the code used by the carrier organization to identify the
service. For example, UPS Next Day Air has the electronic
code '01'.
Host Code This field is not used in this version of Sterling Selling and
Fulfillment FoundationSterling Application Platform.
Extended Ship Mode If the carrier service is not TL, LTL, or parcel, select the
correct shipment mode from the drop-down list.
Fixed Transit Days Enter the maximum number of days that the service allows
for delivery. For example, 1 Day Air would have a maximum
of 1 transit day, whereas Ground may have a maximum of 5
transit days.

This number is used for order line scheduling. This value is


only used if the Use Advanced Transit Time Calculation flag
on the Other Rules tab under Distributed Order Management
> Cross Application > Logistics > Logistics Attributes is
selected. For more information about this field, see the
Sterling Selling and Fulfillment Foundation: Distributed Order
Management Configuration Guide.

58 Sterling Selling and Fulfillment Foundation: Application Platform Configuration Guide


Table 17. Truckload Service Details Pop-Up Window (continued)
Field Description
Distance Per Day Enter the maximum distance that the service travels each
transit day. Choose the relevant UOM for the distance from
the drop-down list.

This number is used for order line scheduling. This value is


only used if the Use Advanced Transit Time Calculation flag
on the Other Rules tab under Distributed Order Management
> Cross Application > Logistics > Logistics Attributes is
selected. For more information about this field, see the
Sterling Selling and Fulfillment Foundation: Distributed Order
Management Configuration Guide.
Allow Shipping Of Check this box to indicate that this carrier allows the
Hazardous Materials shipping of hazardous materials.
Ship By Air Check this box to indicate that this carrier can ship by air.
Has Freezer Check this box to indicate that this carrier can ship items that
require freezer storage.
Restrict Shipping to Choose the type of address from the drop-down list where
Address of Type the carrier can ship.

If you do not select an options, the carrier can ship to both


commercial and residential addresses.
Package Level Integration Choose this if this carrier service caters to package-level
integration.
Shipment Level Integration Choose this if this carrier service caters to shipment-level
integration.
Supports Integration for Check this box to indicate that this carrier service supports
Return Shipping Label integration for return shipping label.

Modifying Carrier Services for Truckload Shipments:


About this task

To modify carrier services for truckload shipments:

Procedure
1. From the Roles & Participation tab in the Organization Details window, choose
Carrier Attributes.
2. Choose the TL Services tab, the Truckload Services list displays.

3. Select the applicable carrier service and choose . The Truckload Service
Details pop-up window displays.
4. Modify information in the applicable fields. Refer to Table 17 on page 58 for
field value descriptions.

5. Choose .

Deleting Carrier Services for Truckload Shipments:


About this task

To delete a carrier service for truckload shipments:

Chapter 3. Configuring Participants 59


Procedure
1. From the Roles & Participation tab in the Organization Details window, choose
Carrier Attributes.
2. Choose the TL Services tab, the Truckload Services list displays.

3. Select the applicable carrier service and choose .

Defining Carrier Services for Less-Than Truckload Shipments:


About this task

A shipment is normally referred to as a less-than truckload shipment when it


weighs between 150 and 10,000 pounds. You can add, modify, and delete carrier
services for the less-than truckload shipping mode.

To create carrier services for less-than truckload shipments:

Procedure
1. From the Roles & Participation tab in the Organization Details window, choose
Carrier Attributes.
2. Enter the PRO Number Length. The PRO Number Length refers to the number
of digits in the PRO Number.
For more information about PRO Numbers and their generation, see “Defining
a Node's LTL Carrier Preferences” on page 78.
3. Choose the LTL Services tab, the Less-Than Truckload Services list displays.

4. Choose . The Less-Than Truckload Service Details pop-up window displays.


5. Enter information in the applicable fields. Refer to Table 18 on page 61 for field
value descriptions.
6. Choose .

60 Sterling Selling and Fulfillment Foundation: Application Platform Configuration Guide


Figure 21. Less-Than Truckload Service Details

Table 18. Less-Than Truckload Service Details Pop-Up Window


Field Description
Service Choose the carrier service code.
Scac and Service Enter the name of the SCAC and service.
Note: This is populated when the carrier service code is
chosen. You can then edit it as necessary.
Scac and Service Enter a brief description of the carrier SCAC and service.
Description Note: This is populated when the carrier service code is
chosen. You can then edit it as necessary.
Electronic Code Enter the code used by the carrier organization to identify the
service. For example, UPS Next Day Air has the electronic
code '01'.
Host Code This field is not used in this version of Sterling Selling and
Fulfillment FoundationSterling Application Platform.
Extended Ship Mode If the carrier service is not TL, LTL, or parcel, select the
correct shipment mode from the drop-down list.
Fixed Transit Days Enter the maximum number of days that the service allows
for delivery. For example, 1 Day Air would have a maximum
of 1 transit day, whereas Ground may have a maximum of 5
transit days.

This number is used for order line scheduling. This value is


only used if the Use Advanced Transit Time Calculation flag
on the Other Rules tab under Distributed Order Management
> Cross Application > Logistics > Logistics Attributes is
selected. For more information about this field, see the
Sterling Selling and Fulfillment Foundation: Distributed Order
Management Configuration Guide.

Chapter 3. Configuring Participants 61


Table 18. Less-Than Truckload Service Details Pop-Up Window (continued)
Field Description
Distance Per Day Enter the maximum distance that the service travels each
transit day. Choose the relevant UOM for the distance from
the drop-down list.

This number is used for order line scheduling. This value is


only used if the Use Advanced Transit Time Calculation flag
on the Other Rules tab under Distributed Order Management
> Cross Application > Logistics > Logistics Attributes is
selected. For more information about this field, see the
Sterling Selling and Fulfillment Foundation: Distributed Order
Management Configuration Guide.
Allow Shipping Of Check this box to indicate that this carrier allows the
Hazardous Materials shipping of hazardous materials.
Ship By Air Check this box to indicated that this carrier can ship by air.
Has Freezer Check this box to indicate that this carrier can ship items that
require freezer storage.
Restrict Shipping to Choose the type address from the drop-down list where the
Address of Type carrier can ship.

If you do not select an option, the carrier can ship to both


commercial and residential addresses.
Package Level Integration Select this option if this carrier service caters to package-level
integration.
Shipment Level Integration Select this option if this carrier service caters to
shipment-level integration.
Supports Integration for Check this box to indicate that this carrier service supports
Return Shipping Label integration for return shipping label.

Modifying Carrier Services for Less-Than Truckload Shipments:


About this task

To modify carrier services for less-than truckload shipments:

Procedure
1. From the Roles & Participation tab in the Organization Details window, choose
Carrier Attributes.
2. Choose the LTL Services tab. The Less-Than Truckload Services list displays.
3. Edit the PRO Number Length. The PRO Number Length refers to the number
of digits in the PRO Number.
For more information about PRO Numbers and their generation, see “Defining
a Node's LTL Carrier Preferences” on page 78.

4. Select the applicable carrier service and choose . The Less-Than Truckload
Service Details pop-up window displays.
5. Modify information in the applicable fields. Refer to Table 18 on page 61 for
field value descriptions.

6. Choose .

Deleting Carrier Services for Less-Than Truckload Shipments:

62 Sterling Selling and Fulfillment Foundation: Application Platform Configuration Guide


About this task

To delete a carrier service for less-than truckload shipments:

Procedure
1. From the Roles & Participation tab in the Organization Details window, choose
Carrier Attributes.
2. Choose the LTL Services tab, the Less-Than Truckload Services list displays.

3. Select the applicable carrier service and choose .

Defining Carrier Services for Parcel Shipments:


About this task

A parcel is the smallest shipping mode. A shipment is normally referred to as a


parcel when it weighs under 150 pounds. You can add, modify, and delete carrier
services for the parcel shipping mode.

To create carrier services for parcel shipments:

Procedure
1. From the Roles & Participation tab in the Organization Details window, choose
Carrier Attributes.
2. Choose the Parcel Services tab, the Parcel Services list displays.
3. Check the Support Domestic Shipping Integration box, if you want to integrate
through the carrier's external systems for domestic shipments.
4. Choose the Carrier Adapter that you want to integrate with the carrier from the
Carrier Adapter Implementation drop-down list.

Note: Only the Carrier Adapters supported for the selected carrier will be
displayed in the drop-down list.
5. Check the Support International Shipping Integration box, if you want to
integrate through the carrier's external systems for international shipments.

6. Choose . The Parcel Service Details pop-up window displays.

Chapter 3. Configuring Participants 63


7. Enter information in the applicable fields. Refer to Table 19 for field value
descriptions.

8. Choose .

Figure 22. Parcel Service Details Pop-Up Window

Table 19. Parcel Service Details Pop-Up Window


Field Description
Service Choose the carrier service code.
Scac and Service Code Enter the name of the SCAC and service.
Note: This is populated when the carrier service code is
chosen. You can then edit it as necessary.
SCAC and Service Enter a brief description of the carrier SCAC and service.
Description Note: This is populated when the carrier service code is
chosen. You can then edit it as necessary.
Electronic Code Enter the code used by the carrier organization to identify the
service. For example, UPS Next Day Air has the electronic
code '01'.
Host Code This field is not used in this version of Sterling Selling and
Fulfillment FoundationSterling Application Platform.
Extended Ship Mode If the carrier service is not TL, LTL, or parcel, select the
correct shipment mode from the drop-down list.

64 Sterling Selling and Fulfillment Foundation: Application Platform Configuration Guide


Table 19. Parcel Service Details Pop-Up Window (continued)
Field Description
Fixed Transit Days Enter the maximum number of days that the service allows
for delivery. For example, 1 Day Air would have a maximum
of 1 transit day, whereas Ground may have a maximum of 5
transit days.

This number is used for order line scheduling. This value is


only used if the Use Advanced Transit Time Calculation flag
on the Other Rules tab under Distributed Order Management
> Cross Application > Logistics > Logistics Attributes is
selected. For more information about this field, see the
Sterling Selling and Fulfillment Foundation: Distributed Order
Management Configuration Guide.
Distance Per Day Enter the maximum distance that the service travels each
transit day. Choose the relevant UOM for the distance from
the drop-down list.

This number is used for order line scheduling. This value is


only used if the Use Advanced Transit Time Calculation flag
on the Other Rules tab under Distributed Order Management
> Cross Application > Logistics > Logistics Attributes is
selected. For more information about this field, see the
Sterling Selling and Fulfillment Foundation: Distributed Order
Management Configuration Guide.
Allow Shipping Of Check this box to indicate that this carrier allows the
Hazardous Materials shipping of hazardous materials.
Ship By Air Check this box to indicate that this carrier can ship by air.
Has Freezer Check this box to indicate that this carrier can ship items that
require freezer storage.
Restrict Shipping to Choose the type of address from the drop-down list where
Address of Type the carrier can ship.

If you do not select an option, the carrier can ship to both


commercial and residential addresses.
Package Level Integration Choose this option if this carrier service caters to package
level integration.
Shipment Level Integration Choose this option if this carrier service caters to shipment
level integration.
Supports Integration for Check this box to indicate that this carrier service supports
Return Shipping Label integration for return shipping label.

Modifying Carrier Services for Parcel Shipments:


About this task

To modify carrier services for parcel shipments:

Procedure
1. From the Roles & Participation tab in the Organization Details window, choose
Carrier Attributes.
2. Choose the Parcel Services tab, the Parcel Services list displays.

3. Select the applicable carrier service and choose . The Parcel Service Details
pop-up window displays.

Chapter 3. Configuring Participants 65


4. Modify information in the applicable fields. Refer to Table 19 on page 64 for
field value descriptions.

5. Choose .

Deleting Carrier Services for Parcel Shipments:


About this task

To delete a carrier service for parcel shipments:

Procedure
1. From the Roles & Participation tab in the Organization Details window, choose
Carrier Attributes.
2. Choose the Parcel Services tab, the Parcel Services list displays.

3. Select the applicable carrier service and choose .

Defining Node Attributes


If you chose Node as a role for the organization, you can specify its primary
information, sourcing, scheduling, carrier preferences, and calendars.

Defining a Node's Primary Information:


About this task

A node's primary information determines how it is identified throughout the


system.

To define a node's primary information:

Procedure
1. From the Roles & Participation tab in the Organization Details window, choose
Node Attributes.
2. Choose the Primary Info tab.
3. Enter information in the applicable fields. Refer to Table 20 on page 67 for field
value descriptions.
4. Choose .

66 Sterling Selling and Fulfillment Foundation: Application Platform Configuration Guide


Figure 23. Node Primary Info

Table 20. Node Primary Info Tab


Field Description
Node Type
GLN Enter the global location number.
Node Type Select the node type for this node from the drop-down list.
Identified By Parent As Enter the name the node's parent uses to identify it.
Agent Criteria Group Select an agent criteria group from the drop-down list.
Export License Number Enter the node's license number used for export shipments.
License Expiration Date Enter the date the export license expires.
BOL Prefix Enter the label this node uses as a prefix on the bills of lading
it creates, if applicable.
Default Declared Value Enter the price that is to be displayed as the default declared
value in the Application Console. This price is typically used
by parcel carriers for computing insurance.
Work Day Hours The standard number of working hours per resource or
person in a day.

This is used to convert hours to days.


Resource Planning Enabled Choose this to enable the planning of resources and activities.
Third Party Logistics Node Choose this if the node is part of a third-party logistics
business model. Chained orders are not created for nodes
marked as a third-party logistics node.

Chapter 3. Configuring Participants 67


Table 20. Node Primary Info Tab (continued)
Field Description
Maintain Inventory Cost Choose this if the node maintains its own inventory costs.
When this option is selected, cost must be entered for each
inventory adjustment that happens at this node. If you choose
this, then inventory adjustments made for this node must be
approved. Adjustments awaiting approval are called pending
adjustments. The actual adjustment does not occur until the
pending adjustment has been approved.
Execution in Node Using
External Application Choose this to have order releases interface through events.
For more information about events, see “Defining
Transactions” on page 140.
IBM Sterling Order Choose this to have order releases interface through the
Management Application Console.
Sterling Warehouse Choose this to have order releases interface through a Sterling
Management System Warehouse Management System.
WMS 6.2 Choose this to have order releases interface through a Sterling
Warehouse Management System version prior to and
including Release 6.2.
Action Name If you chose External Application, select the action to
associate with it. For more information about actions, see
“Defining Actions” on page 176.
Note: In the drop-down, only the Actions linked to the
Primary Enterprise of this Node/Organization are available.
Any actions created from this screen using the + button are
linked to the Primary Enterprise of the User's Organization.
As a result, they may not be available for the
Node/Organization being created.

In a multi-enterprise environment, ensure that Actions are


created for the appropriate Enterprises first (when logged in
as that Enterprise user). Subsequently, mapping of nodes to
actions can be done when logged in either as an Enterprise
user or as a Hub user.
Dock Schedule
Dock Schedules are Select the application that manages the dock schedule.
managed by

Defining a Node's Sourcing and Scheduling:


About this task

Setting up a node's sourcing and scheduling enables you to define how orders are
sourced from the node.

To define node sourcing and scheduling:

Procedure
1. From the Roles & Participation tab in the Organization Details window, choose
the Node Attributes attributes.
2. Choose the Sourcing/Scheduling tab from the right.

68 Sterling Selling and Fulfillment Foundation: Application Platform Configuration Guide


3. Enter information in the applicable fields. Refer to Table 21 for field value
descriptions.

Figure 24. Node Attributes

Table 21. Node Sourcing/Scheduling Tab


Field Description
Do not schedule an order Enter the maximum number of business days that a schedule
to this node more than for an order can be sent to a node for it to be fulfilled. This
<number of days> days number is used when performing earliest schedule date
before expected time of calculations.
shipment
This parameter is only considered if the node is pre-specified
on the order line.
Procure To Ship Allowed Check this box if the node can accept procurement chained
orders. A procurement chained order is a type of order that is
created when a node has to source inventory from another
node. A chained order is an order that is linked to a parent
order in which the life cycle of one effects the other. There are
two types of procurement chained orders: procurement
transfer orders and procurement purchase orders.

A transfer order is a type of chained order that is created


when the node you are configuring needs to replenish their
stock from another node within the organization to fulfill an
order.

A procurement purchase order is a type of chained order that


is created when the node you are configuring needs to
replenish their stock from another node that belongs to an
external organization to fulfill an order.

When setting up procurement from one node to another, you


must define the billing address of each node. Billing
addresses are defined in the Payment Info panel of the
Organization Details screen. Also, a legal entity must be
present in the organization hierarchy for the procured-from
ship node.

Chapter 3. Configuring Participants 69


Table 21. Node Sourcing/Scheduling Tab (continued)
Field Description
Requires Transfer Check this box if you want this node to accept a procurement
Acceptance to confirm availability before proceeding with the order.
Work Order Creation Is Check this box if you want to use Work Orders to support
Allowed compliance services at this node. Work Orders describe the
service activities to customize items based on a buyer's
requests.
Substitution Is Allowed Check this box if substitution of product items within an
order is allowed.
Use End Of Shift Time Check this box if you want the node to base shipment time
by the end of the next feasible shift.

Uncheck this box if you want the node to base shipment time
by any given node parameters, such as Minimum Notification
Time, and the time a shipment can actually be shipped.

For example, a node works five days a week, with two shifts,
8AM - 4PM and 4PM - 8PM.

The node's Minimum Notification Time is set to 2 hours.

If an order is sent to a node on Friday at 1PM, the order is


scheduled to ship on same day at 4PM if Use End Of Shift
Time box is checked. The order is scheduled to ship on same
day at 3PM if Use End Of Shift Time box is unchecked.

If an order is sent to a node on Friday at 3PM, the order


scheduled to ship on same day at 8PM if Use End Of Shift
Time box is checked. The order is scheduled to ship on same
day at 5PM if Use End Of Shift Time box is unchecked.
Note: Use End Of Shift Time is only applicable to nodes that
use a shipping calendar that has shift times defined.
Note: Use End Of Shift Time is only applicable for product
lines.
Gift Wrap Services Allowed Check this box to indicate that this node provides gift
wrapping services.
Item Based Allocation Check this box to allow item based allocation for the item.
Allowed When the 'Use Item Based Allocation' rule is enabled, the
item based allocation are only applicable for the items and
nodes which have the Item Based Allocation Allowed
attribute enabled. For more information about item-based
allocation, see the Sterling Selling and Fulfillment Foundation:
Product Concepts Guide.
Receiving Calendar Select the calendar to use to determine the available shifts for
receiving deliveries at the node. The calendars of the node as
well as the calendars of the primary enterprise of the node
display in this drop-down list.
Shipping Calendar Select the calendar to use to determine the available shifts for
shipping from the node. The calendars of the node as well as
the calendars of the primary enterprise of the node display in
this drop-down list.
Receipt Processing Time Enter how many hours it takes the node to process receipts
For Procurement (Hours) for procurement.
Receipt Processing Time for Enter the time it takes the node to process receipts for
Forwarding (Hours) forwarding in hours.

70 Sterling Selling and Fulfillment Foundation: Application Platform Configuration Guide


Table 21. Node Sourcing/Scheduling Tab (continued)
Field Description
Receipt Processing Time for Enter how many days are required to process incoming
Future Inventory (Days) future supplies before they are available for orders.
Node Can Ship To

Select the node types that this node can ship to. The availability of these checkboxes
depends on what node types have been defined, except the Any Address checkbox which
is always available.
Any Address Check this box to allow this node to ship to any address.
All Nodes Select this option if this node can ship to all nodes.
Specific Nodes Of Type If this node can only ship to nodes with a specific node type,
select this option, and check the applicable node types
available.

Defining a Node's Parcel Carrier Preferences:


About this task

You can identify the carriers that a node uses and define how they should interact.
You can add, modify, and delete carrier preferences.

To add parcel carrier preferences to a node:

Procedure
1. From the Roles & Participation tab in the Organization Details window, choose
Node Attributes.
2. Choose the Parcel Carrier Preferences tab.

3. Choose . The Parcel Carrier Preferences Detail pop-up window displays.


4. Enter information in the applicable fields. Refer to the following table for field
value descriptions.

Chapter 3. Configuring Participants 71


5. Choose .

Results

Modifying a Node's Parcel Carrier Preferences:


About this task

To modify a node's parcel carrier preferences:

Procedure
1. From the Roles & Participation tab in the Organization Details window, choose
Node Attributes.
2. Choose the Parcel Carrier Preferences tab.

3. Select the applicable carrier preference and choose . The Parcel Carrier
Preferences Detail pop-up window displays.
4. Enter information in the applicable fields. Refer to table in “Defining a Node's
Parcel Carrier Preferences” on page 71 for field value descriptions.

5. Choose .

Deleting a Node's Parcel Carrier Preferences:


About this task

To delete a node's parcel carrier preferences:

Procedure
1. From the Roles & Participation tab in the Organization Details window, choose
Node Attributes.
2. Choose the Parcel Carrier Preferences tab.
3. Select the applicable carrier preference and choose .

Parcel Carrier Preferences Detail Popup Window:

72 Sterling Selling and Fulfillment Foundation: Application Platform Configuration Guide


Table 22. Parcel Carrier Preferences Detail Popup Window
Fields Description
Carrier Choose the carrier to set the preferences. This is a mandatory
field.
Enterprise Code Choose the enterprise code.
Shipping Account Enter the shipping account information.
Bill Third Party for Check this box to bill shipping charges to a third-party
Outbound Shipment organization.
Bill Third Party for Return Check this box to bill return shipping charges to a third-party
Shipment organization.
Third Party Organization
Details
Organization Code Choose the organization code of the third party organization.
Billing Account Choose the billing account information of the third party
organization.
Online Control # Enter the online control number for the carrier preference.
International Shipping Check this box if international shipping integration is
Integration Required required.
Domestic Shipping Check this box if domestic shipping integration is required.
Integration Required
Allow system to Check this box if the system should be allowed to
automatically open a automatically open a manifest.
manifest

Chapter 3. Configuring Participants 73


Table 22. Parcel Carrier Preferences Detail Popup Window (continued)
Fields Description
Carrier Label Delivery
Mechanism
Print Choose this option to print the carrier label automatically.
Save as Image Choose this option to save the carrier label in PNG format.
Integration Carrier Adapter
Carrier Adapter Choose the Carrier Adapter that you want to integrate with
Implementation the selected carrier.

Defining a Node’s Relationships: A transfer order is a type of chained order that


is created when a node that belongs to the organization you are configuring needs
to replenish their stock from another node within the organization to fulfill an
order. A chained order is an order that is linked to a parent order in which the
lifecycle of one effects the other.

You can define a relationship between the node you are defining and another
node. Within this relationship you can define a transfer schedule, including the
transit time to procure items from a node, on a day-of-week basis. The schedule is
used for calculating expected dates.

You can define a transfer schedule that determines when items can be shipped
from one node to another, including the transit time to procure items from a node,
on a day-of-week basis. The schedule is used for calculating expected dates. For
more information on creating Transfer Schedules, refer to section “Defining a
Transfer Schedule” on page 76.

You can create, modify, and delete relationships.

Creating a Node Relationship:


About this task

To create a node relationship:

Procedure
1. From the Roles & Participation tab in the Organization Details window, choose
Node Attributes.
2. To create a node relationship from the node to another node, choose the
Relationship To Node tab. To create a node relationship to the node from
another node, choose the Relationship To Node tab.

3. Choose . The Relationship Details pop-up window displays.


4. Enter information into the applicable fields. Refer to Table 23 on page 75 for
field value descriptions.

5. Choose .

74 Sterling Selling and Fulfillment Foundation: Application Platform Configuration Guide


Table 23. Relationship Details Pop-Up Window
Field Description
Relationship Type Select a relationship type for this relationship from the
drop-down list.
From Node Select the node from which items are sent. If you select the
ShipNode from a lookup, a description must be configured
for the ShipNode in order to display a value in the From
Node field.

For the Relationship To Node tab, this option is defaulted to


the node you are configuring and disabled.
To Node Select the node at which transfer order items are received. If
you select the ShipNode from a lookup, a description must be
configured for the ShipNode in order to display a value in
the To Node field.

For the Relationship From Node tab, this option is defaulted


to the node you are configuring and disabled.
Transfer Schedules
Effective From Indicates the date on which the schedule takes effect.
Effective To Indicates the date on which the specified transfer schedule
stops being effective.
Days of the Week Indicates on which days during the transfer schedule items
are eligible for items to ship.

Modifying a Node Relationship:


About this task

To modify a node relationship:

Procedure
1. From the Roles & Participation tab in the Organization Details window, choose
Node Attributes.

Chapter 3. Configuring Participants 75


2. To modify a node relationship from the node to another node, choose the
Relationship To Node tab. To modify a node relationship to the node from
another node, choose the Relationship To Node tab.

3. From the table, locate the applicable relationship and choose . The
Relationship Details pop-up window displays.
4. Enter information into the applicable fields. Refer to Table 23 on page 75 for
field value descriptions.
5. Choose .

Deleting a Node Relationship:


About this task

To delete a node relationship:

Procedure
1. From the Roles & Participation tab in the Organization Details window, choose
Node Attributes.
2. To delete a node relationship from the node to another node, choose the
Relationship To Node tab. To modify a node relationship to the node from
another node, choose the Relationship To Node tab.

3. From the table, locate the applicable relationship choose .

Defining a Transfer Schedule: Transfer schedules provide a means to allow or


disallow a transfer during a specific period of time.

Creating a Transfer Schedule:


About this task

To create a transfer schedule:

Procedure

1. From the Relationship Details screen, choose from the Transfer Schedules
panel. The Transfer Schedule window displays.
2. Enter information into the applicable fields. For field value descriptions see
Table 24 on page 77.

3. Click .

76 Sterling Selling and Fulfillment Foundation: Application Platform Configuration Guide


Table 24. Transfer Schedule Window
Field Description
Effective From Date Select the date on which the transfer schedule becomes
effective.

If this value is left empty, it is assumed that the Transfer


Schedule has been effective for an infinite number of days.
Effective To Date Select the date on which the transfer schedule ends.

If this value is left empty, it is assumed that the Transfer


Schedule remains effective indefinitely.
Default Transit Days Enter the minimum number of days shipments are expected
to take to reach the end location.
Shipped On
Day Of Week Check the box for each day of the week on which transfers
are permitted.
Override Transit Days Enter the number of transit days for a specific day of the
week. For example, shipping on a Saturday may add one day
to the number of transfer days. As a result, the new Transfer
Days value would be 1 + the amount of the standard value.
Ship Date Overrides
Ship Date Select the date for which you would like to override
shipping. For example, Tuesday, December 25, 2007, a
holiday.
Can Ship Select Yes to allow or No to disallow shipping on the
specified day.

Chapter 3. Configuring Participants 77


Table 24. Transfer Schedule Window (continued)
Field Description
Override Transit Days Enter the override transit days for the override dates.

Note: If a transfer schedule exists for one day, it is assumed that a transfer
schedule exists for all days.

Modifying a Transfer Schedule:


About this task

To modify a transfer schedule:

Procedure
1. From the Relationship Details screen, Transfer Schedules panel, select the
Transfer Schedule you would like to modify.

2. Choose .
3. Enter information into the applicable fields. For field value descriptions, see
Table 24 on page 77.
4. Click .

Deleting a Transfer Schedule:


About this task

To delete a transfer schedule:

Procedure
1. From the Relationship Details screen, Transfer Schedules panel, select the
Transfer Schedule you would like to delete.

2. Choose .

Defining a Node's LTL Carrier Preferences:


About this task

You can define the PRO Number Generation settings for the carriers a node uses
and define how they should be used.

PRO Number refers to the unique progressive or serial number assigned by the
carrier to identify and track a specific shipment. This is used on freight bills, bills
of lading, and waybills for invoicing and tracking purposes.

A warehouse may define the range of PRO Numbers assigned by a carrier. The
PRO Number has a fixed length defined for each carrier, and may contain a prefix.

PRO Number is typically generated during routing for a load with carrier type
'LTL'. The PRO Number is regenerated automatically when the carrier/service on
the load is changed.

You can add, modify, and delete LTL carrier preferences.

To add LTL carrier preferences to a node:

78 Sterling Selling and Fulfillment Foundation: Application Platform Configuration Guide


Procedure
1. From the Roles & Participation tab in the Organization Details window, choose
Node Attributes.
2. Choose the LTL Carrier Preferences tab.

3. Choose . The PRO Number Generation Scheme pop-up window displays.


4. Enter information in the applicable fields. Refer to Table 25 on page 80 for field
value descriptions.
5. Choose .

Chapter 3. Configuring Participants 79


Table 25. PRO Number Generation Scheme Pop-Up Window
Field Description
PRO Number Generation One of the following actions is initiated based on the
Scheme Generation Scheme selected:
v Sterling Warehouse Management System generates the
PRO Numbers
v Sterling Warehouse Management System uses the PRO
Numbers generated by an external system, or
v Sterling Warehouse Management System does not
generate PRO Numbers.
Carrier Choose the carrier whose PRO Number Generation Scheme is
being defined.
System Generated Select ‘System Generated' if Sterling Warehouse Management
System should generate PRO Numbers.
Externally Generated Select ‘Externally Generated' if Sterling Warehouse
Management System should use PRO Numbers generated by
an external system.
Do Not Generate Select ‘Do Not Generate' if PRO Numbers should not be
generated.
Set up data for System This is applicable only when Sterling Warehouse
Generated scheme Management System generates the PRO Numbers.
PRO Number Sets When the first range of PRO Numbers is used up, Sterling
Warehouse Management System utilizes the second range
of PRO Numbers, and vice versa.
PRO Number Set - 1 Defines the first range of PRO Numbers to be used by
Sterling Warehouse Management System.
PRO Number Prefix Enter the PRO Number Prefix to be used in generating the
first range of PRO Numbers.

PRO Number Prefix can be alpha numeric, and is not


included for computing the check digit.
PRO Number Start Enter the PRO Number Start to be used in generating the first
range of PRO Numbers.

PRO Number Start is the starting number for the first set of
PRO Numbers.
PRO Number End Enter the PRO Number End to be used in generating the first
range of PRO number.

PRO Number End is the ending number for the first set of
PRO Numbers.
PRO Number Set - 2 Defines the second range of PRO Numbers to be used by
Sterling Warehouse Management System.
PRO Number Prefix Enter the PRO Number Prefix to be used in generating the
second range of PRO Numbers.

PRO Number Prefix can be alpha numeric, and is not


included for computing the check digit.
PRO Number Start Enter the PRO Number Start to be used in generating the
second range of PRO Numbers.

PRO Number Start is the starting number for the second set
of PRO Numbers.

80 Sterling Selling and Fulfillment Foundation: Application Platform Configuration Guide


Table 25. PRO Number Generation Scheme Pop-Up Window (continued)
Field Description
PRO Number End Enter the PRO Number End to be used in generating the
second range of PRO Numbers.

PRO Number End is the ending number for the second set of
PRO Numbers.
Notification Threshold Enter the notification threshold at which an alert is raised to
the user. This gains importance in instances where the second
set of PRO Numbers is not defined.

The notification threshold defines the number of unassigned


PRO Numbers available till the PRO Number End. This
enables the warehouse to talk to the carrier and get a new
range of PRO Numbers.
Note: If the PRO Number End is X, and the notification
threshold is set to 50, Sterling Warehouse Management
System raises an alert to the user, when the current PRO
Number (unassigned) reaches X-50.
Notification Service Choose Notification Service to be used.

Notification Service is the service that is invoked when


Notification Threshold is reached.
Check Digit Determination Defines the check digit algorithm to be used for PRO
Generation.
Select Algorithm Choose the relevant algorithm for check digit determination.

Typical values are mod-11 and mod-10.


Note: When ‘mod-11' or ‘mod-10' schema of check digit
determination is chosen, the check digit is generated
out-of-the-box by Sterling Warehouse Management System.

For more details about Check Digit Determination Algorithm,


see Setting Up a Check Digit Determination Algorithm.

Setting Up a Check Digit Determination Algorithm:


About this task

To set up a check digit determination algorithm:

Procedure

1. In the PRO Number Generation Scheme pop-up window, choose .


2. The Check Digit Algorithms Search window displays.

Chapter 3. Configuring Participants 81


3. In the Check Digit Algorithms panel, choose . The Check Digit Logic Details
pop-up window displays.
4. Enter information in the applicable fields. Refer Table 26 for field value
descriptions.

5. Choose .

Table 26. Check Digit Logic Details Popup Window


Field Description
Check Digit Logic Enter the check digit logic for the algorithm being created.
Short Description Enter a short description for the algorithm being created.

82 Sterling Selling and Fulfillment Foundation: Application Platform Configuration Guide


Table 26. Check Digit Logic Details Popup Window (continued)
Field Description
Long Description Enter a long description for the algorithm being created.

Creating a New Check Digit Determination Algorithm from an Existing Check Digit
Determination Algorithm:
About this task

To create a new check digit determination algorithm from an existing check digit
determination algorithm:

Procedure

1. In the PRO Number Generation Scheme pop-up window, choose .


2. The Check Digit Algorithms Search window displays.

3. In the Search panel, enter applicable search criteria, and choose .


4. The relevant search results display in the Check Digit Algorithms panel.
5. From the Check Digit Algorithms list, choose the Check Digit Algorithm to be
copied from.

6. Choose . The Check Digit Logic Details pop-up window displays.


7. Enter information in the applicable fields. Refer Table 26 on page 82 for field
value descriptions.
8. Choose .

Modifying a Check Digit Determination Algorithm:


About this task

Once a check digit determination algorithm has been created, it can be modified.

To modify a check digit determination algorithm:

Procedure

1. In the PRO Number Generation Scheme pop-up window, choose .


2. The Check Digit Algorithms Search window displays.
3. In the Search panel, enter applicable search criteria, and choose .
4. The relevant search results display in the Check Digit Algorithms panel.
5. From the Check Digit Algorithms list, choose the Check Digit Algorithm to be
modified.

6. Choose . The Check Digit Logic Details pop-up window displays.


7. Enter information in the applicable fields. Refer Table 26 on page 82 for field
value descriptions.

8. Choose .

Deleting a Check Digit Determination Algorithm:


About this task

To delete a check digit determination algorithm:

Chapter 3. Configuring Participants 83


Procedure

1. In the PRO Number Generation Scheme pop-up window, choose .


2. The Check Digit Algorithms Search window displays.

3. In the Search panel, enter applicable search criteria, and choose .


4. The relevant search results display in the Check Digit Algorithms panel.
5. From the Check Digit Algorithms list, choose the Check Digit Algorithm to be
deleted.

6. Choose .

Modifying a Node's LTL Carrier Preferences:


About this task

To modify a node's LTL carrier preferences:

Procedure
1. From the Roles & Participation tab in the Organization Details window, choose
Node Attributes.
2. Choose the LTL Carrier Preferences tab.
3. Select the applicable LTL Carrier Preference and choose . The PRO Number
Generation Scheme pop-up window displays.
4. Enter information in the applicable fields. Refer to Table 25 on page 80 for field
value descriptions.

5. Choose .

Deleting a Node's LTL Carrier Preferences:


About this task

To delete a node's LTL carrier preferences:

Procedure
1. From the Roles & Participation tab in the Organization Details window, choose
Node Attributes.
2. Choose the LTL Carrier Preferences tab.

3. Select the applicable LTL Carrier Preference and choose .

Defining a Node's Carrier Pickup Schedule:


About this task

You can define a carrier's pickup schedule at a node. You can add, modify, and
delete pickup schedules. See the Sterling Selling and Fulfillment Foundation: Product
Concepts Guide guide for more information.

To add a carrier pickup schedule to a node:

Procedure
1. From the Roles & Participation tab in the Organization Details window, choose
Node Attributes.
2. Choose the Carrier Pickup Schedules tab.

84 Sterling Selling and Fulfillment Foundation: Application Platform Configuration Guide


3. Choose . The Carrier Pickup Schedule Details pop-up window displays.
4. Enter information in the applicable fields. Refer to the following table for field
value descriptions.
5. Choose .

Chapter 3. Configuring Participants 85


Results
Table 27. Carrier Pickup Schedule Details Popup Window
Field Description
Carrier Service Select the carrier service for which you are
configuring a pickup schedule.
Effective From Date Select the date on which the pickup
schedule becomes effective. If you do not
specify a start date, the system assumes that
the pickup schedule has already started.
Effective To Date Select the date on which the pickup
schedule ends. If you do not specify an end
date, the pickup schedule is in effect forever.
Ensure that you specify a date range that is
not already in use by another carrier pickup
schedule. For example, if a carrier pickup
schedule has a date range of January
through June, you cannot specify a date
range of May through July for a different
schedule.
Pick Up On
Day of Week Check the box for each day of the week on
which pickups are permitted.
Pickup Time Enter the time of day when this carrier
service picks up shipments from this node.
If you do not specify a time, the carrier does
not pick up on the selected day.
Pickup Date Overrides
Override Date Select the date for which you want to
override the scheduled pickup options.
Can Pick Up Select Yes to allow pick up or No to
disallow pick up on the specified date.
Pickup Time Enter the pickup time for the override date
that you are allowing pickup.

Modifying a Carrier Pickup Schedule:


About this task

To modify a carrier pickup schedule:

Procedure
1. From the Roles & Participation tab in the Organization Details window, choose
Node Attributes.
2. Choose the Carrier Pickup Schedules tab.

3. Select a pickup schedule from the Carrier Pickup Schedule List and choose .
The Carrier Pickup Schedule Details popup window displays.
4. Enter information in the applicable field. Refer to Table 27 for field value
descriptions.

5. Choose .

Deleting a Carrier Pickup Schedule:

86 Sterling Selling and Fulfillment Foundation: Application Platform Configuration Guide


About this task

To delete a carrier pickup schedule:

Procedure
1. From the Roles & Participation tab in the Organization Details window, choose
Node Attributes.
2. Choose the Carrier Pickup Schedules tab.

3. Select a pickup schedule from the Carrier Pickup Schedule List and choose .

Defining a Node's Advanced Inventory Attributes


About this task

You can determine if a node's inventory is maintained within Sterling Selling and
Fulfillment FoundationSterling Application Platform. You can also determine if the
node you are configuring is itself an inventory node or identifies the inventory
node to which it belongs.

To define a node's advanced inventory attributes:

Procedure
1. From the Roles & Participation tab in the Organization Details window, choose
Advanced Attributes.
2. Enter information in the applicable fields. Refer to Table 28 on page 88 for field
value descriptions.

3. Choose .

Chapter 3. Configuring Participants 87


Table 28. Advanced Attributes, Inventory Tab
Field Description
Inventory Information Not Select this option if the node uses an inventory application
Available To Sterling other than Sterling Selling and Fulfillment FoundationSterling
Selling and Fulfillment Application Platform to track inventory.
FoundationSterling
Application Platform If this option is selected, Sterling Selling and Fulfillment
FoundationSterling Application Platform never has access to
the inventory picture for this node, and never attempts to do
any inventory availability checks.
Note: When this option is selected, Sterling Selling and
Fulfillment FoundationSterling Application Platform still
stores the inventory organization for the node with the
organization selected as the inventory organization when the
node was created (see the Inventory Consolidation Level rule
in “System Administration Components: Defining Installation
Rules” on page 226).
Inventory Is Made Select this if the node tracks inventory using either Sterling
Available To Sterling Selling and Fulfillment FoundationSterling Application
Selling and Fulfillment Platform or another inventory application. The node's
Foundation inventory picture can be used in Sterling Selling and
Fulfillment FoundationSterling Application Platform for
availability calculation, inventory tracking, and distribution.

If you are configuring a node, this field determines if


inventory is tracked or infinite at the node.
Get External Supply Real Select this field if the supply is available to Sterling Selling
Time and Fulfillment FoundationSterling Application Platform, but
comes from an external system instead of being maintained
internally. The supply picture is obtained by calling the
getExternalSupply user exit.
Note: This checkbox is only available when the inventory
information is available to Sterling Selling and Fulfillment
FoundationSterling Application Platform, and the
organization is a node only.
Capture Tag Information
Only when receiving Select this option to capture an item's tag information only
when receiving inventory.
When performing any node Select this option if you want to capture an item's tag
operation information when performing any node operation, such as
receiving, picking, putaway, or counting.
Only when shipping, if the Select this option if you want to capture an item's tag
buyer mandates information only when shipping inventory to a buyer who
mandates it.
Serial Information
Serial Tracked Item
Capable of Serial Tracking Select this to track serials for serial tracked items in inventory.
in Inventory
If this is not selected, serial tracking will be based on
configuration for serialized items.
Serialized Item

88 Sterling Selling and Fulfillment Foundation: Application Platform Configuration Guide


Table 28. Advanced Attributes, Inventory Tab (continued)
Field Description
Capture Serial in Inbound Select this to capture serial information in inbound. There are
two scenarios of capturing serials:

Only Return Inbound - Select this to capture only for return


inbound items.

All Inbound - Select this to capture serials for all inbound


inventory.
Capture Serial in Outbound Select this to capture the serial information when shipping.
Exclude Serial Capture For Select this to exclude serial capturing for transfer orders.
Transfer
Physical Count
Allow Other Inventory Check this box to allow other inventory operations to be
Operations While Physical performed during the physical count process.
Count Is On
Inventory Adjustment Reasons

You can associate inventory adjustment reasons for a ship node that performs receiving,
packing, and shipping activities.

Based on the configurations done for a ship node in the Sterling Warehouse Management
System, the inventory adjustment reasons drop-down list displays. For more information
about defining inventory adjustment reasons, see the Sterling Selling and Fulfillment
Foundation: Warehouse Management System Configuration Guide.
Receiving Select the adjustment reason code associated with the
receiving activity from the drop-down list. By default, the
value of the receiving activity is RECEIPT.
Note: Ensure that the reason code is not associated with an
accounting bin.
Packing Select the adjustment reason code associated with the packing
activity from the drop-down list. By default, the value of the
packing activity is PACK.
Note: Ensure that the reason code is associated with an
accounting bin.
Shipping Select the adjustment reason code associated with the
shipping activity from the drop-down list. By default, the
value of the shipping activity is SHIP.
Note: Ensure that the reason code is not associated with an
accounting bin.
OverPick For Voice Based Select the adjustment reason code associated with the
Tasks voice-based overpicking activity from the drop-down list.
Note: This reason code is applicable only when voice-based
picking is implemented in a warehouse.

Defining an Organization's Advanced Inventory Attributes


About this task

You can determine if an organization's inventory is maintained within Sterling


Selling and Fulfillment FoundationSterling Application Platform. You can also
determine if the organization you are configuring is an inventory organization or
the inventory organization it belongs to.

Chapter 3. Configuring Participants 89


Note: This is an installation level configuration only. Do not attempt to reconfigure
the parameters on this tab mid-implementation.

Note: When creating an organization through the save as operation, the new
organization's inventory organization is the inventory organization of the source
organization. If the source organization is its own inventory organization, the
source organization is set as the inventory organization of the new organization.

To define an organization's advanced inventory attributes:

Procedure
1. From the Roles & Participation tab in the Organization Details window, choose
Advanced Attributes.
2. Choose the Inventory tab.

3. Choose .

Table 29. Inventory Tab


Field Description
Inventory Information Is Select this option if the organization uses an inventory
Not AvailableSterling application other than Sterling Selling and Fulfillment
Application Platform FoundationSterling Application Platform to track supply and
demand.

If this option is selected, Sterling Selling and Fulfillment


FoundationSterling Application Platform does not have access
to the inventory picture for this organization, and do not
attempt to do any inventory availability checks. Orders can
still be placed using this organization as a seller, but the
orders are scheduled without any inventory availability
checks.

90 Sterling Selling and Fulfillment Foundation: Application Platform Configuration Guide


Table 29. Inventory Tab (continued)
Field Description
Inventory Information Is Select this if the organization tracks inventory supply and
AvailableSterling demand using either Sterling Selling and Fulfillment
Application Platform FoundationSterling Application Platform or another inventory
application. The organization's supply and demand picture
can be used in Sterling Selling and Fulfillment
FoundationSterling Application Platform for availability
calculation, inventory tracking, and distribution.

If you are configuring a node, this field determines if


inventory is tracked or infinite at the node.
This Organization Is An Select this if you selected Inventory Is Maintained Within
Inventory Organization Sterling Selling and Fulfillment FoundationSterling
Application Platform and you want to specify this
organization as an inventory consolidator.

An inventory organization:
v Provides inventory identification for a product. For
example, different organizations can have different product
identification IDs for the same inventory item. The
inventory organization provides a mechanism to rationalize
these product IDs into a single nomenclature across
multiple organizations.
v Establishes ownership of inventory when a single physical
location is shared across multiple organizations without
having to create multiple logical locations to establish the
inventory ownership.
v Provides inventory separation, allowing all organizations
that are part of the inventory organization to have visibility
to the inventory of all of the other organizations that are
part of the inventory organization.
Inventory Organization Is Select this and the applicable inventory organization if you
selected Inventory Is Made Available To Sterling Selling and
Fulfillment Foundation and you want to associate this
organization as part of the applicable inventory organization.

Important: The organization should have the same catalog


organization as the inventory organization you are associating
with.
Get External Inventory Real Select this field if the inventory is available to Sterling Selling
Time and Fulfillment FoundationSterling Application Platform, but
comes from an external system instead of being maintained
internally. The inventory picture is then obtained by calling
the getExternalInventory user exit.
Get External Supply Real Select this field if the supply is available to Sterling Selling
Time and Fulfillment FoundationSterling Application Platform, but
comes from an external system instead of being maintained
internally. The supply picture is then obtained by calling the
getExternalSupply user exit.
Note: This checkbox is only available when the organization
has been defined only as a node.
Physical Count
Allow Other Inventory Check this box to allow other inventory operations to be
Operations While Physical performed during the physical count process.
Count Is On
This checkbox is enabled only if the organization is a node.

Chapter 3. Configuring Participants 91


Table 29. Inventory Tab (continued)
Field Description
Inventory Organization Relationship
Inventory Organization
Choose to select an inventory organization from the
Relationship
drop-down list. It displays Consumable Inventory
Organization and Organization Name.
Note: This panel is visible only if This Organization Is An
Inventory Organization is selected.

Defining an Organization's Advanced Catalog Attributes


About this task

You can determine if an organization maintains its own catalog or if it is


maintained by another organization.

Note: This is an installation level configuration only. Do not attempt to reconfigure


the parameters on this tab mid-implementation.

Note: When creating an organization through the save as operation, the new
organization's catalog organization is the catalog organization of the source
organization. If the source organization is its own catalog organization, the source
organization is set as the catalog organization of the new organization.

To define an organization's advanced catalog attributes:

Procedure
1. From the Roles & Participation tab in the Organization Details window, choose
Advanced Attributes.
2. Choose the Catalog tab.
3. Enter information in the applicable fields. Refer to Table 30 on page 93 for field
value descriptions.

4. Choose .

92 Sterling Selling and Fulfillment Foundation: Application Platform Configuration Guide


Table 30. Catalog Tab
Field Description
Organization Defines Its Select this field in the organization defines it's own item
Own Catalog master catalog. The item master that this organization defines
can be shared with other organizations.
Catalog Defined By Select this field and select the applicable catalog organization
if you want to use the organization's item master catalog
without having to create a separate catalog of your own.

Defining an Organization's Advanced Capacity Attributes


About this task

You can determine if an organization maintains its own capacity or if it is


maintained by another organization.

Note: This is an installation level configuration only. Do not attempt to reconfigure


the parameters on this tab mid-implementation.

Note: When creating an organization through the save as operation, the new
organization's capacity organization is the capacity organization of the source
organization. If the source organization is its own capacity organization, the source
organization is set as the capacity organization of the new organization.

To define an organization's advanced capacity attributes:

Procedure
1. From the Roles & Participation tab in the Organization Details window, choose
Advanced Attributes.
2. Choose the Catalog tab.
3. Enter information in the applicable fields. Refer to Table 31 on page 94 for field
value descriptions.

4. Choose .

Chapter 3. Configuring Participants 93


Table 31. Capacity Tab
Field Description
This Organization Is A Select This Organization Is A Capacity Organization if you
Capacity Organization want to specify this organization as an service capacity
consolidator.

A capacity organization:
v Provides service capacity identification for a product.
v Establishes ownership of capacity when a single physical
location is shared across multiple organizations without
having to create multiple logical locations to establish the
capacity ownership.
v Provides capacity separation, allowing all organizations
that are part of the capacity organization to have visibility
to the capacities of all of the other organizations that are
part of the same capacity organization.
Capacity Organization Is Select Capacity Organization Is and select the applicable
capacity organization if you want to associate this
organization as part of the applicable capacity organization.

Important: The organization should have the same catalog


organization as the capacity organization you are associating
with.
Get Capacity Real Time Select this field if the organization makes capacity
information available to Sterling Selling and Fulfillment
FoundationSterling Application Platform from an external
system. When Sterling Selling and Fulfillment
FoundationSterling Application Platform checks for capacity,
the external system provides the capacity in response to a
user exit call from Sterling Selling and Fulfillment
FoundationSterling Application Platform.

Defining an Organization's Advanced Customer Attributes


About this task

You can determine if an organization defines its own customers, or if its customers
are defined by another organization.

To define an organization's advanced customer attributes:

Procedure
1. From the Roles & Participation tab in the Organization Details window, choose
Advanced Attributes.
2. Choose the Customer tab.
3. Enter information in the applicable fields. Refer to Table 31 for field value
descriptions.

4. Choose .

94 Sterling Selling and Fulfillment Foundation: Application Platform Configuration Guide


Defining an Organization's Advanced Pricing Attributes
About this task

You can determine if an organization maintains its own pricing or if it is


maintained by another organization.

Note: This is an installation level configuration only. Do not attempt to reconfigure


the parameters on this tab mid-implementation.

To define an organization's advanced pricing attributes:

Procedure
1. From the Roles & Participation tab in the Organization Details window, choose
Advanced Attributes.
2. Choose the Pricing tab.
3. Enter information in the applicable fields. Refer to Table 30 on page 93 for field
value descriptions.
4. Choose .

Table 32. Pricing Tab


Field Description
Organization Defines Its Select this field if the organization defines its own price lists,
Own Pricing pricing rules, and coupons. The pricing data that this
organization defines can be shared with other organizations.
Pricing Defined By Select this field and select the applicable organization if you
want to use that organization's price lists, pricing rules, and
coupons.

Chapter 3. Configuring Participants 95


Defining an Organization's Themes
About this task

You can create and maintain a list of themes to be part of your storefront's URL
and provide a brand-name, "look-and-feel" entry point for customers on the web.
This tab is enabled when an organization has the roles of enterprise and seller. You
can list specific themes such as seasonal or promotional displays as well as default
themes that are more generic in nature.

To define an Organization's Themes:

Procedure
1. From the Roles & Participation tab in the Organization Details window,
choose Organization Themes.
2. Enter information in the applicable fields. Refer to Table 33 for field value
descriptions.

3. Choose .
Table 33. Organization Theme
Field Description
Theme Enter the name of a theme that your organization supports.
This name will become part of the URL.

96 Sterling Selling and Fulfillment Foundation: Application Platform Configuration Guide


Table 33. Organization Theme (continued)
Field Description
Default Theme Enter the ID of your organization's Default Theme. This name
will become part of the URL.

Assigning a Yard's Roles and Participant Associations


About this task

If an organization is a yard, the role is selected as a Node. You cannot assign any
other roles to that yard.

To assign a yard's roles and participant associations:

Procedure
1. In the Organization Details window, choose the Roles & Participation tab.

The Roles box is disabled as the organization is a yard and not a fulfillment
node.

2. In the Enterprises box, choose . The Participating Enterprises pop-up


window is displayed. Select the enterprise that this organization participates
with from the drop-down list.

Choose to delete the enterprise that do not participate with the


organization.
3. In Primary Enterprise, select the primary Enterprise for the organization from
the drop-down list, if applicable.

4. Click .

Defining Communication Protocols


Communication protocols are the means by which an organization communicates
in the Hub environment. For example, if the organization you are setting up uses
both an FTP site and e-mail services to send and receive documents, you would
identify them along with their protocols here. You can create, modify, and delete
communication protocols.

Creating a Communication Protocol


About this task

To create a communication protocol:

Chapter 3. Configuring Participants 97


Procedure
1. In the Organization Details window, choose the Communication tab. The
Communication Protocols and Documents lists display.

2. From the Communication Protocols list, select . The Communication


Protocol Details pop-up window displays.
3. Enter information in the applicable fields. Refer to Table 34 for field value
descriptions.
4. Choose .

Table 34. Communication Protocol Details Pop-Up Window


Field Description
Protocol Select the type of protocol you want to set up. For more
information about protocols, see “Defining Protocol Codes”
on page 291.

You must choose before entering any references.


References
Name Enter a reference name for the protocol. For example, IP
address.
Value Enter the value for the reference name.

Modifying a Communication Protocol


About this task

To modify a communication protocol:

Procedure
1. In the Organization Details window, choose the Communication tab. The
Communication Protocols and Documents list displays.
2. From the Communication Protocols list, select the applicable communication
protocol and choose . The Communication Protocol Details pop-up window
displays.
3. Modify information in the applicable fields. Refer to Table 34 for field value
descriptions.

98 Sterling Selling and Fulfillment Foundation: Application Platform Configuration Guide


4. Choose .

Deleting a Communication Protocol


About this task

To delete a communication protocol:

Procedure
1. In the Organization Details window, choose the Communication tab. The
Communication Protocols and Documents lists display.
2. From the Communication Protocols list, select the applicable communication
protocol and choose .

Defining Buyer Documents


If you choose Buyer as the role for the organization, you may have to define the
types of Buyer documents. Buyer documents are documents used by the Buyer
organization when communicating with a Seller organization.

The following are some examples of Buyer documents:


v Planned Purchase Order
v Purchase Order Download
v Invoice

You can create, modify, and delete Buyer documents.

Creating a Buyer Document:


About this task

To create a Buyer document:

Procedure
1. In the Organization Details window, choose the Communication tab. The
Communication Protocols and Documents lists display.
2. From the Documents list, choose the Buyer Documents tab. The Buyer
Documents list displays.

3. Choose . The Buyer Document Detail pop-up window displays.


4. Enter information in the applicable fields. Refer to Table 35 on page 100 for
field value descriptions.

5. Choose .

Chapter 3. Configuring Participants 99


Table 35. Buyer Document Detail Pop-Up Window
Field Description
Document The business document to be used in your organization. For
more information about business documents, see “Defining
Business Document Codes” on page 293.
Format Select the format in which you want the document to appear.
For example, XML or EDI. For more information about
document formats, see “Defining Document Format Codes”
on page 292.
Protocol Select the protocol you want to use when sending or
receiving the document. For example, FTP.
Backup Protocol Select a backup protocol to use in case there is a problem
with the primary protocol. For example, set to e-mail service
in case of occasional problems with the FTP site. For more
information about protocols, see “Defining Communication
Protocols” on page 97.
Integration Service Enter the service that the Buyer prefers to use to receive this
document.

For example, you are setting up an Invoice document. The


Buyer prefers to receive this document from organizations
using an EDI format. A particular organization that
participates with the Buyer, also uses two additional Carriers
that prefer to receive the document in formats other than EDI.
The Enterprise has a router configured to look for the
preferred service at the point in their pipeline where the
Invoice document is sent to the Buyer. They also have several
services configured to enable the transfer of documents in
different formats, including EDI.

You can use this field to specify the service to transfer the
necessary information into EDI format at the necessary point
in the pipeline.
Reference 1 Enter any user-defined information. This field is disabled
until you enter information and choose .

100 Sterling Selling and Fulfillment Foundation: Application Platform Configuration Guide
Table 35. Buyer Document Detail Pop-Up Window (continued)
Field Description
Reference 2 Enter any user-defined information. This field is disabled
until you enter information and choose .
Reference 3 Enter any user-defined information. This field is disabled
until you enter information and choose .
Reference 4 Enter any user-defined information. This field is disabled
until you enter information and choose .
Reference 5 Enter any user-defined information. This field is disabled
until you enter information and choose .

Modifying a Buyer Document:


About this task

To modify a Buyer document:

Procedure
1. In the Organization Details window, choose the Communication tab. The
Communication Protocols and Documents lists display.
2. From the Documents list, choose the Buyer Documents tab. The Buyer
Documents list displays.

3. Select the applicable Buyer document and choose . The Buyer Document
Detail pop-up window displays.
4. Modify information in the applicable fields. Refer to Table 35 on page 100 for
field value descriptions.

5. Choose .

Deleting a Buyer Document:


About this task

To delete a Buyer document:

Procedure
1. In the Organization Details window, choose the Communication tab. The
Communication Protocols and Documents lists display.
2. From the Documents list, choose the Buyer Documents tab. The Buyer
Documents list displays.

3. Select the applicable Buyer document and choose .

Setting Up Seller Documents


If you choose Seller as the role for the organization, you may have to define the
types of Seller documents. Seller documents are documents used by the Seller
organization when communicating with a Buyer organization.

The following are some examples of Seller documents:


v Order Confirmation
v Shipment Confirmation
v Planned Order Modification

Chapter 3. Configuring Participants 101


You can create, modify, and delete Seller documents.

Creating a Seller Document:


About this task

To create a Seller document:

Procedure
1. In the Organization Details window, choose the Communication tab. The
Communication Protocols and Documents lists display.
2. From the Documents list, choose the Seller Documents tab. The Seller
Documents list displays.

3. Choose . The Seller Document Detail pop-up window displays.


4. Enter information in the applicable fields. Refer to Table 36 for field value
descriptions.

5. Choose .

Table 36. Seller Document Detail Pop-Up Window


Field Description
Document The business document to be used in your organization. For
more information about business documents, see “Defining
Business Document Codes” on page 293.
Format Select the format in which you want the document to appear.
For example, XML or EDI. For more information about
document formats, see “Defining Document Format Codes”
on page 292.
Protocol Select the protocol you want to use when sending or
receiving the document. For example, FTP.
Backup Protocol Select a backup protocol to use in case there is a problem
with the primary protocol. For example, set to e-mail service
in case of occasional problems with the FTP site. For more
information about protocols, see “Defining Communication
Protocols” on page 97.

102 Sterling Selling and Fulfillment Foundation: Application Platform Configuration Guide
Table 36. Seller Document Detail Pop-Up Window (continued)
Field Description
Integration Service Enter the service that the Seller prefers to use to receive this
document.

For example, you are setting up a Purchase Order document.


The Seller prefers to receive this document from organizations
using an EDI format. A particular organization that
participates with the Seller, also uses two additional Sellers
that prefer to receive the document in formats other than EDI.
This organization has a router configured to look for the
preferred service at the point in their pipeline where the
Purchase Order document is sent to the Seller. They also have
several services configured to enable the transfer of
documents in different formats, including EDI.

You can use this field to specify the service to transfer the
necessary information into EDI format at the necessary point
in the pipeline.
Reference 1 Enter any user-defined information. This field is disabled
until you enter information and choose .
Reference 2 Enter any user-defined information. This field is disabled
until you enter information and choose .
Reference 3 Enter any user-defined information. This field is disabled
until you enter information and choose .
Reference 4 Enter any user-defined information. This field is disabled
until you enter information and choose .
Reference 5 Enter any user-defined information. This field is disabled
until you enter information and choose .

Modifying a Seller Document:


About this task

To modify a Seller document:

Procedure
1. In the Organization Details window, choose the Communication tab. The
Communication Protocols and Documents lists display.
2. From the Documents list, choose the Seller Documents tab. The Seller
Documents list displays.

3. Select the applicable Seller document and choose . The Seller Document
Detail pop-up window displays.
4. Modify information in the applicable fields. Refer to Table 36 on page 102 for
field value descriptions.

5. Choose .

Deleting a Seller Document:


About this task

To delete a Seller document:

Chapter 3. Configuring Participants 103


Procedure
1. In the Organization Details window, choose the Communication tab. The
Communication Protocols and Documents lists display.
2. From the Documents list, choose the Seller Documents tab. The Seller
Documents list displays.
3. Select the applicable Seller document and choose .

Setting Up Carrier Documents


If you chose Carrier as the role for the organization, you may have to define the
types of Carrier documents. Carrier documents are documents used in
communicating carrier shipment information with Buyer and Seller organizations.

The following are some examples of Carrier documents:


v Package Details
v Load Tender Request
v Load Tender Confirmation

You can create, modify, and delete Carrier documents.

Creating a Carrier Document:


About this task

To create a Carrier document:

Procedure
1. In the Organization Details window, choose the Communication tab. The
Communication Protocols and Documents lists display.
2. From the Documents list, choose the Carrier Documents tab. The Carrier
Documents list displays.
3. Choose . The Carrier Document Detail pop-up window displays.
4. Enter information in the applicable fields. Refer to Table 37 on page 105 for
field value descriptions.
5. Choose .

104 Sterling Selling and Fulfillment Foundation: Application Platform Configuration Guide
Table 37. Carrier Document Detail Pop-Up Window
Field Description
Document The business document to be used in your organization. For
more information about business documents, see “Defining
Business Document Codes” on page 293.
Format Select the format in which you want the document to appear.
For example, XML or EDI. For more information about
document formats, see “Defining Document Format Codes”
on page 292.
Protocol Select the protocol you want to use when sending or
receiving the document. For example, FTP.
Backup Protocol Select a backup protocol to use in case there is a problem
with the primary protocol. For example, set to e-mail service
in case of occasional problems with the FTP site. For more
information about protocols, see “Defining Communication
Protocols” on page 97.
Integration Service Enter the service that the Carrier prefers to use to receive this
document.

For example, you are setting up a Package Type document.


The Carrier prefers to receive this document from
organizations using an EDI format. A particular organization
that participates with the Carrier, also uses two additional
Carriers that prefer to receive the document in formats other
than EDI. The Enterprise has a router configured to look for
the preferred service at the point in their pipeline where the
Package Type document is sent to the Carrier. They also have
several services configured to enable the transfer of
documents in different formats, including EDI.

You can use this field to specify the service to transfer the
necessary information into EDI format at the necessary point
in the pipeline.
Reference 1 Enter any user-defined information. This field is disabled
until you enter information and choose .

Chapter 3. Configuring Participants 105


Table 37. Carrier Document Detail Pop-Up Window (continued)
Field Description
Reference 2 Enter any user-defined information. This field is disabled
until you enter information and choose .
Reference 3 Enter any user-defined information. This field is disabled
until you enter information and choose .
Reference 4 Enter any user-defined information. This field is disabled
until you enter information and choose .
Reference 5 Enter any user-defined information. This field is disabled
until you enter information and choose .

Modifying a Carrier Document:


About this task

To modify a Carrier document:

Procedure
1. In the Organization Details window, choose the Communication tab. The
Communication Protocols and Documents lists display.
2. From the Documents list, choose the Carrier Documents tab. The Carrier
Documents list displays.

3. Select the applicable Carrier document and choose . The Carrier Document
Detail pop-up window displays.
4. Modify information in the applicable fields. Refer to Table 37 on page 105 for
field value descriptions.

5. Choose .

Deleting a Carrier Document:


About this task

To delete a Carrier document:

Procedure
1. In the Organization Details window, choose the Communication tab. The
Communication Protocols and Documents lists display.
2. From the Documents list, choose the Carrier Documents tab. The Carrier
Documents list displays.

3. Select the applicable Carrier document and choose .

Defining an Organization's Payment Information


About this task

An organization that makes any type of monetary transactions with other


organizations must have payment information set up. This information provides all
parties with an account number, billing address, and tax information.

To set up an organization's payment information:

106 Sterling Selling and Fulfillment Foundation: Application Platform Configuration Guide
Procedure
1. In the Organization Details window, choose the Payment Info tab.
2. Enter information in the applicable fields. Refer to Table 38 for field value
descriptions.

3. Choose .

Table 38. Payment Info Tab


Field Description
Account Number With Hub Enter the organization's account number used for monetary
transactions with the Hub organization, if applicable.
Tax Information
Tax Payer ID Enter the organization's tax payer identification number. This
number identifies the organization as a tax paying entity.
Authority Type Enter the authority type given for an exemption certificate, if
applicable.
Tax Exempt Check this box if the organization is exempt from paying
taxes.
Exemption Certificate Enter the identification number of the exemption certificate.
Issuing Authority Enter the authority that issued the exemption certificate.
Tax Jurisdiction Enter the tax jurisdiction that the exemption certificate was
issued in.

Chapter 3. Configuring Participants 107


Table 38. Payment Info Tab (continued)
Field Description
Billing Address The the organization's billing address. This information is
mandatory.

Choose to enter an address.

Choose the Contact Info tab to view additional contact


information.

Viewing an Organization's Child Organizations


About this task

You can view any child organizations an organization may have.

To view an organization's child organizations, choose the Child Organizations tab


in the Organization Details window. You can create and modify organizations from
this tab as described in detail in additional sections of this chapter.

Defining an Organization’s Calendars


You can define an organization’s working calendar. A working calendar is a span
of dates for a defined period for which you can define any working shifts (for
example, Day Shift, Night Shift), exception shifts (for example, extra shifts on the
last day of the month for performing inventory stock), and exception days (for
example, Fourth of July, New Years Day).

108 Sterling Selling and Fulfillment Foundation: Application Platform Configuration Guide
A node or an organization can choose its calendars as well as the calendars of its
primary enterprise as its business calendar, shipping calendar, or receiving
calendar.

A node or an organization can also inherit calendar definition from its primary
enterprise when creating calendars. If a calendar is inherited from another
calendar, the parent calendar’s components such as Effective Periods, Shifts,
Calendar Day Exceptions, and Exception Shifts can be used by the child calendar
during runtime. This implies that the inherited calendars cannot specify their own
effective periods or shifts. However, a child calendar has the ability to specify its
own set of Calendar Day Exceptions and Exception Shifts. These are used in
conjunction with the parent calendar’s components while retrieving the day details
of the child calendar during runtime.

Note: The child calendar’s Calendar Day Exceptions and Exception Shifts override
those of the parent calendar if they fall on the same date.

The following limitations are assumed when inheriting calendars:


v A calendar of an organization or a node can only be inherited from a calendar of
the primary enterprise and from its own calendar.
v The parent calendar cannot be an inherited calendar.
v An inherited calendar is not allowed to change to a non-inherited calendar and
vice-versa.
v An inherited calendar is not allowed to specify its own effective periods and
standard shifts.
v If a calendar is inherited from another calendar:
– only Calendar Day Exceptions and Exception Shifts can be defined for the
inherited calendar.
– the exception dates must fall under one of the effective periods of the parent
calendar. Moreover, the start time and end time of the exception shifts must
match the start time and end time of a shift within that effective period.

Setting Up an Organization's Calendar


About this task

To set up an organization's calendar:

Procedure
1. In the Organization Details window, choose the Calendar tab. The Calendar list
displays.
2. Select . The Create Calendar pop-up window displays.

Chapter 3. Configuring Participants 109


Table 39. Create Calendar Pop-up Window
Field Description
Inherit Definition from From the drop-down list, select the parent calendar from
Calendar which you wish to inherit the calendar definition.
Note: This list does not contain calendars that are inherited.
Note: Once a calendar is selected from this list, the Default
Effective From, Default Effective To, and Shifts for Effective
Periods are disabled.
Calender ID Enter the identification for the calendar.
Description Enter the description for the calendar.
Default Effective From Enter the beginning date (according to the date format
defined in the organization's locale) of the timeframe from
which the calendar is effective.
Default Effective To Enter the ending date (according to the date format defined
in the organization's locale) of the timeframe to which the
calendar is effective. However, because the ending date is
perceived by the system as having the time 00:00:00, the
ending date is not included in the date range.
Shift Name Enter the name of the shift.
Start Time Enter the start time of the shift.
End Time Enter the end time of the shift.

Select the days on which the shift is worked. Continue adding shifts as needed.

Note: A single calendar can have multiple effective periods.

3. Choose . The Calendar Details pop-up window displays.

110 Sterling Selling and Fulfillment Foundation: Application Platform Configuration Guide
Defining a Calendar's Defaults
About this task

You can configure the default effective dates and working shifts for a calendar.

Note: The default effective dates and working shifts cannot be defined for
inherited calendars.

To configure calendar defaults:

Procedure
1. From the Calendar Details pop-up window, choose . The Default Calendar
Configuration pop-up window displays.

Chapter 3. Configuring Participants 111


2. From Effective Period, select the timeframe through which you want the
calendar to be used.

v Choose to create additional effective periods to associate with the


calendar.

Note: Effective periods cannot overlap each other. Nor can they start or end
in the middle of the day.
3. In Shift Name, enter the name of the shift.
4. In Start Time, enter the time the shift starts.
5. In End Time, enter the time the shift ends.

Note: You cannot configure a shift to carry over to the next day.
6. From Shift Valid For, select the days of the week the shift you are configuring
is valid for.

7. Choose . The shift now displays in Calendar Details pop-up window for
any of the default days you have selected.

Creating an Exception for a Particular Calendar Day


About this task

You can mark a regular working day as a non-working day or indicate if certain
shifts are valid or not for a particular day. The exceptions that you indicate are
only valid for that day.

For example, if the Fourth of July is a holiday for the organization, and it falls on a
Friday, which is a normal working day, you can mark that particular date as a
non-working day.

As another example, if the organization has an extra shift for taking inventory on
the last day of each month. You can create that shift and mark it as a valid shift for
the last day of each month within your calendar's effective period.

112 Sterling Selling and Fulfillment Foundation: Application Platform Configuration Guide
To mark a regular working day as a non-working day or vice versa, select the date
you want from the Calendar Details pop-up window and choose the applicable
exception from the Day Details frame.

To mark a default shift as valid or invalid:

Procedure
1. From the Calendar Details window, select the date you want to work with.
2. If the date is a default non-work day:
a. Select Working Day.
b. Select the shift you want to mark as valid or invalid from the Shifts table.
Check Is Valid to indicate that the shift is valid for that particular date.
Uncheck Is Valid to indicate that the shift is not valid for that particular
date.
c. Choose OK, then choose from the Day Details window.
3. If the date is a default work day, select Non-Working Day. This automatically
unchecks the Is Valid box for all shifts on that day. Choose from the Day
Details window.

Chapter 3. Configuring Participants 113


Note: If you choose from the Calendar Details window. The date that was
highlighted shows the color of an exception day, even if no changes were made
to that day.

4. You can apply the defaults for the overrides by choosing . But you cannot
restore the defaults for parent overrides in inherited calendars.

Viewing an Organization’s Departments


About this task

You can view all departments of an organization.

To view an organization’s departments, choose the Departments tab in the


Organization Details window.

Creating a Department
About this task

To create a department:

Procedure
1. In the Organization Details window, choose the Departments tab. The
Department List displays.

2. From the Department List, select . The Department Details pop-up window
displays.
3. Enter information in the applicable fields. Refer to the Results for field value
descriptions.

4. Choose .

Results
Field Description
Department Code
A unique code to identify the department.
Department Name
Name of the department.
Department Abbreviation
Abbreviation of the department name.

114 Sterling Selling and Fulfillment Foundation: Application Platform Configuration Guide
Queue
Select the default alert queue for the department to which the exceptions
are routed. The list contains only those alert queues which are configured
on the departments organization. For more information about creating alert
queues, see, Chapter 12, “Configuring Alert Queues,” on page 305.
Email Id
Enter the email id for the department.

Department Details Pop-up Window

Modifying a Department
About this task

To modify a department:

Procedure
1. In the Organization Details window, choose the Departments tab. The
Department List displays.

2. From the Department List, select the applicable department and choose .
The Department Details pop-up window displays.
3. Modify information in the applicable fields.
4. Choose .

Deleting a Department
About this task

To delete a department:

Procedure
1. In the Organization Details window, choose the Departments tab. The
Department List displays.

2. From the Department List, select the applicable department and choose .

Modifying an Organization
About this task

Once an organization has been created, you can modify it.

To modify an organization:

Procedure
1. From the tree in the application rules side panel, choose Participant Modeling >
Participant Setup. The Organization Search window displays in the work area.

2. Enter the applicable search criteria and choose . A list of organizations


displays.

3. Select the organization and choose . The Organization Details window


displays.
4. Refer to the topics under “Creating and Modifying an Organization” on page
23 for further instructions.

Chapter 3. Configuring Participants 115


Creating and Modifying an Organizational Hierarchy
You can organize any existing organizations in an organizational hierarchy. This
hierarchy can be used to configure the relationships between related organizations.
For example, if you have a multi-divisional setting with one parent Hub and
several Enterprises below it, you can organize all of the existing Enterprises under
the Hub in the organizational hierarchy. You can add and remove organizations
from the organizational hierarchy.

Creating an Organizational Hierarchy


About this task

To create an organizational hierarchy:

Procedure
1. From the tree in the application rules side panel, choose Participant Modeling >
Participant Setup. The Organization Search window displays in the work area.
2. Enter applicable search criteria and choose . A list of organizations displays.
3. Select the organization you want to build an organizational hierarchy for and
choose .
4. The Organizational Hierarchy tree displays in the left frame with the name of
the organization you chose. You can now add organizations to the hierarchy.

Adding an Organization to the Organizational Hierarchy


About this task

To add organizations to the organizational hierarchy:

Procedure
1. From the tree select the organization you want to add the organization under.

2. From the Organizational Hierarchy tree, choose . The Add Organization to


Hierarchy pop-up window displays.

3. Enter the applicable search criteria and choose . A list of organizations


displays.
4. Select the organization you want to add to the organizational hierarchy and
choose .

Removing an Organization from the Organizational Hierarchy


About this task

To remove an organization from the organizational hierarchy, select the


organization you want to remove from the Organizational Hierarchy tree and
choose .

116 Sterling Selling and Fulfillment Foundation: Application Platform Configuration Guide
Creating Node Types
You can create node types to classify nodes. You can use node types to define node
relationships, and set inventory rules.

For more information about defining inventory node type rules, see the Sterling
Selling and Fulfillment Foundation: Global Inventory Visibility Configuration Guide.

Creating a Node Type


About this task

To create a node type:

Procedure
1. From the tree in the application rules side panel, choose Participant Modeling >
Node Types. The Node Type window displays in the work area.
2. Choose . The Node Type Details pop-up window displays.
3. Enter information into the applicable fields. Refer to Table 40 for field level
descriptions.
4. Choose .

Table 40. Node Type Details Pop-up Window


Field Description
Node Type Enter a name for the node type.
Description Enter a description for the node type.

Modifying a Node Type


About this task

To modify a node type:

Procedure
1. From the tree in the application rules side panel, choose Participant Modeling >
Node Types. The Node Type window displays in the work area.

2. Select the applicable node type and choose . The Node Type Details pop-up
window displays.
3. Enter information into the applicable fields. Refer to Table 40 for field level
descriptions.

4. Choose .

Chapter 3. Configuring Participants 117


Deleting a Node Type
About this task

To delete a node type:

Procedure
1. From the tree in the application rules side panel, choose Participant Modeling >
Node Types. The Node Type window displays in the work area.

2. Select the applicable node type and choose .

118 Sterling Selling and Fulfillment Foundation: Application Platform Configuration Guide
Chapter 4. Configuring Process Models
Process Modeling[Application Process Modeling] is the setting up of the Sterling
Selling and Fulfillment FoundationSterling Application Platform business process
workflow. The Sterling Selling and Fulfillment FoundationSterling Application
Platform workflow consists of the entire set of business logic that defines how
Sterling Selling and Fulfillment FoundationSterling Application Platform handles
business documents and transactions on those documents. A transaction is a
logical unit of work that encapsulates certain business logic. Transactions can be
related to orders, inventory changes, returns, payment authorizations, or many
other system events. Order Create, Inventory Monitor, and Send Release are
examples of transactions.

Business process workflow consists of:


v Document types
v Repositories
v Process-type pipelines
v Transactions
v Conditions
v Events
v Statuses
v Actions
v Services

Document Type Configuration


Sterling Selling and Fulfillment FoundationSterling Application Platform uses
document types to carry information through a configured business process
workflow. These documents are derived from base document types. A base
document type defines the business documents that Sterling Selling and
Fulfillment FoundationSterling Application Platform handles, and defines a
common storage structure for all derived document types.

The following base document types are defined in Sterling Selling and Fulfillment
FoundationSterling Application Platform:
v General
v Order
v Load
v Count
v Container
v Wave
v Work Order
v Opportunity

Note: The available base document types are pre-defined and cannot be added
to.

© Copyright IBM Corp. 1999, 2011 119


Document types are specific business documents that are derived from a base
document type. For example, document types such as Sales Order and Purchase
Order are derived from the Order base document type.

For detailed information about document types, see Chapter 26, “Document
Types,” on page 639.

To complete a life cycle, each document type has a set of different processes that it
can go through. These processes are called process types. Every base document
type has a defined set of process types in Sterling Selling and Fulfillment
FoundationSterling Application Platform.

Following are the process types defined in Sterling Selling and Fulfillment
FoundationSterling Application Platform (for the base document types):
v Order Fulfillment
v Order Negotiation
v Outbound Shipment
v Planned Order Execution
v Planned Order Negotiation
v Reverse Logistics
v Return Shipment
v Return Receipt
v Template Order
v Purchase Order Execution
v Purchase Order Negotiation
v Inbound Shipment
v Purchase Order Receipt
v Transfer Order Execution
v Transfer Order Delivery
v Transfer Order Receipt
v Master Order Fulfillment
v Quote Fulfillment
v Load Execution
v General
v WMS Putaway
v WMS Layout Definition
v WMS Inventory
v Trailer Loading
v Task Execution
v Move Request Execution
v Manifesting
v Over Pack Build
v Count Execution
v Pack Process
v Outbound Picking
v VAS Process

120 Sterling Selling and Fulfillment Foundation: Application Platform Configuration Guide
Business rules such as payment collection rules and modification rules must be set
up for each document type.

The Process Modeling Tree


About this task

In Sterling Selling and Fulfillment FoundationSterling Application Platform, you


can view a graphical representation of each base document type and it's document
and process types.

To view the process modeling tree:

Procedure
1. From the tree in the application rules side panel, choose Process Modeling. The
Process Modeling window displays in the work area.
2. Select the Order, Load, or General tab to view the corresponding process
modeling tree for that base document type.

Defining a New Document Type


You may need to create a new document type if the rules pertaining to a key
action, such as inventory updates, are affected. In this case, you can save an
existing document type as a new custom document type. The new document type
retains all of the process types associated with the document type you saved from.
Database tables at both the document type level and the process type level are also
copied to the new document type.

The following document type attributes are copied to the new document type:
v Document parameters
v Document templates
v Charge categories
v Charge names
v Common codes
v Order line types
v Purge criteria
v Business rules
v Receiving dispositions

The following process type level attributes are copied to the new document type:
v Process type rules
v Date types
v Process task types
v Statuses
v Status inventory types
v Modification types
v Modification rules
v Transactions
v Transaction pickup statuses
v Transaction drop statuses
v Events

Chapter 4. Configuring Process Models 121


Creating a New Document Type
About this task

To create a new document type:

Procedure
1. From the Process Modeling window, select the Order, Load, or General tab to
view the corresponding process modeling tree for that base document type.
2. In the Document Types swimlane, right-click on the applicable document type
and choose Save As. The New Document Type window displays.

3. In Document Type, enter the new document type identification number.


4. In Description, enter a brief description of the document type.
5. For each process type associated with the document type you are saving as,
enter the process type, the process type name, and a brief description.

6. Choose . The new document type displays in the document type tree with
the associated process types.

Note: An .ex extension is automatically appended to the document type and


process type values you have specified.

122 Sterling Selling and Fulfillment Foundation: Application Platform Configuration Guide
Modifying a Document Type's Description
About this task

You can modify a document type's description.

To modify a document type's description:

Procedure
1. In the Process Modeling window, select the Order, Load, or General tab to view
the corresponding process modeling tree for that base document type.
2. In the Document Types swimlane, right-click on the applicable document type
and choose Details. The Document Type Details window displays.

3. In Description, enter the new description.

4. Choose .

Modifying a Process Type


About this task

You can define the parameters and templates that are particular to an individual
process type. These definitions are applied to a document throughout its lifecycle
in the process type.

To modify a process type:

Procedure
1. In the Process Modeling window, select the Order, Load, or General tab to view
the corresponding process modeling tree for that base document type.
2. In the Process Types swimlane, right-click on the applicable process type and
choose Details. The Process Type Details window displays.

Chapter 4. Configuring Process Models 123


Note: For details about defining the Quote Fulfillment Process Type's Primary
Information, see “Defining the Quote Fulfillment Process Type's Primary
Information” on page 128. For details about defining the Opportunity
Fulfillment Type's Primary Information, see “Defining the Opportunity
Fulfillment Process Type's Primary Information” on page 129.

Defining a Process Type's Primary Information


About this task

You can define a process type's parameters for order creation, inventory, financial
transactions, and other related entities. These parameters are applied to a
document throughout its life cycle in the process type.

To define a process type's primary information:

Procedure
1. In the Process Modeling window, select the Order, Load, or General tab to view
the corresponding process modeling tree for that base document type.
2. In the Process Types swimlane, right-click on the applicable process type and
choose Details. The Process Type Details window displays.
3. Choose the Primary Info tab.
4. Enter information in the applicable fields. Refer to Table 41 on page 125 for
field value descriptions.

5. Choose .

124 Sterling Selling and Fulfillment Foundation: Application Platform Configuration Guide
Table 41. Process Type's Primary Info Tab
Field Description
Process Type The process type ID.
Process Type Name Enter the name of the process type.
Description Enter a brief description of the process type.
Document Classification Select the document type you want to use for the process
type.
Use as a Template Order Select this field if documents in this process type can be used
as a template for another document.
Validate Item During Order Select this field if you want item IDs and units of measure to
Creation/ Modification be validated against the Catalog Management application (or
external Catalog Management application) upon order
creation or adding an order line.
Driver Date
Requested Ship Date Select this option if you want the fulfillment process to be
driven by the order document's requested ship date.
Requested Delivery Date Select this option if you want the fulfillment process to be
driven by the order document's requested delivery date.
Order Creation Tab

Chapter 4. Configuring Process Models 125


Table 41. Process Type's Primary Info Tab (continued)
Field Description
Use Template Order For Select this field if you want to be able to default some
Defaulting attributes of an existing order into a newly created order.

When an order is created and this field is selected, the system


looks for an existing order with the same Buyer, Seller, and
Enterprise organizations, as well as the document type
specified in the Template Document Type field. If an existing
template is found, some of the attributes may be copied into
the new order.

For more information about template orders, see the Sterling


Selling and Fulfillment Foundation: Distributed Order
Management User Guide, the Sterling Selling and Fulfillment
Foundation: Supply Collaboration User Guide, and the Sterling
Selling and Fulfillment Foundation: Reverse Logistics User Guide.
Template Document Type If you choose Use Template Order For Defaulting, select the
document type you want to use for the default template
order.
Log Audits For Draft Order Select this field if you want the system to log audit records
when modifications are made to orders in draft status.
Note: Changes to order status are audited whether or not
you select this option.
Refund Fulfillment Order Select the document type you want to use from refund
Document Type fulfillment orders.
Default Delivery Method Select Default Delivery Method Based On Catalog if you
Based On Catalog want the system to default to the configured delivery method
assigned to items set up as Delivery Allowed in the catalog.
For more information about defining item attributes, see the
Catalog Management: Configuration Guide.
Note: This field should not be selected for any document
types other than Sales Orders.
Suppress Audits for Select this field if the CHANGE_STATUS audits have to be
Change Order Status suppressed by the changeOrderStatus API for any change in
the order status.
Inventory Tab
Demand Type For Schedule Select the demand type to be considered when the Schedule
Order time-triggered transaction is run.

Important: All the supply types that you have associated


with the demand type in the Inventory Considerations table
are considered for scheduling inventory to satisfy demand
optimization. For more information about configuring
inventory considerations, see the Sterling Selling and
Fulfillment Foundation: Global Inventory Visibility Configuration
Guide.

Note: The demand type should have the same supply types
associated with it as the demand type of the transaction that
you plan for Schedule Order to drop into for this process
type.

126 Sterling Selling and Fulfillment Foundation: Application Platform Configuration Guide
Table 41. Process Type's Primary Info Tab (continued)
Field Description
Demand Type for Release Select the demand type to be considered when the Release
Order time-triggered transaction is run.

Important: All the supply types that you have associated


with the demand type in the Inventory Considerations table
are considered for release inventory calculations. For more
information about configuring inventory considerations, see
the Sterling Selling and Fulfillment Foundation: Global Inventory
Visibility Configuration Guide.
Allow Inventory Updates Select this field if you want the system to perform inventory
For The Seller Organization updates for the Seller.
Allow Inventory Updates Select this field if you want the system to perform inventory
For The Buyer updates for the Buyer.
Organization
Allow Inventory Check Select this field if you want inventory supply and demand
During Schedule And data stored in the system to be used for availability
Release calculation during the schedule and release processes.
Create Reservation On Select this field if you want to enable reservations during
Order Creation order creation.
Note: This field is not applicable for procurement orders.
Procurement Placed Supply Select the supply type of the supply to be considered when a
Type procurement order is placed.
Financials Tab
Allow Invoice Creation Select this field to enable invoice creation for orders or
shipments.
Allow Pro Forma Invoice Select this field to enable Pro Forma invoice creation for
Creation For Shipments shipments. For more information about Pro Forma invoicing,
see the Sterling Selling and Fulfillment Foundation: Product
Concepts Guide.
Note: This flag is only applicable to shipments created from
orders. This flag is ignored for shipments without orders. For
more information about creating Pro Forma invoices for
shipments without orders, see the Sterling Selling and
Fulfillment Foundation: JavadocsJavadocs.
Allow Payment Processing Select this field to enable payment processing. For more
information about payment processing, see the Sterling Selling
and Fulfillment Foundation: Product Concepts Guide.
Allow Price Calculation For Select this field if you want to be able to associate a price
Draft Orders with an item during draft order creation. For more
information about configuring prices, see the Sterling Selling
and Fulfillment Foundation: Distributed Order Management
Configuration Guide or the Business Center: Pricing
Administration Guide.
Note: If both this field and Allow Price Calculation For
Confirmed Orders are not selected, no price calculations are
performed on orders, even if they have price lists associated
with them. If both this field and Allow Price Calculation For
Confirmed Orders are selected, price calculations can be
performed at any point in an order's creation cycle. If only
this field is selected, price calculations are only done at the
time of draft order creation.

Chapter 4. Configuring Process Models 127


Table 41. Process Type's Primary Info Tab (continued)
Field Description
Allow Price Calculation For Select this field if you want pricing to be done upon draft
Confirmed Orders order confirmation and order creation.
Note: If both this field and Allow Price Calculation For Draft
Orders are not selected, no price calculations are performed
on orders, even if they have price lists associated with them.
If both this field and Allow Price Calculation For Draft
Orders are selected, price calculations can be performed at
any point in an order's creation cycle. If only this field is
selected, price calculations are only done at any point after
orders have been confirmed where it is applicable to do so
(for example, after a quantity adjustment).
Related Entities
Allow Chained Order Select this field if you want the order document to have the
Creation ability to create chained orders during scheduling.
Chained Procurement Select the document type you want to use for the chained
Inbound Order Document order document in a procurement inbound order scenario.
Type
The procurement inbound order scenario occurs when the
final shipping point to the customer is one of your nodes and
the shipping node does not have enough stock and needs to
be replenished from an external organization's node.
Consolidate New Order Select this field if you want the system to attempt to
Releases consolidate new releases into existing releases that have not
been processed.
Chained Procurement Select the document type you want to use for the chained
Transfer Order Document order document in a procurement transfer order scenario.
Type
The procurement transfer order scenario occurs when the
final shipping point to the customer is one of your nodes and
the shipping node does not have enough stock and needs to
be replenished from another node within your organization.
Allow Propagation Of Select this field if you want changes on a derived order to be
Changes To Derived Parent propagated to its derived parent when the appropriate
listener transaction is configured.
Note: If this field is not selected, a derived order's quantity
can be greater than the parent order that is was derived from.
Create Shipments For If this is checked, shipments should be created for all the
Products Being Delivered products, which are delivered along with the work order.
In Addition To Work Order Note: If the flag is unchecked, you cannot create releases
since releases are not required without shipments.

Defining the Quote Fulfillment Process Type's Primary


Information
About this task

To define a quote fulfillment process type's primary information:

Procedure
1. In the Process Modeling window, select the Order tab to view the
corresponding process modeling tree for that base document type.
2. In the Process Types swimlane, right-click on the Quote Fulfillment process
type and choose Details. The Process Type Details window displays.

128 Sterling Selling and Fulfillment Foundation: Application Platform Configuration Guide
3. Choose the Primary Info tab.
4. Enter information in the applicable fields. Refer to Table 42 for field value
descriptions.

5. Choose .

Table 42. Quote Fulfillment Process Type's Primary Info Tab


Field Description
Process Type The process type ID. Enter QUOTE_FULFILLMENT.
Process Type Name Enter the name of the process type, Quote Fulfillment.
Description Enter a brief description of the process type.
Document Classification Select the Quote document type from the drop-down list.
Validate Item During Order Select this field if you want item IDs and units of measure to
Creation/ Modification be validated against the Catalog Management application (or
external Catalog Management application) upon quote
creation or adding a quote line.
Log Audits For Draft Order Select this field if you want the system to log audit records
when modifications are made to quotes.
Note: A quote is in a draft status throughout the quote
fulfillment lifecycle.
Allow Price Calculation For Select this field if you want to be able to associate a price
Draft Orders with an item during quote creation. For more information
about configuring prices, see the Sterling Selling and
Fulfillment Foundation: Distributed Order Management
Configuration Guide or the Business Center: Pricing
Administration Guide.
Default Delivery Method Select Default Delivery Method Based On Catalog if you
Based On Catalog want the system to default to the configured delivery method
assigned to items set up as Delivery Allowed in the catalog.
For more information about defining item attributes, see the
Catalog Management: Configuration Guide.

Defining the Opportunity Fulfillment Process Type's Primary


Information
About this task

To define an opportunity fulfillment process type's primary information:

Chapter 4. Configuring Process Models 129


Procedure
1. In the Process Modeling window, select the Opportunity tab to view the
corresponding process modeling tree for that base document type.
2. In the Process Types swimlane, right-click on the Opportunity Fulfillment
process type and choose Details. The Process Type Details window displays.
3. In the Primary Info tab, enter information in the applicable fields. Refer to
Table 43 for field value descriptions.

4. Choose

Table 43. Opportunity Fulfillment Process Type's Primary Info Tab


Field Description
Process Type The process type ID. Enter OPPORTUNITY_FULFILLMENT.
Process Type Name Enter the name of the process type, Opportunity Fulfillment.
Description Enter a brief description of the Opportunity process type.

Defining a Process Type's Templates (Fulfillment Process Types


Only)
About this task

Document templates are used at various times throughout Sterling Selling and
Fulfillment FoundationSterling Application Platform. The template type indicates
how it is used. Typically, templates are required in scenarios in which a particular
set of attributes of a given entity need to be considered for processing. For
example, when calling the copyOrder() API, the Copy Order template is used to
indicate which order attributes should be copied.

You can determine which XML attributes and elements should be included or
excluded from master template XMLs for a given fulfillment process type.

To define a process type's XML templates:

Procedure
1. In the Process Modeling window, select the Order, Load, or General tab to view
the corresponding process modeling tree for that base document type.
2. In the Process Types swimlane, right-click on the applicable process type and
choose Details. The Process Type Details window displays.
3. Choose the Templates tab. The available master templates for the fulfillment
process type you are working with display as tabs. These master templates are
retrieved from the YFS_BASE_DOCUMENT_TYPE table.

130 Sterling Selling and Fulfillment Foundation: Application Platform Configuration Guide
4. Choose the tab of the applicable master template. The master template XML is
loaded from the YFS_BASE_DOCUMENT_TEMPLATE table and is combined
with the template XML stored for this document type in the
YFS_DOCUMENT_TEMPLATE table. Extended attributes are also added to the
master template for each element that has extended attributes. The resulting
XML is shown in hierarchical format in the tree.

Note: The extended branch of the template XML is automatically generated. It


is not stored in either the YFS_DOCUMENT_TEMPLATE or
YFS_BASE_DOCUMENT_TEMPLATE tables.

5. Choose to include an XML attribute or element in the master template


XML for this process type. Choose to exclude an XML attribute in the
master template XML for this process type.

Note: If you want to exclude all of an element's attributes, you must exclude
the entire element.

Note: Some attributes are mandatory and cannot be excluded from the
template.

Chapter 4. Configuring Process Models 131


Defining Process Type Pipelines
You can define your business process workflow by creating process type pipelines.
A process type pipeline is a series of transactions and statuses that guide
document types, such as a Sales Order, through a predefined process. A pipeline
consists of the different statuses a document goes through during fulfillment,
negotiation, shipment, or receipt. You can also set up transactions consisting of
events, actions, and conditions, as they pertain to the pipeline you are configuring.

Repositories

A repository is a logical collection of entities that define the business process


workflow.

The following entities are included in a repository:


v Pipelines
v Transactions
v Statuses
v Conditions
v Actions
v Services

Sterling Selling and Fulfillment FoundationSterling Application Platform provides


a base repository for each of the system-defined process types. Some of the entities
within a repository are copied when creating a new document type.

When you choose Model Process from the Process Modeling tree, two frames
display. The left-hand frame is the repository and the right-hand frame is the work
area.

There are six available tabs at the bottom of the repository. These tabs allow you to
switch between the Pipeline tree, Transaction tree, Status tree, Condition tree,
Action tree, and Service tree. When you choose an entity from any of these trees,
its details display in the work area frame, if applicable.

When configuring a pipeline, you can enable auto-hints to aid you in your
configuration process. To activate auto-hints, right-click anywhere in the work area
and choose Enable Auto Hint. When auto-hints are activated, transactions that a
particular drop status can connect to are highlighted in a blue frame when you are
setting up a graphical pipeline.

Defining Pipeline Determination


Pipeline determination is used to set up conditions that affect which pipeline is
used during the start of the business process workflow. For example, an
organization deals with sales orders that sometimes contain hazardous materials.
They have two separate pipelines, one in which orders with order lines without
any hazardous materials go through and one in which orders with order lines
containing hazardous materials must go through for inspection before continuing
through the order process. The organization uses pipeline determination to set up
a condition that determines whether or not order lines contain hazardous materials
and sends the order line down the correct pipeline.

When you expand the Pipeline Determination branch, the components displayed
depends on what role you are logged in as. If you are logged in as a Hub role, the

132 Sterling Selling and Fulfillment Foundation: Application Platform Configuration Guide
Hub Rule displays. If you are logged in as an Enterprise role, both the Hub Rule
and My Rule components display. Double-click on the applicable node to display
the pipeline determination rules.

Note: If you are logged in as an Enterprise role, the Hub Rule screen is grayed out
and cannot be modified.

Drag conditions and pipelines into the work area to construct pipeline
determination rules. A single pipeline or condition must be the root. Conditions
cannot link back to an earlier component in the chain and a pipeline cannot be
linked to twice.

Note: When configuring pipeline determination for an order document type


pipeline, please note that pipeline determination is only considered when adding a
line or creating an order. When changes are made to draft orders pipeline
determination does not occur.

Creating a Pipeline
About this task

You can create a pipeline for the process type that you are working with.

To construct a pipeline you can drag transactions and conditions into the pipeline
work area. Each transaction has a set of branches relating to each drop status. To
link a transaction to another transaction you must drag the appropriate port from
the first transaction to the second. You can identify what status belongs to which
port by putting the arrow over the transaction's ports. You can link transactions
back to themselves assuming they are allowed to pick up the status being linked
back to.

Transactions can also be linked to conditions. To specify that you are extending the
drop status with a condition, drag the port to the applicable condition and then to
the pickup transaction. If the pickup status has the same base as the port, the link
is allowed. Once the link is made, it is defaulted to the first possible pickup status.

To create a pipeline:

Procedure
1. In the Process Modeling window, select the Order, Load, or General tab to view
the corresponding process modeling tree for that base document type.
2. In the Process Types swimlane, right-click on the applicable process type and
choose Model Process. The Repository Details window and work area display
for the corresponding process type.
3. Choose the Pipeline tab.
4. Select Pipelines and choose . The Pipeline Detail window displays in the
work area.

Chapter 4. Configuring Process Models 133


5. Drag and drop the applicable transactions and conditions into the work area
and connect them following the rules detailed in this section.

6. Choose .

Saving a Pipeline as a Draft


About this task

You can save an incomplete pipeline as a draft. This draft can be retrieved for a
final save without any necessary validations. When you save and activate the
pipeline, the draft pipeline is deleted from the system.

To save a service as a draft:

Procedure
1. In the Process Modeling window, select the Order, Load, or General tab to view
the corresponding process modeling tree for that base document type.
2. In the Process Types swimlane, right-click on the applicable process type and
choose Model Process. The Repository Details window and work area display
for the corresponding process type.
3. Choose the Pipeline Tab.

134 Sterling Selling and Fulfillment Foundation: Application Platform Configuration Guide
4. Configure a pipeline as per the rules detailed in this section.

5. Choose . The pipeline is saved as a draft service.


6. When you are ready to save it as a complete and functional pipeline, choose

.
Note: During runtime, when a status is reached that has been configured to be
picked up by more than one TaskQ-based transaction in the pipeline, Sterling
Selling and Fulfillment FoundationSterling Application Platform creates a
TaskQ record for each of those transactions.

Note: This includes situations where the Yes and No branches of a condition
both drop into the same status, but feed into different TaskQ-based
transactions.

Note: When you save a pipeline as a draft, any existing draft for the pipeline is
overwritten. When you save the draft as an actual pipeline, any existing
pipeline with the same pipeline ID is overwritten.

Note: The Order Delivered Status can be picked up by more than one
transaction. There is no implied order of processing between these transactions.
Depending on which transaction is run first, this status is processed.

Modifying a Pipeline
About this task

Note: Sterling Selling and Fulfillment FoundationSterling Application Platform


does not support modification of pipelines while it is processing transactions.
Modify pipelines only on a quiet system, when no APIs or agents are running.

Note: If high availability is a concern, never modify pipelines directly in


production. Make all the changes in your test, and then migrate the changes to
your production environment using the Sterling Selling and Fulfillment
FoundationSterling Application Platform Configuration Deployment Tool.

To modify a pipeline:

Procedure
1. In the Process Modeling window, select the Order, Load, or General tab to view
the corresponding process modeling tree for that base document type.
2. In the Process Types swimlane, right-click on the applicable process type and
choose Model Process. The Repository Details window and work area display
for the corresponding process type.
3. Choose the Pipeline tab.
4. Expand the Pipelines branch.
5. Select the applicable pipeline and choose . The Pipeline Detail window
displays in the work area.
6. Using the rules and concepts detailed in the Basics section of this chapter,
modify the pipeline according to your business practices. For more information
about how use the drag and drop window, see Section 2.2.2.4 "Drag and Drop
Window".

7. Choose .

Chapter 4. Configuring Process Models 135


Note: During runtime, when a status is reached that has been configured to be
picked up by more than one TaskQ-based transaction in the pipeline, Sterling
Selling and Fulfillment FoundationSterling Application Platform creates a
TaskQ record for each of those transactions. This includes situations where the
Yes and No branches of a condition both drop into the same status, but feed
into different TaskQ-based transactions.

Defining a Pipeline's Monitoring Rules


About this task

Using the monitoring rule components you configured while defining the process
type, you can define the parameters used to monitor orders and shipments
throughout their life cycle in fulfillment and shipment process type pipelines. For
more information about configuring the monitoring rule components, see the
Sterling Selling and Fulfillment Foundation: Distributed Order Management
Configuration Guide.

Note: You can only define a pipeline's monitoring rules if your organization owns
the pipeline you are configuring them for.

To define a pipeline's monitoring rules:

Procedure
1. In the Process Modeling window, select the Order, Load, or General tab to view
the corresponding process modeling tree for that base document type.
2. In the Process Types swimlane, right-click on the applicable process type and
choose Model Process. The Repository Details window and work area display
for the corresponding process type.
3. Choose the Pipeline tab.
4. Expand the Pipelines branch.

5. Select the applicable pipeline and choose . The Monitor Rules window
displays in the work area.

136 Sterling Selling and Fulfillment Foundation: Application Platform Configuration Guide
6. From Rule List, choose . The Rule Type pop-up window displays.

7. Select the rule type you want to define and add to the rule list. The rule details
displays in the lower frame. You can select the hyper-text in the rule details
and define the individual parameters. Refer to Table 44 on page 138 for a list of
rule types and their configurable rule details.

Chapter 4. Configuring Process Models 137


Note: When defining the hours parameter, you can select whether the hours
are based on elapsed hours or on the working hours for any calendars you may
have defined.

8. Choose .

Note: You can increase or decrease a monitoring rule's priority by selecting the
rule and choosing the up-arrow to increase it's priority and the down-arrow to
decrease its priority.
Table 44. Monitoring Rule Types
Rule Details (Bold and Italicized Text Indicates
Rule Type Configurable Parameters)
Milestone has not reached If Order/Shipment has not reached a milestone n calendar
before a date hours before a date type, then raise a monitor event.
Milestone has not reached If Order/Shipment has not reached a milestone within n
after a date calendar hours of a date type, then raise a monitor event.
Milestone has not reached If Order/Shipment has not reached a milestone within n
after another Milestone calendar hours of a milestone, then raise a monitor event.
Milestone has reached If Order/Shipment has reached a milestone n calendar hours
before a date before a date type, then raise a monitor event.
Milestone has reached after If Order/Shipment has reached a milestone within n calendar
a date hours of a date type, then raise a monitor event.
Milestone has reached after If Order/Shipment has reached a milestone within n calendar
another Milestone hours of a milestone, then raise a monitor event.
Has been in a status If Order/Shipment has been in a status for n calendar hours,
then raise a monitor event.
Before a date For Order/Shipment n calendar hours before a date type, raise
a monitor event.
After a date For Order/Shipment n calendar hours after a date type, raise a
monitor event.
After a Milestone For Order/Shipment n calendar hours after a milestone, raise a
monitor event.
Date before another date For Order/Shipment, if a date type is more than n calendar
hours before a date type, then raise a monitor event.
Date within a specified For Order/Shipment, if a date type is within n calendar hours
time after another date after a date type, then raise a monitor event.
Date not within a specified For Order/Shipment, if a date type is not within n calendar
time after another date hours after a date type, then raise a monitor event.
Date after another date For Order/Shipment, if a date type is more than n calendar
hours after a date type, then raise a monitor event.
Conditionally Milestone If Order/Shipment meets a condition and has not reached a
has not reached before a milestone n calendar hours before a date type, then raise a
date monitor event.
Conditionally Milestone If Order/Shipment meets a condition and has not reached a
has not reached after a date milestone within n calendar hours of a date type, then raise a
monitor event.
Conditionally Milestone If Order/Shipment meets a condition and has not reached a
has not reached after milestone within n calendar hours of a milestone, then raise a
another Milestone monitor event.

138 Sterling Selling and Fulfillment Foundation: Application Platform Configuration Guide
Table 44. Monitoring Rule Types (continued)
Rule Details (Bold and Italicized Text Indicates
Rule Type Configurable Parameters)
Conditionally Milestone If Order/Shipment meets a condition and has reached a
has reached before a date milestone n calendar hours before a date type, then raise a
monitor event.
Conditionally Milestone If Order/Shipment meets a condition and has reached a
has reached after a date milestone within n calendar hours of a date type, then raise a
monitor event.
Conditionally Milestone If Order/Shipment meets a condition and has reached a
has reached after another milestone within n calendar hours of a milestone, then raise a
Milestone monitor event.
Conditionally has been in a If Order/Shipment meets a condition and has been in a
status status for n calendar hours, then raise a monitor event.
Conditionally before a date If Order/Shipment meets a condition, raise a monitor event
n (or more) calendar hours before a date type.
Conditionally after a date If Order/Shipment meets a condition, raise a monitor event
n calendar hours after a date type.
Conditionally after a If Order/Shipment meets a condition, raise a monitor event
Milestone n calendar hours after a milestone.
Conditionally date before If Order/Shipment meets a condition and if a date type is
another date more than n calendar hours before a date type, then raise a
monitor event.
Conditionally date after If Order/Shipment meets a condition and if a date type is
another date more than n calendar hours after a date type, then raise a
monitor event.
Conditionally date within a If Order/Shipment meets a condition and if a date type is
specified time after another within n calendar hours after a date type, then raise a monitor
date event.
Conditionally date not If Order/Shipment meets a condition and if a date type is
within a specified time not within n calendar hours after a date type, then raise a
after another date monitor event.
Has been in Hold Type If Order/Shipment has been in a specified Hold Type with a
specified Hold Type Status for n calendar hours, then raise a
monitor event.
Conditionally has been in If Order/Shipment meets a condition and has been in a
Hold Type specified Hold Type with a specified Hold Type Status for n
calendar hours, then raise a monitor event.
Has been in Hold Type If Order/Shipment is in a specified Hold Type with a Hold
before a date Type Status with n calendar hours before a date, then raise a
monitor event.
Conditionally has been in If Order/Shipment meets a condition and is in a specified
Hold Type before a date Hold Type with a Hold Type Status with n calendar hours
before a date, then raise a monitor event.

Note: Hold-based monitoring rules can monitor holds that belong to the
organization owning the pipeline.

Monitoring Rule Configuration Example


According to your business practices, you need to monitor orders that have not
been released 24 hours before their requested shipment date and raise alerts for
such orders. Assuming that you have configured the necessary monitor rule

Chapter 4. Configuring Process Models 139


components, including milestones, date types, and alert consolidation rules, for the
process type you are working with, you can create a monitoring rule identifying
these parameters.

Using the "Milestone has not reached before a date" monitoring rule type, you can
configure the system to monitor when the Released milestone has not been reached
24 hours before an order’s requested shipment date.

Defining Transactions
Every process type has a set of base transactions defined for it. A transaction is a
logical unit of work that is necessary for performing activity within Sterling Selling
and Fulfillment FoundationSterling Application Platform. Base transactions are
predefined transactions that contain information about how the transaction
behaves, such as how many copies of a transaction can be kept in a process type
and whether or not it can have configurable base pick and drop statuses. Base
transactions can be used to create new transactions. These transactions can be
changed within the limits defined in the base transaction.

In Sterling Selling and Fulfillment FoundationSterling Application Platform, APIs


are used to run transactions. When an API is invoked, the transaction ID is
determined based on the context the API was run. The transaction ID identifies the
transaction to be run. Depending on the situation the transaction ID can be passed
as an input parameter or it can be predefined for the invoking API. For more
information about APIs, refer to the Sterling Selling and Fulfillment Foundation:
JavadocsJavadocs.

Some extended transactions that are created may require custom coding to
implement logic for the transaction. However, you can derive new transactions
from the abstract transactions provided by Sterling Selling and Fulfillment
FoundationSterling Application Platform. A transaction derived from an abstract
transaction contains specific details such as, statuses and triggering mechanisms
that do not require custom coding. For example, if you are configuring an order
document pipeline that requires several different types of order status change
transactions, you can derive multiple extended transactions from the Change Order
Status abstract transaction and configure them in your pipeline without requiring
custom coding.

Transactions can be classified as one or more of the following types:


v Externally-triggered
v User-triggered
v Time-triggered

Externally-Triggered Transactions

An externally-triggered transaction is performed through the Service Definition


Framework (asynchronous service) which calls a corresponding API within Sterling
Selling and Fulfillment FoundationSterling Application Platform to run the
transaction.

You can add an asynchronous service to a transaction as a reminder that that


service performs some processing around this transaction and that it is triggered
externally. For example, you can set up a service that puts a message in a queue,
which acts as a trigger. An asynchronous service then picks up this message from
the queue and does some processing. “Specifying a Transaction as
Externally-Triggered” on page 144 explains how to add a service that triggers a

140 Sterling Selling and Fulfillment Foundation: Application Platform Configuration Guide
transaction in the Externally Triggered tab.

User-Triggered Transactions

A user-triggered transaction is invoked manually through the Application


Consoles, a configured alert queue, or an e-mail service.

Time-Triggered Transactions

A time-triggered transaction is invoked on scheduled intervals. In Sterling Selling


and Fulfillment FoundationSterling Application Platform, a time-triggered
transaction is also called an agent.

Creating an Extended Transaction


About this task

You can create new custom transactions in the process type you are working with.
These transactions can then be used in pipeline creation and modification.

Note: When you are "creating" an extended transaction that is not derived from an
abstract transaction, you are creating a custom transaction for which software
development must be done separately before the extended transaction can be used
within a pipeline.

To create an extended transaction:

Procedure
1. In the Process Modeling window, select the Order, Load, or General tab to view
the corresponding process modeling tree for that base document type.
2. In the Process Types swimlane, right-click on the applicable process type and
choose Model Process. The Repository Details window and work area display
for the corresponding process type.
3. Choose the Transactions tab.

4. Select the Transactions branch and choose . The Create New Transaction
pop-up window displays.
5. Select ‘Do not derive from an abstract transaction' to create a new transaction
and associate your own logic with it.
6. Choose OK. The Transaction Detail window displays in the work area.
7. Enter information in the applicable fields. Refer to Table 45 on page 142 for
field value descriptions.

8. Choose .

Chapter 4. Configuring Process Models 141


Table 45. Transaction Details Window
Field Description
Transaction ID Enter the transaction ID.
Note: The document type and ‘.ex' are automatically
appended to the transaction ID of transactions you create.
Transaction Name Enter the transaction's name.
Externally Triggered The Externally Triggered tab provides an interface to set up
an externally-triggered transaction. For more information
about setting up an externally-triggered transaction, see
“Specifying a Transaction as Externally-Triggered” on page
144.
Time Triggered The Time Triggered tab provides an interface to set up a
time-triggered transaction. For more information about setting
up a time-triggered transaction, see “Specifying a Transaction
as Time-Triggered” on page 145.
User Triggered The User Triggered tab provides an interface to set up a
user-triggered transaction. For more information about setting
up a user-triggered transaction, see “Specifying a Transaction
as User-Triggered” on page 152.
Other

142 Sterling Selling and Fulfillment Foundation: Application Platform Configuration Guide
Table 45. Transaction Details Window (continued)
Field Description
This transaction is task Select this field if your transaction is triggered by a task
based queue. This indicates that whenever the previous transaction
in the pipeline completes its functions, the system creates a
task in the task queue table for this transaction.

Important: If this field is selected and the transaction is not


identified as a time-triggered transaction, task queue entries
are not created.
Works Based On Select the order level for which the transaction is used (for
example, order or order release).
Note: This field is disabled for inherited transactions.
Spawns another process? Select this field if the transaction spawns another system
process.
Spawning process type If you chose ‘Spawns another process?', select the process
type the transaction spawns.
Chained Document Type If a chained order is created from this transaction, enter the
document type of the chained order that is created. For
example, Sales Order or Purchase Order.
Derived Document Type If a derived order is created from this transaction, enter the
document type of the derived order that is created. For
example, Return Order or Exchange Order.
Operation Level Select the operation level to be assigned to the transaction
from the drop-down list. The values in the drop-down list are
common codes associated with the code type =
"OPERATION_LEVEL". You can use the Operation Level
value to categorize transactions in the pipeline.
Note: The operation level is applicable only for derived
transactions. For non-derived (new) transactions, the
Operation Level field is disabled.
This Transaction Is Derived Indicates if the transaction is derived from a base transaction.
From Abstract
Base Transaction Name If the transaction is derived from a base transaction, the name
of the base transaction displays.
This Transaction Can Be Check this if you want this transaction to be hold type
Stopped From Processing enabled. A hold type enabled transaction can be configured to
Orders That Are On Hold be stopped from processing orders that are on placed on a
particular hold type.

This flag cannot be modified for system defined transactions,


but can be set for all custom transactions that are not derived
from an abstract transaction.
Events An event is a specific occurrence in the business process,
often creating a status change or generated alert. When an
event occurs in a transaction an action is triggered.

The Events tab provides an interface to set up events and


event handlers. For more information about events and event
handlers, see “Adding an Event to a Transaction” on page
153 and “Defining Event Handlers” on page 155.

Chapter 4. Configuring Process Models 143


Table 45. Transaction Details Window (continued)
Field Description
Supports Transaction Check this box if you want to support dependency for this
Dependency transaction. For more information about creating transaction
dependency groups and any associated rules, see the Sterling
Selling and Fulfillment Foundation: Distributed Order
Management Configuration Guide.
Supports Transaction Check this box if you want to support transaction completion.
Completion For more information about configuring transaction
completion for extended or custom transactions, see
“Configuring a Transaction Completion” on page 157.
Operation Level Select the operation level for which the transaction is used.
You can select either header level or line level. For
information about configuring header-level or line-level
operations for quote pipeline transactions, see “Configuring
Header-Level and Line-Level Operations for Quote Pipeline
Transactions” on page 165.
Pickup Statuses The Pickup Statuses tab provides an interface to set up
pickup statuses. For more information about pickup statuses,
see “Adding a Pickup Status to an Extended Transaction” on
page 155.
Drop Statuses The Drop Statuses tab provides an interface to set up drop
statuses. For more information about pickup statuses, see
“Adding a Drop Status to an Extended Transaction” on page
156.

Specifying a Transaction as Externally-Triggered:


About this task

To create an externally-triggered extended transaction:

Procedure
1. From the Transaction Details window, choose the Externally Triggered tab.

2. Check ‘This transaction is triggered from external systems' to indicate that this
in an externally-triggered transaction.
3. From the Services Triggering This Transaction list, choose . The Service List
pop-up window displays.

144 Sterling Selling and Fulfillment Foundation: Application Platform Configuration Guide
4. Select the services that trigger the transaction and choose . The services are
added to the Services Triggering This Transaction list.
5. Continue to enter information in the applicable transaction fields. Refer to
Table 45 on page 142 for field level descriptions.

6. Choose .

Specifying a Transaction as Time-Triggered:


About this task

You can set up a transaction to be triggered by the Sterling Selling and Fulfillment
FoundationSterling Application Platform agents. For detailed information about
time-triggered transactions, see Appendix A "Time-Triggered Transaction
Reference".

Note: If you are creating a time-triggered transaction for a derived transaction,


please observe that agent criteria data is not automatically populated and must be
created.

To create a time-triggered extended transaction:

Procedure
1. From the Transaction Details window, choose the Time Triggered tab.

Chapter 4. Configuring Process Models 145


2. Check ‘This transaction is time triggered' to indicate that this in a
time-triggered transaction.
3. In Java Class, enter the agent class that you want to handle agent messages.

4. From the Agent Criteria table, choose . The Agent Criteria pop-up window
displays.
5. Enter information in the applicable fields. Refer to Table 46 for field level
descriptions.

Table 46. Time-Triggered Transaction Runtime Properties


Control Description
Runtime Properties
Agent Server The server on which this instance of the transaction is to be
run. To add new Agent Servers, click the Add Servers button
next to this field. This is a parameter used to start the agent
server. For more information about this parameter, see the
Sterling Selling and Fulfillment Foundation: Installation Guide.
Alert Queue Name The name of the alert queue.
JMS Queue Name The name of the JMS queue that contains messages to be
processed by this transaction.
No. of Threads The number of concurrent threads with which this transaction
should be run.

146 Sterling Selling and Fulfillment Foundation: Application Platform Configuration Guide
Table 46. Time-Triggered Transaction Runtime Properties (continued)
Control Description
Initial Context Factory The class providing an Initial Context implementation for
your application server to enable remote Java clients to
connect.

Select WebSphere® MQ if you are using MQSeries® accessed


through a IBM WebSphere IIOP URL. This sets the class name
to: com.ibm.websphere.naming.WsnInitialContextFactory.

Select File if you are using MQSeries accessed through a file


URL, as with Oracle WebLogic. This sets the class name to
com.sun.jndi.fscontext.RefFSContextFactory.

Select WebLogic if you are using Oracle WebLogic JMS. This


sets the class name to
weblogic.jndi.WLInitialContextFactory.

Select Jboss if you are using JBoss JMS. This sets the class
name to org.jnp.interfaces.NamingContextFactory.

If you defined an initial context factory code for ActiveMQ,


select the entry you created for it. For more information about
setting up other JMS vendors, such as ActiveMQ, which are
not included in the default set, see Section A.2 "Configuring
Communication Between an Agent and a JMS Server".
Note: You can override this value by configuring the
yfs.agent.override.icf property in the <INSTALL_DIR>/
properties/customer_overrides.properties file. For
additional information about overriding properties using the
customer_overrides.properties file, see the Sterling Selling
and Fulfillment Foundation: Properties Guide.
Note: You can configure your own initial context factory
settings to be used here. For more information about defining
initial context factory codes, see “Defining Initial Context
Factory Codes” on page 234.
QCF Lookup The name of the queue connection factory. This name
corresponds with a JMS connection factory configured in the
application server cluster running Sterling Selling and
Fulfillment FoundationSterling Application Platform.
Note: You can override this value by configuring the
yfs.agent.override.qcf property in the <INSTALL_DIR>/
properties/customer_overrides.properties file.

For additional information about overriding properties using


the customer_overrides.properties file, see the Sterling
Selling and Fulfillment Foundation: Properties Guide.

Chapter 4. Configuring Process Models 147


Table 46. Time-Triggered Transaction Runtime Properties (continued)
Control Description
Provider URL The URL containing the protocol and address used to access
the JMS queue.

If you use Oracle WebLogic JMS, enter the following value:


t3://<IP address and port of the WLS instance>

If you use MQSeries through a JNDI file, enter the following


value:
file://<pathname>

For example, if the path to the .bindings file is


/home/yantra/MQ_HSmith/java/jndi, use:
file:///home/yantra/MQ_HSmith/java/jndi

If you use MQSeries through IBM WebSphere JNDI, enter the


following value:
corbaloc::<DNS server name or IP
address>:<bootstrapport>

If you use JBoss JMS, enter the following value:

jnp://<IP address and port of the JBoss instance>


Note: You can override this value by configuring the
yfs.agent.override.providerurl property in the
<INSTALL_DIR>/properties/customer_overrides.properties
file.

The Provider URL format is:

t3://<ip Address>:<port>

For additional information about overriding properties using


the customer_overrides.properties file, see the Sterling
Selling and Fulfillment Foundation: Properties Guide.
Enable JMS Security Check this box if you want JMS Security to be enabled. Once
selected, the JMS Security Parameters tab is enabled to
configure Queue and/or JNDI based JMS security.
Note: Oracle WebLogic 10.3 only supports JNDI based JMS
security. If queue based security is enabled, it is altogether
bypassed. Therefore, you must configure JNDI based JMS
security if using Oracle WebLogic 10.3.
Note: You can override this value by configuring the
yfs.agent.override.auth.enabled property in the
<INSTALL_DIR>/properties/customer_overrides.properties
file.

For additional information about overriding properties using


the customer_overrides.properties file, see the Sterling Selling
and Fulfillment Foundation: Properties Guide.
Schedule Trigger Message Check this box to configure the agent to run the agent trigger
periodically from within the Agent Server during runtime.

When there are no messages for the agent to process, a new


trigger message is sent to the agent at specified time
intervals.
Schedule Trigger Message Enter the desired time interval in minutes.
Interval (Min)

148 Sterling Selling and Fulfillment Foundation: Application Platform Configuration Guide
Table 46. Time-Triggered Transaction Runtime Properties (continued)
Control Description
Service to Execute on Enter the service to be run upon completing the execution of
Completion of Work the selected agent. You can select the required service by
using the button.
Note: In case of agent implementations that extend
AbstractPurgeAgent or AbstractEnterpriseAgent, which
performs multi level GET for configured agent criteria, the
completion of work service will get executed for each of the
GET calls that results in execute messages. In this case, the
completion of work just indicates the completion of work for
that criteria or GET operation.
Criteria Parameters
Parameter Name The name of parameter sent to the transaction. This is a
parameter used to trigger the transaction, for more
information about this parameter, see "Time-Triggered
Transaction Reference".
Parameter Value The value of the parameter sent to the transaction. For valid
names and parameters, see "Time-Triggered Transaction
Reference".
JMS Security Properties Tab

This is enabled upon selecting Enable JMS Security in the runtime properties tab. You can
override the JMS security properties specified here by enabling the agent and flow
authorization parameters in yfs.properties.
Note: You can override the JMS security parameters (userid and password) by configuring
the following parameters in the <INSTALL_DIR>/properties/
customer_overrides.properties file:
yfs.agent.override.auth.userid
yfs.agent.override.auth.password

For additional information about overriding properties using the


customer_overrides.properties file, see the Sterling Selling and Fulfillment Foundation:
Properties Guide.

For more information about the application server-specific security mechanisms, see Setting
up the JMS Security Properties.
Parameter Name Enter the name of the security parameter.
Parameter Value Enter the value of the security parameter.

6. Choose .
7. Continue to enter information in the applicable transaction fields. Refer to
Table 45 on page 142 for field level descriptions.
8. Choose .
9. Restart the appropriate Agent Servers for the changes to take effect.

Setting up the JMS Security Properties: Based on your application server, you also
need to pass the name-value pairs for user authentication.

Queue Based Security and/or JNDI Based Security:

Chapter 4. Configuring Process Models 149


About this task

For Oracle WebLogic, IBM WebSphere and IBM WebSphere MQ, and JBoss, specify
the following name-value pairs in the parameter name and values explained in
Table 46 on page 146:
v For Queue Based Security set the following parameters:
– sci.queuebasedsecurity.userid=<username configured in the
APPLICATION_SERVER and assigned to the queue>
– sci.queuebasedsecurity.password=<password for the above username as
configured for the APPLICATION_SERVER

Note: Oracle WebLogic 10.3 only supports JNDI based JMS security. If queue
based security is enabled, it is altogether bypassed. Therefore, you must
configure JNDI based JMS security if using Oracle WebLogic 10.3.

Note: JBoss does not support queue based security for JMS service. Only
JNDI based security is supported.
v For JNDI Based security set the following parameters:
– java.naming.security.principal=<user ID configured in the
APPLICATION_SERVER and assigned to the JNDI>
– java.naming.security.credentials=<password for the above user ID as
configured for the APPLICATION_SERVER>

Note: For more information about the authentication mechanism, setting up


queues and QCF, refer to individual Application Server's documentation.

For IBM WebSphere and IBM WebSphere MQ, set up the desired forms of
authentication and encryption where appropriate. Additionally, modify the java
commands as described below to suit the desired goal.

Before modifying, ensure that you have defined the following variables in your
environment:
v WAS_HOME refer to the installation directory of the IBM WebSphere software
v MQ_HOME refers to the installation location of the IBM WebSphere MQ
software.
v PROFILE_NAME refers to the name of the profile in which you created the
server.
v To allow agents to be authenticated to IBM WebSphere JNDI, add the following
definitions:
– -Djava.ext.dirs=<CLASSPATH>, where the CLASSPATH should contain the
following directories:
- $MQ_HOME\java\lib
- $WAS_HOME\AppServer\java\jre\lib\ext
- $WAS_HOME\AppServer\java\jre\lib
- $WAS_HOME\AppServer\lib
- $WAS_HOME\AppServer\lib\ext
- $WAS_HOME\AppServer\properties
- $WAS_HOME\AppServer\profiles\<PROFILE_NAME>\properties.
– com.ibm.CORBA.ConfigURL should be set to the full path to the sas props file
that you want to use such as -Dcom.ibm.CORBA.ConfigURL=$WAS_HOME/
AppServer/profiles/<PROFILE_NAME>/properties/sas.client.props.

150 Sterling Selling and Fulfillment Foundation: Application Platform Configuration Guide
The SAS props file is obtained from the IBM WebSphere installation. You
need to modify this text file to contain the username and password to be used
for authentication to the IBM WebSphere (corbaloc based) JNDI.

Note: For more information about how to set any of the above mentioned
defines refer to IBM documentation. In specific, read the IBM WebSphere
documentation to understand how to enable and configure Global security.
v To enable SSL encryption on the transmission of JMS messages to MQ, enable
SSL on the channel to which your agents and services are connected. Create the
QCF using the equivalent SSLCIPHERSPEC. On the java command line specify
the following definitions:
– javax.net.ssl.trustStore
– javax.net.ssl.keyStorePassword
– javax.net.ssl.KeyStore

Note: Refer to the IBM WebSphere MQ documentation to learn how to turn


on the SSL on the server channel to which the Sterling Selling and Fulfillment
FoundationSterling Application Platform agents and services connect. For
more information about how to use the SSLCIPHERSPEC option while
creating the QCF, see the IBM documentation.

For JBoss, before modifying, ensure that you have added following jars to the
CLASSPATH:
v JBOSS_HOME refer to the installation directory of the JBoss software
v To allow agents to be authenticated to JBoss JNDI, add the following definitions:
– -Djava.ext.dirs=<CLASSPATH>, where the CLASSPATH should contain the
following directories:
- <JBOSS_HOME>/client/jbossall-client.jar
- <JBOSS_HOME>/server/<server-home>/jboss-aop-jdk50.deployer/jboss-
aop-jdk50.jar
- <JBOSS_HOME>/jboss-messaging-client.jar

Adding a New Server:


About this task

You can add a new server from the Agent Criteria Details screen or from the
Service Definition Framework. This screen provides the options for you to
terminate the server on completing the task.

For example, in a once a day wave release scenario, the orders are downloaded
through an integration server, waves are created and batched, pick locations are
assigned, waves are released and printed in multiple servers. This may take an
hour or more to process, but once completed the servers are idle and waiting until
the next day. Even though the processes are idle, they consume valuable resources
like memory and CPU upon the server.

To avoid this idle time, you can configure the server to terminate automatically. To
achieve this you can specify certain options in the Server Details upon creation as
described in the following table.

Chapter 4. Configuring Process Models 151


Table 47. Server Details
Field Description
Server Properties Tab
Server Name Enter the name of the server.
Terminate Server on Idle Select this option if you want to terminate the server when
the task is completed or when idle.

Once this option is selected the next two fields are enabled.
Startup Delay for Enter the monitor start time. This is to ensure that the server
Termination Monitor does not terminate before it has completed one successful
(minutes) execution.
Termination Monitor Enter the idle wait time before terminating the server.
Interval (minutes)
Sub Service List Tab
Subflow Name or Criteria Lists the name of the subflow or the criteria belonging to the
ID configured service or agent.
Threads Specifies the number of threads.

Click upon entering the details.

Once the server which has been configured to terminate is started, it monitors the
threads to check if they are idle. The monitor start time indicates the time the
number of minutes delay before it starts. Once all the threads are idle, the server
waits the configured amount of time before terminating. If a new message comes
in, the time is reset and the server again starts monitoring the threads.

Specifying a Transaction as User-Triggered:


About this task

You can create a transaction that is triggered by the user.

To create a user-triggered extended transaction:

Procedure
1. From the Transaction Details window, choose the User Triggered tab.

152 Sterling Selling and Fulfillment Foundation: Application Platform Configuration Guide
2. Check ‘This transaction is triggered by Users' to indicate that this a
user-triggered transaction.
3. From ‘When ready, notify user using', select the service that should be triggered
when a document enters this transaction's pick-up status. For example, if all
orders created for a particular order type need to be verified by a customer
service representative when an order is created, you can create a user-triggered
transaction that invokes a service that sends an e-mail to the representative that
verifies the order.

Note: You must select the applicable transaction order level from the Works
Based On field on the Others tab for user notification to occur. For example, if
you are configuring a transaction that is triggered by the user at the order
release level, you must select Process Task Type for Order Release from the
Works Based On drop-down.
4. Continue to enter information in the applicable transaction fields. Refer to
Table 45 on page 142 for field value descriptions.

5. Choose .

Adding an Event to a Transaction:


About this task

You can add events to transactions. These events signify occurrences in the process
type's workflow and call associated actions.

To add an event to a transaction:

Procedure
1. From the Transaction Detail window, choose the Events tab.

2. Choose . The Event Details pop-up window displays.


3. Enter information in the applicable fields. Refer to Table 48 on page 154 for
field level descriptions.
4. Choose OK.

Chapter 4. Configuring Process Models 153


Table 48. Event Details Pop-Up Window
Field Description
Event ID Enter the event ID.
Event Name Enter the event's name.
Is Active? Select this field if the event is active for the transaction.

Leave this field unselected to deactivate the event.


Can Enterprise Configure If you are logged in as a Hub role, select this field if you
Event Handler? want to allow Enterprise roles to be able to configure event
handlers for the transaction.
Note: If the transaction works across multiple enterprises or
enterprise information is not available to the transaction, the
default event handler is used.
Requires Backward Select this field if the event handler contains properties that
Compatibility require backward compatibility. If you select this field, choose
the applicable version.

Modifying an Extended Transaction's Event:


About this task

To modify a transaction's event:

Procedure
1. From the Transaction Detail window, choose the Events tab.

2. Select the applicable event and choose . The Event Details pop-up window
displays.
3. Modify information in the applicable fields. Refer to Table 48 for field value
descriptions.
4. Choose OK.

Deleting an Event from a Transaction:


About this task

To delete an event from a transaction:

154 Sterling Selling and Fulfillment Foundation: Application Platform Configuration Guide
Procedure
1. From the Transaction Detail window, choose the Events tab.

2. Select the applicable event and choose .

Defining Event Handlers:


About this task

You can define event handlers that determine the types of actions that are
performed when an event in a transaction occurs. You can provide conditions that
apply to the event handler.

Note: Event handlers defined for a transaction in a particular pipeline are also
applicable if the same transaction is used in another pipeline.

Note: When associating a condition with an event, refer to the Sterling Selling and
Fulfillment Foundation: JavadocsJavadocs to ensure that the applicable condition
variables coincide with the event's key data and data published.

To set up event handlers:

Procedure
1. From the Transaction Detail window, choose the Events tab.
2. Select the applicable event and choose the Configure Event Handler button.
The Event Handler Definition work area activates.

3. Drag the applicable actions and conditions into the work area and connect
them as per the rules detailed in this section.

4. Choose .

Adding a Pickup Status to an Extended Transaction:


About this task

You can add a pickup statuses to extended transactions. A pickup status pulls the
document from the preceding drop status and brings it into the transaction.

Note: While you cannot add pickup statuses or drop statuses to a system
transaction, you can use an extended status as a pickup or drop status as long as
its base status is included in the transaction's pickup or drop statuses.

Chapter 4. Configuring Process Models 155


To add a pickup status to a transaction:

Procedure
1. From the Transaction Detail window, choose the Pickup Statuses tab.

2. Choose . The Select Status pop-up window displays.

Note: If the transaction has been derived from an abstract transaction, the
pickup statuses populating the list are determined by the pickup status filter as
defined in the derived transaction's base transaction.
3. Select the pickup status you want to add to the transaction.
4. Choose OK.

Deleting a Pickup Status from a Transaction:


About this task

To delete a pickup status from a transaction:

Procedure
1. From the Transaction Detail window, choose the Pickup Statuses tab.

2. Select the applicable pickup status and choose .

Note: You cannot delete an extended transaction's pickup status if it is the


transaction's only pickup status and drop statuses exist for the transaction.

Adding a Drop Status to an Extended Transaction:


About this task

You can add drop statuses to extended transactions. This status moves the
document from the current transaction to the next transaction's pickup status.

Note: While you cannot add pickup statuses or drop statuses to a system
transaction, you can use an extended status as a pickup or drop status as long as
its base status is included in the transaction's pickup or drop statuses.

To add a drop status to a transaction:

156 Sterling Selling and Fulfillment Foundation: Application Platform Configuration Guide
Procedure
1. From the Transaction Detail window, choose the Drop Statuses tab.

2. Choose . The Select Status pop-up window displays.

Note: If the transaction has been derived from an abstract transaction, the drop
statuses populating the list are determined by the drop status filter as defined
in the derived transaction's base transaction.
3. Select the drop status you want to add to the transaction.
4. Choose OK.

Deleting a Drop Status from a Transaction:


About this task

To delete a drop status from a transaction:

Procedure
1. From the Transaction Detail window, choose the Drop Statuses tab.

2. Select the applicable drop status and choose .

Configuring a Transaction Completion: You can configure the transactions to be


completed based on an order line status in the order fulfillment process type. The
completion criteria can be defined only for custom or extended transactions. When
an order runs these transactions, it is evaluated for completion. Upon evaluation
the transaction it is marked as complete or incomplete as defined in the transaction
completion criteria. This configuration provides you the flexibility to set up
completion dependencies for transaction-based on its drop statuses.

Note: You cannot configure transaction completion for the standard transactions
provided by Sterling Selling and Fulfillment FoundationSterling Application
Platform. For example, you cannot configure completion for the standard Schedule
transaction.

Note: However, some of the status-based transactions such as Schedule and


Release are provided with completion criteria and can be viewed by selecting
in the drop status tab.

Chapter 4. Configuring Process Models 157


Apart from transactions, completion criteria can also be configured for the
extended listeners used in the pipeline. However, you need to configure the
completion for every instance of the listener.

For more information about the concepts of transaction dependencies, see the
Sterling Selling and Fulfillment Foundation: Product Concepts Guide. For information
about configuring transaction dependencies for the order fulfillment model, see the
Sterling Selling and Fulfillment Foundation: Distributed Order Management
Configuration Guide.

Configuring the Transaction Completion Setup:


About this task

To configure the transaction completion setup:

Procedure
1. From the Transaction Detail window, choose the Drop Statuses tab.
2. Choose to configure the transaction completion. The Transaction
Completion window displays.
3. Enter information into the applicable fields. Refer to the following table for
field value descriptions.
4. After entering the details choose OK.
Table 49. Transaction Completion Configuration Details
Field Description
Configure Transaction Check this box if you want to configure the transaction
Completion For Order Line completion based on an order line status.
Transaction is Marked As Complete When

158 Sterling Selling and Fulfillment Foundation: Application Platform Configuration Guide
Table 49. Transaction Completion Configuration Details (continued)
Field Description
All Quantity Are In or Select this option if you want to configure the transaction
Beyond the Status when the order line is beyond the status specified in the
drop-down.

The transaction is considered incomplete if any quantity is


below the status that is configured.
Transaction is Marked as Select the transaction completion status from the drop-down
Complete When All option. The drop down list all statuses defined for that
Quantities Are In the
organizations. Use the icon to select from a list of
Following Statuses
available drop statuses.
Transaction is Marked as Select the status from the drop-down for which the
Incomplete When Any
transaction is considered incomplete. Use the icon to
Quantity Is in Any of the
select the status from the list of available statuses.
Following Statuses

Results

For deleting the chosen statuses for the completion or incompletion of the
transaction, choose the appropriate status and click .

TRANSACTION_DEPENDENCY.READY_TO_PROCESS event is triggered when


the transaction is completed to notify the user that the order is ready to process the
dependent transaction. This event also enables custom transactions to know that
the order is ready for processing.

Note: The READY_TO_PROCESS event is triggered only when a transaction is


ready for immediate processing.

You can have multiple transactions that could become ready due to the completion
of one transaction. In this case, each transaction is output along with the order
lines that are available.

The lines that become available due to dependency removal are published in the
event.

Managing a Base Transaction's User Exits:


About this task

User exits are Java interfaces which can be implemented for creating custom logic
components. Once implemented, they must be configured so that the Sterling
Selling and Fulfillment FoundationSterling Application Platform transactions can
invoke them to perform the necessary logic at runtime.

To manage a base transaction's user exits:

Procedure
1. From the Transaction Detail window, choose the User Exits tab.

Chapter 4. Configuring Process Models 159


If the user exit can be implemented for a document type, the ‘Can Override For
Document Types' column displays ‘Y'. If the user exit can be implemented for
services, the ‘Can Attach Service' column displays ‘Y'. If the user exit is
implemented, the ‘User Exit Implemented' column displays ‘Y'.

Note: The User Exit List may not display the complete list of user exits
available for the transaction. To view the complete list of available user exits,
use the User Exit Management Console.

2. Locate the applicable user exit and choose . The User Exit Details window
displays.

160 Sterling Selling and Fulfillment Foundation: Application Platform Configuration Guide
3. From the User Exit Implementation List table, choose . User Exit
Implementation Details displays.
4. Enter information into the applicable fields. Refer to Table 50 on page 162 for
field value descriptions.

Chapter 4. Configuring Process Models 161


Table 50. User Exit Implementation Details Fields
Field Description
User Exit Implementation Details
Document Type If the user exit can be implemented for a document type,
select the appropriate document type, if applicable.
Implement As A Service If the user exit can be implemented to use a service and you
are configuring it as such, choose Implement As A Service.
Implement As A Java Class If you are configuring the user exit to be implemented as a
Java class, choose Implement As A Java Class.
Service Name (if selected If you selected Implement As A Service, select the applicable
Implement as Service) service to configure.
Java Class (if selected If you selected Implement As A Java Class, enter the Java
Implement as Java Class) class as it displays in the User Exit Name field.
Requires Backward Select this field if the user exit requires backward
Compatibility compatibility for another release.
Version If you selected Requires Backward Compatibility, select the
Sterling Selling and Fulfillment FoundationSterling
Application Platform version number that requires user exit
backward compatibility.
Restrict Number Of Calls If a call made to the external system through the User exit
custom code hangs, the API thread, which invoked this
user-exit, also hangs. Potentially this could block out all the
execute threads in an App server. If checked, you can
configure Calls Per JVM, Waiting Calls and Wait time.
Pool Size Indicates total number of concurrent active calls to User Exit.

162 Sterling Selling and Fulfillment Foundation: Application Platform Configuration Guide
Table 50. User Exit Implementation Details Fields (continued)
Field Description
Maximum Queue Length The maximum queue length for the number of user exit calls
that are waiting to become active if the active count is filled
up. If the queue is filled with calls waiting to be active, any
new User Exit requests cause an error.
Wait Time (seconds) Time for which the user exit call waits in queue. If the wait
time exceeds the configured wait time, an exception is
thrown.
User Exit Implementation Enter any additional information regarding user exit
Notes implementation.

Creating an Extended Transaction that is Derived from an


Abstract Transaction
About this task

You can create new transactions by deriving from existing system transactions in
the process type you are working in. These transactions can then be used in
pipeline creation and modification.

Note: When creating a transaction that is derived from an abstract transaction,


completing the document field type is not mandatory, but is recommended.

To create a derived transaction:

Procedure
1. In the Process Modeling window, select the Order, Load, or General tab to view
the corresponding process modeling tree for that base document type.
2. In the Process Types swimlane, right-click on the applicable process type and
choose Model Process. The Repository Details window and work area display
for the corresponding process type.
3. Choose the Transactions tab.

4. Select the Transactions branch and choose . The Create New Transaction
pop-up window displays.
5. Select ‘Derive from this abstract transaction' and select the applicable
transaction to build a derived transaction off of.
6. Choose OK. The Transaction Detail window displays in the work area.
7. Enter information in the applicable fields. Refer to Table 45 on page 142 for
field value descriptions.

8. Choose .
9. If you modified the Java class, restart the appropriate Agent Servers for the
changes to take effect.

Creating a Status Change Listener Derived Transaction:


About this task

You can create listener transactions to keep track of the changes in a document
when it is in another pipeline. For example, if you are creating an order fulfillment
pipeline in which the order document is dropped into an outbound shipment
pipeline with its own set of statuses for shipment, you can configure a status

Chapter 4. Configuring Process Models 163


change listener transaction in the order fulfillment pipeline to keep track of the
statuses the order document goes through in the outbound shipment pipeline.

The transaction details screen for a listener allows multiple drop statuses to be
added. A validation is performed to prevent the removal of a transaction drop
status record if there is a pipeline listener record for that drop status. When setting
the statuses listened to in the pipeline, specify which drop status to use for each
listened to status. When a child order changes status, the parent order is updated
with the specific drop status for the status to which the child order has just
changed.

This listener listens to all the same statuses as the previous three listeners
combined and drops into whichever drop status that the previous three listeners
did.

Listeners that change status on an order raise an event upon status change.
Listeners raise the event for each order line that has a status change. The
ON_STATUS_CHANGE event is raised for each order line using the Listener
transaction.

To configure a status change listener:

Procedure
1. In the Process Modeling window, select the Order, Load, or General tab to
view the corresponding process modeling tree for that base document type.
2. In the Process Types swimlane, right-click on the applicable process type and
choose Model Process. The Repository Details window and work area display
for the corresponding process type.
3. Choose the Transactions tab.

4. Select the Transactions branch and choose . The Create New Transaction
pop-up window displays.
5. Select ‘Derive from this abstract transaction' and select the applicable listener
transaction.
6. Choose OK.
7. In the repository, choose the pipeline tab and then select the pipeline you
want to add the status change listener transaction to. Right-click on the
pipeline and choose Details. The details of that pipeline appear in the work
area.
8. Choose the transactions tab and drag your transaction into the appropriate
spot in the work area.
9. Right-click on the status change listener transaction and choose Show Listener
Details. The Listener Details pop-up window displays.

164 Sterling Selling and Fulfillment Foundation: Application Platform Configuration Guide
10. From Process Type Listening To, select the applicable process type pipeline
from which you want the listener to track statuses.

11. From the Status Listening To list, select . A list of statuses that can be
tracked displays.
12. Select the statuses you want the listener to track and choose .
13. Choose OK.

Note: Work Order Status Listeners do not work on provided service or


delivery service work orders.

Configuring Header-Level and Line-Level Operations for Quote Pipeline


Transactions:
About this task

You can configure whether transactions occur at the line level or the header level
of quotes. If a transaction operates at the header level, the status move on all the
quote lines occurs only if all lines are permitted to move. If a transaction operates
at the line level, any line status can be moved, independent of other line statuses
in the quote.

To configure whether transactions occur at the line level or the header level of
quotes:

Procedure
1. In the Process Modeling window, select the Order tab to view the Quote
process modeling tree for the Order base document type.
2. In the Process Types swimlane, right-click on Quote Fulfillment and choose
Model Process. The Repository Details window and work area display for the
Quote process type.
3. Choose the Transactions tab.

Chapter 4. Configuring Process Models 165


4. Select the Transactions branch and choose . The Create New Transaction
pop-up window displays.
5. Select ‘Derive from this abstract transaction' and select the Change Order Status
transaction to build a derived transaction off of.
6. Choose OK. The Transaction Detail window displays in the work area.
7. Choose the Others tab. Refer to Table 45 on page 142 for field value
descriptions.
8. From the Operation Level drop-down list, select either:
v Transaction Operation Level of Header
v Transaction Operation Level of Line

9. Choose .

Modifying a Transaction
About this task

To modify a transaction:

Procedure
1. In the Process Modeling window, select the Order, Load, or General tab to view
the corresponding process modeling tree for that base document type.
2. In the Process Types swimlane, right-click on the applicable process type and
choose Model Process. The Repository Details window and work area display
for the corresponding process type.
3. Choose the Transactions tab.
4. Expand the Transactions branch.

5. Select the applicable transaction and choose . The Transaction Details


window displays in the work area.
6. Modify information in the applicable fields. Refer to Table 45 on page 142 for
field value descriptions.

7. Choose .

Deleting a Transaction
About this task

To delete a transaction:

Procedure
1. In the Process Modeling window, select the Order, Load, or General tab to view
the corresponding process modeling tree for that base document type.
2. In the Process Types swimlane, right-click on the applicable process type and
choose Model Process. The Repository Details window and work area display
for the corresponding process type.
3. Choose the Transactions tab.
4. Expand the Transactions branch.

5. Select the applicable transaction and choose .

Note: If a transaction existing in any pipeline is deleted, it appears bright red


in the graphical pipeline.

166 Sterling Selling and Fulfillment Foundation: Application Platform Configuration Guide
Defining Statuses
Statuses are the actual states that a document moves through in the pipeline. A
transaction can contain two types of statuses, a drop status and a pickup status. A
document is moved into a drop status when the events and conditions of a
transaction have been completed. A pickup status takes the document from the
previous drop status and moves it through the next transaction. Created and
Scheduled are examples of statuses.

Sterling Selling and Fulfillment FoundationSterling Application Platform provides


a default set of statuses. These statuses are used to connect transactions. Your
business practices may call for use of one or more extended statuses. These
statuses do not stand alone and only follow the status from which they are
extended.

Creating an Extended Status


About this task

To create an extended status:

Procedure
1. In the Process Modeling window, select the Order, Load, or General tab to view
the corresponding process modeling tree for that base document type.
2. In the Process Types swimlane, right-click on the applicable process type and
choose Model Process. The Repository Details window and work area display
for the corresponding process type.
3. Choose the Statuses Tab.
4. Expand the Statuses branch.

5. Select the applicable status and choose . The Status Detail window displays
in the work area.

Chapter 4. Configuring Process Models 167


6. In Status, enter the extension number. This number must be sequential with
any other existing extended statuses.
7. In Status Name, enter the name of the extended status.

8. Choose .

Modifying an Extended Status


About this task

To modify an extended status:

Procedure
1. In the Process Modeling window, select the Order, Load, or General tab to view
the corresponding process modeling tree for that base document type.
2. In the Process Types swimlane, right-click on the applicable process type and
choose Model Process. The Repository Details window and work area display
for the corresponding process type.
3. Choose the Statuses Tab.
4. Expand the Statuses branch.

5. Select the applicable extended status and choose . The Status Detail window
displays in the work area.

168 Sterling Selling and Fulfillment Foundation: Application Platform Configuration Guide
6. In Status Name, enter the name of the extended status.

7. Choose .

Deleting an Extended Status


About this task

To delete an extended status:

Procedure
1. In the Process Modeling window, select the Order, Load, or General tab to view
the corresponding process modeling tree for that base document type.
2. In the Process Types swimlane, right-click on the applicable process type and
choose Model Process. The Repository Details window and work area display
for the corresponding process type.
3. Choose the Statuses Tab.
4. Expand the Statuses branch.
5. Select the applicable extended status and choose .

Defining Status Monitoring Rule Definitions


About this task

A status monitoring rule is used to monitor business documents that stay in a


particular status for a set amount of time. When the configured time is reached the
actions you define in the status monitoring rule definition work area are
performed.

Note: The following setup for the status monitoring rule definition is for the order
monitor.

To set up status monitoring rule definitions:

Procedure
1. In the Process Modeling window, select the Order, Load, or General tab to view
the corresponding process modeling tree for that base document type.
2. In the Process Types swimlane, right-click on the applicable process type and
choose Model Process. The Repository Details window and work area display
for the corresponding process type.
3. Expand the Statuses branch.
4. Choose the Statuses Tab.
5. Double click the applicable Status. The Status Details window displays in the
work area.
6. Right-click in the work area and select Actions > Add Monitor Node. A monitor
node displays in the work area.
7. Drag the applicable actions and conditions into the work area and connect
them as per the rules detailed in this section.
8. Connect the status monitor node to the applicable actions. The hours that a
document stays in the status before the action is raised displays on the
connecting line. To change the time, right-click on the time, choose Change, and
enter the new time.

Note: Do not set up more than one action for the same monitoring age.

Chapter 4. Configuring Process Models 169


9. Choose .

Note: For the following process types, status monitoring rules cannot be
added, and the Status Monitor Rule Definition tab is therefore disabled:
v Count Execution
v General
v Load Execution
v Manifesting
v Move Request Execution
v Outbound Picking
v Outbound Shipment
v Over Pack Build
v Pack Process
v Purchase Order Receipt
v Return Receipt
v Task Execution
v Trailer Loading
v Transfer Order Receipt
v VAS Process
v WMS Layout Definition
v WMS Putaway
v WMS Inventory

Defining Conditions
A condition matches document type attributes against decision points and routes
the documents to different paths based on the specified attribute and value
combinations. The document type attributes against which conditions can be
created are predefined in Sterling Selling and Fulfillment FoundationSterling
Application Platform. You can use these attributes in any combination or you can
create conditions that run the appropriate application logic for specific
circumstances.

For example, at a certain point in a Sales Order Fulfillment process-type pipeline,


you set up a condition to determine if an order contains hazardous materials.
When an order reaches this condition in the pipeline, it cannot move any further
until the condition is met with a definitive ‘yes' or ‘no' value. In this example, if
the order contains no hazardous materials, the value is ‘no' and the order
continues through the regular pipeline. If the order does contain hazardous
material, the value is ‘yes' and the order is sent down an alternate branch of the
order pipeline that has been configured to deal with hazardous material orders.

Static Conditions

The behavior of a static condition differs between different flows (for example,
SDF, Pipeline, Pipeline Determination Rule, and Event Handlers) based on the data
that is available for condition evaluation.
v In SDF, the entire flow or input data is available for condition evaluation.
v In case of a Pipeline Determination Rule, only a limited set of published data
(per process type) is available for condition evaluation. For the complete list of

170 Sterling Selling and Fulfillment Foundation: Application Platform Configuration Guide
out-of-the-box process types, refer to Sterling Selling and Fulfillment Foundation:
Application Platform Configuration GuidePlatform Configuration Guide.
v In Pipeline or Events, only a limited set of published data (per entity or event) is
available for condition evaluation. For more information on Keydata of the
concerned event, refer to Sterling Selling and Fulfillment Foundation:
JavadocsJavadocs.
v The Enter your own attribute configuration is applicable only for unexposed key
attributes that are pre-defined by Sterling Selling and Fulfillment
FoundationSterling Application Platform as opposed to any XML attribute that
you can enter. Also, this configuration has limited visibility to the contextual
condition and hence it is not re-usable. When there is a need for re-usability
across conditions, extn_conditionbuilder.xml should be used which forces the
metadata for condition builder configurations.

Note: In a pipeline, a false node of a condition can be linked to another


condition whereas a true node cannot be linked to another condition.

Dynamic Conditions

Dynamic conditions provide complete visibility into the incoming flow data and
flexibility for evaluating any kind of simple or complex conditions.

Creating a Condition
About this task

To create a condition:

Procedure
1. In the Process Modeling window, select the Order, Load, or General tab to view
the corresponding process modeling tree for that base document type.
2. In the Process Types swimlane, right-click on the applicable process type and
choose Model Process. The Repository Details window and work area display
for the corresponding process type.
3. Choose the Conditions Tab.
4. Expand the Conditions branch.
5. Choose . The Condition Details window displays in the work area.
6. Enter information in the applicable fields. Refer to Table 51 on page 172 for
field level descriptions.

7. Choose .

Chapter 4. Configuring Process Models 171


Table 51. Condition Details Window
Field Description
Condition ID Enter the condition ID.
Condition Name Enter the name of the condition.
Condition Group Enter the name of the condition's group, if applicable.
Condition Group allows you to group related conditions
within the condition tree.
Static If this is checked you must enter a condition value for the
static condition.
Dynamic If this is checked you must enter a Java class name that
evaluates the condition at runtime.
AdvancedXML If you are creating a new condition, this option is disabled as
a new condition of the advanced XML type must be created
using the Sterling Greex Editor IDE tool. For more
information about creating an advanced XML condition using
the Sterling Greex Editor, see the Sterling Selling and
Fulfillment Foundation: Extending the Condition Builder.

This option is automatically selected whenever you modify a


condition of the advanced XML type.
Condition Value (if Static is Choose the Condition Builder button to use the condition
checked) builder. Here you can use the Condition Builder to set up the
condition value. You can set it up in a formulaic readout
using the available symbols.

You can enter your own attribute or an extended attribute if


Static condition is checked. For more information about
creating these attributes, see the Sterling Selling and Fulfillment
Foundation: Extending the Condition Builder.
Class Name (if Dynamic is Enter the class name that implements the following Java
checked) interface:
com.yantra.ycp.japi.YCPDynamicCondition

Note: To use extended attributes for a condition, implement


the YCPDynamicConditionEx interface. For more information
about implementing this interface, refer to the Sterling Selling
and Fulfillment Foundation: Extending the Condition Builder
Condition Properties (if Specify the custom name or value properties which are set
Dynamic is checked) into the condition evaluating java class file before evaluating
the condition. For more information about creating custom
attributes, see the Sterling Selling and Fulfillment Foundation:
Extending the Condition Builder.

Using the Condition Builder: You can use the condition builder to create
condition values. To use the condition builder you must first select the field(s) to
be analyzed when the condition is used and associate the proper value with them.

For example, you want to set up a condition to search for a specific node for order
fulfillment, in this example SN1. To set up this condition value, select Ship Node
from the list of available order fulfillment fields. From the drop down list select ‘Is’
and enter SN1 as the value and choose Add. You have now created a condition
value that reads "Ship Node is ‘SN1’". This indicates that when this condition is
used the application checks the document to see if it is associated with SN1, if it is
the document moves through the pipeline as per your configuration.

172 Sterling Selling and Fulfillment Foundation: Application Platform Configuration Guide
You can also check for conditions to be evaluated if they are greater than, greater
than equal to, less than, less than equal to and contains based on the fields you
have selected.

You can build more complex strings when creating a condition value using the
condition builder. For example, you decide that along with setting up a condition
value associated with SN1, you do not want the condition to include any item IDs
associated with Item1. To set up this condition value, select Ship Node from the
list of available order fulfillment fields. From the drop down list select ‘Is’ and
enter SN1 as the value and choose Add. Then select the statement and choose the
open and closed parentheses buttons. After this statement is set up, select Item ID
from the list of available order fulfillment rules. From the drop down list select
‘Not Equal To’ and enter Item1. Select the statement and choose the & button, then
choose the open and closed parentheses buttons. You have now set up a statement
to read "(Ship Node Is ‘SN1’) AND (Item ID Not Equal To ‘Item1’). This statement
indicates that when this condition is used, the application looks at a given
document to see if it is associated with SN1 but not Item1. If this is the case the
document goes along the pipeline as per your configuration.

Note: You must uses parentheses when using multiple fields in a condition
statement.

Note: You can only have two conditions between the bracket symbols.

You can add custom attributes by process types and during condition definition to
be evaluated as part of the condition builder functionalities. For more information
about implementing custom attributes and incorporating them in the condition
builder, see the Sterling Selling and Fulfillment Foundation: Extending the Condition
Builder.

Modifying a Condition
About this task

To modify a condition:

Procedure
1. In the Process Modeling window, select the Order, Load, or General tab to view
the corresponding process modeling tree for that base document type.
2. In the Process Types swimlane, right-click on the applicable process type and
choose Model Process. The Repository Details window and work area display
for the corresponding process type.
3. Choose the Conditions Tab.
4. Expand the Conditions branch.
5. Expand the applicable condition group branch.

6. Select the applicable condition and choose . The Condition Details window
displays in the work area.
7. Enter information in the applicable fields. Refer to Table 51 on page 172 the
Transaction Details Window table for field level descriptions. (Refer to “Using
the Condition Builder” on page 172 for information about modifying a static
condition). (Refer to Table 52 on page 174 for field level descriptions for an
advanced XML condition).

8. Choose .

Chapter 4. Configuring Process Models 173


Table 52. Advanced XML Condition Details Window
Field Description
Condition ID Enter the new identifier for the advanced XML condition (if
required).
Condition Name Enter the new name for the advanced XML condition (if
required).
Condition Group Enter the new name for the advanced XML condition's group
(if required). Condition Group allows you to group related
conditions within the condition tree.
Advanced XML (if This screen displays only when you are editing an advanced
AdvancedXML is checked) XML condition that is created using the Sterling Greex Editor
IDE tool. For more information about creating an advanced
XML condition using the Sterling Greex Editor, see the
Sterling Selling and Fulfillment Foundation: Extending the
Condition Builder. This screen describes an advanced XML
condition in simple English. All modifiable parameters of an
advanced XML condition display as a hyperlink on the
screen.

Click on the hyperlink of the parameter whose value you


want to edit. Specify the new value for the parameter in the
pop-up screen. The pop-up screen displays the old value. You
can also enter the new value. The new value reflects in the
Advanced XML screen as well as in the Screen View screen
when you click on the save button in the pop-up screen.
Source View (if This screen displays only when you are editing an advanced
AdvancedXML is checked) XML condition that is created using the Sterling Greex Editor
IDE tool.

This screen displays a specific advanced XML condition in an


XML form or as defined in the advanced XML file. You
cannot make changes to any parameter of the advanced XML
condition.
Condition Cases (if Specify the custom cases for the decision table-based
AdvancedXML is checked) advanced XML condition. For more information about
creating custom cases for a decision table-based advanced
XML condition, see the Sterling Selling and Fulfillment
Foundation: Extending the Condition Builder.

Deleting a Condition
About this task

To delete a condition:

Procedure
1. In the Process Modeling window, select the Order, Load, or General tab to view
the corresponding process modeling tree for that base document type.
2. In the Process Types swimlane, right-click on the applicable process type and
choose Model Process. The Repository Details window and work area display
for the corresponding process type.
3. Choose the Conditions Tab.
4. Expand the Conditions branch.
5. Expand the applicable condition group branch.

6. Select the condition you want to delete and choose .

174 Sterling Selling and Fulfillment Foundation: Application Platform Configuration Guide
Viewing All Entities Affected by a Condition
About this task

You can view all of the events, pipelines, and status rules that are affected by a
particular condition. This is useful when you need to modify a condition so that
you can see what is impacted by your modification.

To view the entities affected by a condition:

Procedure
1. In the Process Modeling window, select the Order, Load, or General tab to view
the corresponding process modeling tree for that base document type.
2. In the Process Types swimlane, right-click on the applicable process type and
choose Model Process. The Repository Details window and work area display
for the corresponding process type.
3. Choose the Conditions Tab.
4. Expand the Conditions branch.
5. Expand the applicable condition group branch.
6. Select the applicable condition and choose . The Condition Details window
displays in the work area.

7. Choose . The Entities Affected by this Condition pop-up window displays.


The Pipeline Entities tab provides a list of pipelines affected by the condition,
Enterprises affected by determination rules containing the condition, and
pipelines affected by monitoring rules containing the condition. The Others tab
details all of the events, statuses, and services affected by the condition.

Chapter 4. Configuring Process Models 175


Defining Actions
An action is a process or program that is triggered by an event. These processes
and programs send alert notifications, publish data, or initiate custom services.

For example, when an order is released (the event), you can set an action to send
the customer an e-mail.

Creating an Action
About this task

To create an action:

Procedure
1. In the Process Modeling window, select the Order, Load, or General tab to view
the corresponding process modeling tree for that base document type.
2. In the Process Types swimlane, right-click on the applicable process type and
choose Model Process. The Repository Details window and work area display
for the corresponding process type.
3. Choose the Actions Tab.
4. Expand the Actions branch.

5. Choose . The Action Details window displays.

176 Sterling Selling and Fulfillment Foundation: Application Platform Configuration Guide
6. Enter information in the applicable fields. Refer to Table 53 for field level
descriptions.

7. Choose .

Note: It is recommended that all Actions defined by you should contain the
prefix "EXTN_" to avoid conflicts between factory-shipped actions and the
custom defined actions.

Table 53. Action Details Window


Field Description
Action Code Enter the action code.
Action Name Enter the action's name.

Chapter 4. Configuring Process Models 177


Table 53. Action Details Window (continued)
Field Description
Action Group Enter the name of the action's group, if applicable. Actions
belonging to the same group appear together in the Action
tab in the Process Modeling tree.
Invoked Services
Invoke following services Select this if you want this action to invoke a configured
as part of this action service.
Note: If you configure actions that invoke a service, which
inserts messages into an MQ Series queue, ensure that your
System Administrator includes the following .jar files in the
CLASSPATH environment variable for your application
server (Oracle WebLogic, IBM WebSphere, or JBoss):
v $MQSERIES_HOME/lib/fscontext.jar
v $MQSERIES_HOME/lib/providerutil.jar
v $MQSERIES_HOME/lib/jndi.jar
v $MQSERIES_HOME/lib/com.ibm.mq.jar
v $MQSERIES_HOME/lib/com.ibm.mqbind.jar
v $MQSERIES_HOME/lib/com.ibm.mqjms.jar
v $MQSERIES_HOME/lib/jms.jar
Invoked Services List Lists the services that this action invokes. When you check
‘Invoke following services as part of this action' you can add
additional services by choosing . You can remove services
by selecting the applicable service and choosing .
Service Name The name of the service.
Service Group Name The name of the service group the service belongs to.
Others Important: All information in this tab can be configured
within the Service Definition Framework. The information in
this tab is provided solely for backward compatibility
purposes. From Version 5.0 onwards, these should be
configured as a service.
Send to Alert Console Select the check box if you want an alert notice to be sent to a
particular user.
Queue Name Enter the name of the queue the alert should be sent to.
User Name Select the name of the user who is to receive alert notices.
Template Enter the Alert Console template. It can be any name
followed by an ECT or XSL extension.

If the template is within the EAR file:

The value of the Template field specified in the action should


be the same as the path to the template file as built within
the EAR. The path should be relative to the root of the EAR.

If the template is outside the EAR file:

The value of the Template field specified in the action can be


the path to the file relative to the path given in the
CLASSPATH specified in the application server's start-up
script.

178 Sterling Selling and Fulfillment Foundation: Application Platform Configuration Guide
Table 53. Action Details Window (continued)
Field Description
Send E-Mail Select the check box if you want an e-mail message to be
sent. Enter a template name in the Template field.
Note: You must configure your e-mail server before you can
activate this action.
Template Enter the name of the e-mail template. It can be any name
followed by an MLT extension (if data published is a map) or
XSL extension (if data published is an XML).

If the template is within the EAR file:

The value of the Template field specified in the action should


be the same as the path to the template file as built within
the EAR. The path should be relative to the root of the EAR.

If the template is outside the EAR file:

The value of the Template field specified in the action can be


the path to the file relative to the path given in the
CLASSPATH specified in the application server's start-up
script.
Call Java Extension Select this field if you want to call a particular Java
component.
Class Name Enter the Java class name.
Execute Select this field if you want to call a particular executable.
Program Enter the Program (executable) name. Make sure the
executable exists in the system PATH.
Call DB Extension Select this field if you want to call a particular stored
procedure.
Stored Procedure Enter the Stored Procedure name.
Call HTTP Extension Select this field if you want to call a particular URL.
URL Enter the URL to be called for the HTTP Extension.
Send Fax This field is no longer supported.
Template This field is no longer supported.
Call COM Extension This field is no longer supported.
Prog ID This field is no longer supported.
Publish Data Select this field if you want to publish data to an external
system.
System ID
Choose and enter the system ID in the System ID pop-up
window.

If you want to delete an existing system ID, select the system


ID you want to delete and choose .
Note: System IDs cannot be more than 20 characters.

Note: Only actions linked to the primary enterprise of this node or


organization are available in the drop-down. Any actions created from this
screen using the create button are linked to the primary enterprise of the user's
organization and hence may not be available for the node or organization being
created. In a multi-enterprise situation please ensure that actions are created for

Chapter 4. Configuring Process Models 179


the appropriate enterprises first (when logged in as that enterprise user).
Subsequently mapping of nodes to actions can be done logged in either as an
enterprise user or as a hub user.

Modifying an Action
About this task

To modify an action:

Procedure
1. In the Process Modeling window, select the Order, Load, or General tab to view
the corresponding process modeling tree for that base document type.
2. In the Process Types swimlane, right-click on the applicable process type and
choose Model Process. The Repository Details window and work area display
for the corresponding process type.
3. Choose the Actions Tab.
4. Expand the Actions branch.
5. Expand the applicable action group branch.
6. Select the applicable action and choose . The Action Details window
displays.
7. Enter information in the applicable fields. Refer to Table 53 on page 177 for
field value descriptions.

8. Choose .

Deleting an Action
About this task

To delete an action:

Procedure
1. In the Process Modeling window, select the Order, Load, or General tab to view
the corresponding process modeling tree for that base document type.
2. In the Process Types swimlane, right-click on the applicable process type and
choose Model Process. The Repository Details window and work area display
for the corresponding process type.
3. Choose the Actions Tab.
4. Expand the Actions branch.
5. Expand the applicable action group branch.

6. Select the applicable action and choose .

Defining Service Definitions


Service definitions are a representation of the logic that regulates document
workflow services. The Service Builder is a graphical interface that enables you to
create a graphical representation of these services, in the following situations:
v Transporting data, typically between Sterling Selling and Fulfillment
FoundationSterling Application Platform and external applications
v Transforming data from one format to another
v Extending the application logic when events are raised

Services can be accessed using the following mechanisms:

180 Sterling Selling and Fulfillment Foundation: Application Platform Configuration Guide
v executeFlow() API
v Resource configuration for accessing from the user interface
v Actions can be associated to invoke a service
v User-triggered transactions can be used to invoke a service to raise an alert to
inform the applicable users
v Document Routers
v Monitors

Service Nodes

Service nodes contain the logic that you can use to build a service definition.

The following service nodes are available from the Service Palette:
v Transport nodes
v Component nodes
v Adapter nodes
v Connector nodes

Connector nodes are only available from the right-click menu.

Transport Nodes

Transport nodes forward messages, allowing Sterling Selling and Fulfillment


FoundationSterling Application Platform to communicate with external systems.
Transports (and the entire service) can be classified into the following categories:
v Synchronous - immediately forward messages
v Asynchronous - store and forward messages

You may use either type, depending on your needs. The following sections list the
types of synchronous and asynchronous transport types.

You can add a transport node by dragging it from the pallet into the work area.

Synchronous services forward messages immediately. Sterling Selling and


Fulfillment FoundationSterling Application Platform supports the following
synchronous transport types:
v COM
v Enterprise Java Bean (EJB)
v Hypertext Transfer Protocol (HTTP)
v Web Services
v Synchronous MQSeries Message Queue
v Synchronous Oracle WebLogic Message Queue

Asynchronous services store and forward messages. They queue up messages in a


database or a queuing mechanism, which allows you to reprocess exceptions, if
any, at a later time. Sterling Selling and Fulfillment FoundationSterling Application
Platform supports the following asynchronous transport types:
v Asynchronous MQ JMS Queue
v Asynchronous Oracle WebLogic JMS Queue
v Database
v File IO

Chapter 4. Configuring Process Models 181


v FTP
v Generic JMS
v MSMQ

Each transport type has the following sender and receiver aspects:
v receiver - defines how information should be received from the transport node
v sender - defines how information should be sent to the transport

Whether a transport is a sender or receiver depends on how you have connected


the flow of logic to be directed.

For a complete list of available transport nodes and details of their parameters, see
Chapter 24, “Transport Nodes,” on page 547.

Component Nodes

Component nodes format or translate data. Sterling Selling and Fulfillment


FoundationSterling Application Platform supports the following components:
v Alert
v API
v E-Mail
v Composite Service
v Condition
v Nomenclature Runtime
v Router
v Text Translator (For detailed information about text translator file configuration,
see Chapter 25, “Text Translator Reference,” on page 623.)
v XSL Translator

You can add a component node by dragging it from the pallet into the work area.

For a complete list of available component nodes and details of their parameters,
see Chapter 24, “Transport Nodes,” on page 547.

Adapter Nodes

Adapter nodes allow you to implement a Sterling Selling and Fulfillment


FoundationSterling Application Platform Adapter with an external system.

Sterling Selling and Fulfillment FoundationSterling Application Platform supports


the Sterling GISIBM Sterling B2B Integrator.

Connector Nodes

Connector nodes allow you to link nodes together without adding any additional
logic. This allows you to complete a service. The types of available connector
nodes are as follows:
v Start node - All services are required to begin with a Start node. The Start node
defines where to begin running the Service Definition Framework logic. When
you create a new flow, the Start node is already laid out for you.

182 Sterling Selling and Fulfillment Foundation: Application Platform Configuration Guide
v End node - All services are required to end with an End node. The End node
defines where to end that particular flow of the Service Definition Framework
logic. When you create a new flow, the End node is already laid out for you.
v Pass-through node - The Pass-through node allows you connect synchronous
and asynchronous components together.

You can add a connector node by right-clicking in the work area and selecting
from the above connector node types.

Criteria of a Complete Service Flow

The following conditions must be met in order to save a service:


v Start node - Required. One maximum.
v Transport node - Optional. Zero or many.
v Component node - Required. One or many.
v Adapter Node - Optional. Zero or many.
v End Node - Required. One or many.
v All nodes must be connected together.
v All required properties on all nodes and links must have values specified.

Creating a Service
About this task

To create a service:

Procedure
1. In the Process Modeling window, select the Order, Load, or General tab to view
the corresponding process modeling tree for that base document type.
2. In the Process Types swimlane, right-click on the applicable process type and
choose Model Process. The Repository Details window and work area display
for the corresponding process type.
3. Choose the Service Definitions Tab and select the parent node of the current
Service Definition tree.

4. Choose the Process Type Services node and choose . The Create New
Service Properties dialog box displays.
5. Enter information in the applicable fields. Refer to Table 54 on page 184 for
field value descriptions.
6. Choose OK. The Service Details Window displays.

Note: It is recommended that all Services defined by you should contain the
prefix "EXTN_" to avoid conflicts between factory-shipped services and the
custom defined services.

Chapter 4. Configuring Process Models 183


Table 54. Create New Service Window
Property Description
Service Name Enter the service name.
Service Group Name Enter the service group the new service should be categorized
in.

As long as the service group is populated with services, it


cannot be deleted. When you delete all services within a
group, the group container is automatically deleted.
This Service Provides Select this if the service returns a response to the caller when
Real-time Responses invoked. This option is only available for services that are
invoked synchronously, whether from within Sterling Selling
and Fulfillment FoundationSterling Application Platform or
externally.
Note: When this property is selected, asynchronous transports
cannot be added to the service.
Is Print Service Select this service to print labels.
Is Data Loading Service Select this service to load data.
This Service Is Invoked by an External System or from within Sterling Selling and
Fulfillment FoundationSterling Application Platform.
In an Asynchronous Mode Select this option when the service must start by retrieving a
message from an asynchronous transport source.

The service starts from a queue or database. The definition of


the service does not need detail how the message arrives at
asynchronous source such as queue or database.

When this option is selected the first node after the start node
must be an asynchronous transport node.
In a Synchronous Mode Select this option when the service is invoked from Sterling
Selling and Fulfillment FoundationSterling Application
Platform or through an API synchronously.

Linking Service Definition Nodes:


About this task

Before linking nodes together, lay them out on the work area so that the logic
flows from left to right and from top to bottom. Place you nodes so that the link
coming from a source node are on the bottom or right side, and comes into the top
or left side of the target node. See the following example.

184 Sterling Selling and Fulfillment Foundation: Application Platform Configuration Guide
To link nodes together:

Procedure
1. On the first node, click the small black diamond to its right.
2. Drag a link to the next node.

Results

It doesn't matter what order you use for linking nodes, but it makes more sense to
create the links in the order in which the logic flows.

Note: If you delete a transport link, you also delete any properties you have
defined. You can avoid this by linking your nodes together before defining the
properties.

If you try to link nodes together that cannot be linked, the status bar informs you
that this task that cannot be completed.

Defining a Node's Properties:


About this task

You can configure the individual node properties. For a complete list of the
available service nodes and their properties, see Chapter 24, “Transport Nodes,” on
page 547.

To configure node properties:

Procedure
1. In the Process Modeling window, select the Order, Load, or General tab to view
the corresponding process modeling tree for that base document type.
2. In the Process Types swimlane, right-click on the applicable process type and
choose Model Process. The Repository Details window and work area display
for the corresponding process type.
3. Choose the Services Tab and select the parent node of the current Service
Definition tree.
4. Choose the Process Type Services node.
5. Locate the applicable service and choose . The Service Details Window
displays.
6. In the work area, choose the applicable node, its properties panel displays in
the bottom frame.
7. Edit the properties as indicated for the node in Chapter 24, “Transport Nodes,”
on page 547.

Chapter 4. Configuring Process Models 185


Saving a Service as a Draft
About this task

You can save an incomplete service as a draft. This draft can be retrieved for a
final save without any necessary validations.

To save a service as a draft:

Procedure
1. In the Process Modeling window, select the Order, Load, or General tab to view
the corresponding process modeling tree for that base document type.
2. In the Process Types swimlane, right-click on the applicable process type and
choose Model Process. The Repository Details window and work area display
for the corresponding process type.
3. Choose the Services Tab and select the parent node of the current Service
Definition tree.
4. Configure a service as per the rules detailed in this section.

5. Choose . The service as saved as a draft service.

6. When you are ready to save it as a complete and functional service, choose .

Note: When you save a service as a draft, any existing drafts for the service are
overwritten. When you save the draft as an actual service, any existing services
are overwritten.

Saving a Service as Another Service


About this task

You can save an existing service as another service.

Note: When you save a service containing a Sub Service Name as another service,
that Sub Service Name is copied over with an appended digit to differentiate it
from the original Sub Service Name. For example, if you save a service named
Service1 containing a Sub Service Name R1 as another service named Service2, the
original Sub Service Name is copied over as R1_0.

To save a service as another service:

Procedure
1. In the Process Modeling window, select the Order, Load, or General tab to view
the corresponding process modeling tree for that base document type.
2. In the Process Types swimlane, right-click on the applicable process type and
choose Model Process. The Repository Details window and work area display
for the corresponding process type.
3. Choose the Services Tab and select the parent node of the current Service
Definition tree.
4. Select the existing service you want to save as a new service.

5. Choose . The Save Service As pop-up window displays.


6. In Service Name, enter the name of the new service.

7. Choose .

186 Sterling Selling and Fulfillment Foundation: Application Platform Configuration Guide
Chapter 5. Configuring User Security
Security must be set up to allow users access to the actions and views provided by
the organization to which they belong. A user is limited to access only those to
which they have permission.

The Applications ManagerConfigurator’s Security Management is used to create


users, user groups, and teams. Once these have been created, permissions can be
assigned.

Defining Users
A user is a single person assigned with a certain task, such as, Hub Administrator
or Customer Service Representative, depending on what role they play in the
organization. Each user is associated with one organization.

Creating a User
About this task

To create a user:

Procedure
1. From the tree in the application rules side panel, choose Security > Users. The
User Search window displays in the work area.

2. Choose . The User Details window displays.


3. Choose the Primary Info tab.
4. Enter information in the applicable fields. Refer to Table 55 on page 188 for
field value descriptions.

© Copyright IBM Corp. 1999, 2011 187


Table 55. User Details Window
Field Description
User ID Enter the user ID that the user uses to access the system.
Password Enter the password the user uses to access the system.
Department Code Select the code of the department to associate with the user.
User Name Enter the user's name.
Locale Select the locale the user is located in.
Note: A user who is configured for the Eastern Time Zone
but logs in while physically in the Pacific Time Zone, sees
locale specific information as if he or she was in the Eastern
Time Zone.
Menu Group Select the menu group representing the menu options you
want users to see when they log into the Application
ConsoleConsole.

188 Sterling Selling and Fulfillment Foundation: Application Platform Configuration Guide
Table 55. User Details Window (continued)
Field Description
Theme Enter the available theme as you want it to appear for the
user. The theme determines how the color scheme of the
Console and Applications ManagerConfigurator displays to
the user.

The available themes are:


v Earth
v Jade
v Sapphire
Note: You can extend the system to include as many themes
as you want.
Password Policy Select the password policy that you want to associate with
the user.

For additional information about password policies, see the


Sterling Selling and Fulfillment Foundation: Password Policy
Management .
Team Select the team to which you want to assign the user. For
more information about teams, see “Defining Teams” on page
206.

Notes:
v The list contains all the teams configured for the
organization to which the user belongs and the parent
organization, if applicable.
v Clearing of the database cache is required to take into
effect the changes made to this configuration.
Active Check this if the user is currently active in the organization.
Inactive users cannot log in.
Is Supervisor Check this if the user is a personnel supervisor.
Max Customer Enter the maximum number of customers that this user can
Assignments be assigned to manage.
Contact Address The user's contact address.

Choose to enter an address.

Choose the Contact tab to view additional contact


information.
Billing Address The user's billing address.

Choose to enter an address.

Choose the Contact tab to view additional contact


information.
Group Subscriptions
Available A list of the available user groups.

To subscribe a user to a user group, select the applicable user


group and choose .

Chapter 5. Configuring User Security 189


Table 55. User Details Window (continued)
Field Description
Subscribed A list of the user groups to which the user is subscribed.

To remove a user from a user group, select the applicable


user group and choose .

5. If you want to subscribe the user to an alert queue or remove the user from an
alert queue, choose the Queue Subscription tab.
6. To subscribe a user to an alert queue, select the applicable queue from
Available and choose . To remove a user from a queue select the applicable
queue from Subscribed and choose .

7. Choose .

Modifying a User
About this task

To modify a user:

Procedure
1. From the menu bar, choose Applications > Application Platform. The
Application Platform tree displays in the side panel.
2. From the Application Platform tree, choose Security > Users. The User Search
window displays in the work area.

3. Enter applicable search criteria and choose . A list of users displays.

4. Select the applicable user and choose .


5. Modify information in the applicable fields. Refer to Table 55 on page 188 for
field value descriptions.
6. Choose .

Setting Up Printer Preferences for a User


About this task

User Printer Preferences configures printers that are associated with a specific user.
This preference is used to determine the printer to use when a user prints a
document.

For example, receiving office associates all its users to the HP LaserJet 5P located
in the office.

The association of a printer to a station overrides the group preference of the


specified user. The station is a static location where devices may be directly
attached to a station.

It is recommended that User Printer Preferences be configured at the group level


for easier administration.

To set up printer preferences for a user:

190 Sterling Selling and Fulfillment Foundation: Application Platform Configuration Guide
Procedure
1. From the menu bar, choose Applications > Application Platform. The
Application Platform tree displays in the side panel.
2. From the tree in the application rules side panel, choose Security > Users. The
User Search window displays.
3. In the User Search window, enter applicable search criteria.

4. Choose . The list of users displays in the Search Results panel of the User
Search window.

5. In the Search Results panel of the User Search window, choose the User whose
Printer Preferences are to be set up.

6. Choose . The User Details window displays.


7. In the User Details window, choose the Printer Preferences tab. The Printer
Preferences tab window displays.
8. Enter the information in the applicable fields. Refer Table 56 on page 192 for
field value descriptions.
9. Choose .

Chapter 5. Configuring User Security 191


Results

For more information about Setting Up a User (Creating, Modifying, or Deleting a


User), see “Defining Users” on page 187.

Table 56. Printer Preferences Tab Window


Field Description
Printer Association
Printer ID From the drop down, select the printer ID to be associated
with the user.

Deleting a User
About this task

To delete a user:

Procedure
1. From the tree in the application rules side panel, choose Security > Users. The
User Search window displays in the work area.

192 Sterling Selling and Fulfillment Foundation: Application Platform Configuration Guide
2. Enter applicable search criteria and choose . A list of users displays.

3. Select the applicable user and choose .

Defining User Groups


User groups are a collection of users who perform a similar task. For example, a
group of customer service representatives might be put in a Customer Service
Representative user group. Users can belong to multiple user groups to which
permissions are assigned. A user who belongs to multiple user groups retains the
least restrictive set of permissions defined by the groups they belong to. For
example, if a user belongs to a user group that permits the user to use the
Application Console, and this user also belongs to a user group that permits the
user to access only the Console and Applications ManagerConfigurator, the user
has access to both applications.

Each organization has its own user groups. User groups can only contain users for
the same organization that the user was created for, except in the case of a user
group created by the Hub organization, which can contain users of any
organization.

Creating a User Group


About this task

To create a user group:

Procedure
1. From the tree in the application rules side panel, choose Security > Groups. The
Groups window displays in the work area.

2. Choose . The Group Details window displays.


3. Enter information in the applicable fields. Refer to Table 57 on page 194 for
field value descriptions.

4. Choose .

Chapter 5. Configuring User Security 193


Table 57. Group Details Window
Field Description
Group ID Enter the user group ID.
Group Name Enter the user group's name.
Group Description Enter a description about the user group.
Group Type From the drop-down list, select a group type that you want
to associate with the user group. You can select either:
v INTERNAL - Indicates that the users belonging to this user
group are internal users.
v EXTERNAL - Indicates that the users belonging to this user
group are Web channel users.

Modifying a User Group


About this task
To modify a user group:

Procedure
1. From the tree in the application rules side panel, choose Security > Groups. The
Groups window displays in the work area.

2. Select the applicable user group and choose . The Group Details window
displays.
3. Modify information in the applicable fields. Refer to Table 57 for field value
descriptions.

4. Choose .

Administering User Group Permissions


About this task

You can administer the permissions that a user group has throughout the Console
and Applications ManagerConfigurator applications. You can allow or disallow
permissions for an entire module or on a screen-by-screen or function-by-function
basis. These permissions apply to all of the users in the user group.

Note: The user administering the permissions is only able to administer


permissions for those action and views that he or she has rights to administer.
Therefore, it is suggested that each organization have one single user who
administers permissions for his or her own organization.

To set up user group permissions:

Procedure
1. From the Group Details window, choose the Permissions tab.
2. Locate the module that you want to add and/or revoke permissions for and
choose the Permission button. The Permissions tree for the corresponding
module displays.

194 Sterling Selling and Fulfillment Foundation: Application Platform Configuration Guide
3. If you want to allow permissions for an entire module, highlight the module
you want to allow permissions for and choose the Grant All icon. To disallow
permissions for an entire module, highlight the module and choose the Revoke
All icon.
You can also view the list of users who have permission to access the entity by
performing a right-click and choosing .

Note: If you want to revoke permissions to a particular menu for a given user
group, you need to revoke all of the permissions for screens that can be
selected under the menu option for which you are revoking permissions. For
example, if you uncheck the System Management Console and all of its
associated screens and functions, users do not see the System Management
Console menu option in the Application ConsoleConsole.
4. If you want to allow permissions on a screen-by-screen or function-by-function
basis, expand the application that you want to allow permissions for and
highlight the screens that you want to allow and choose the Grant icon. To
disallow permissions on a screen-by-screen or function-by-function basis,
highlight the screens and choose the Revoke icon.

Chapter 5. Configuring User Security 195


Note: The permissions tree displays the pricing screens and functions for both
the new and old pricing functionalities. If you are using the new pricing
functionality, permissions should be assigned to the new pricing functions. If
you are using the old pricing functionality, permissions should be assigned to
the old pricing screens. For more information about enabling the old and new
pricing functionality, see “System Administration Components: Defining
Installation Rules” on page 226.
5. If you are configuring permissions for a group that has access to the
ConsoleApplication Console, choose the Cross Application Permission button
and expand the Application > Sterling Selling and Fulfillment
FoundationSterling Application Platform Console > Override branch and enable
any of the following permissions as needed:
v The Display Decrypted Primary Payment Attributes permission determines
whether sensitive payment information such as credit card name, credit card
expiration date, customer account number or primary payment reference is
displayed or masked in the Application ConsoleConsole.
If Sterling Selling and Fulfillment FoundationSterling Application Platform is
configured to encrypt primary payment attributes, and the Display
Decrypted Primary Payment Attributes permission is granted, the
Application ConsoleConsole determines whether to call the
getDecryptedString API to decrypt and display sensitive payment
information.
For more information about enabling database encryption for primary
payment attributes, see “System Administration Components: Defining
Installation Rules” on page 226.

Note: Encryption and decryption of credit card numbers and stored value
card numbers has been deprecated. IBM recommends that credit card
numbers and stored value card numbers should not be encrypted. Instead,
they should be tokenized and stored securely in an external vault system. As
a result, credit card numbers and stored value card numbers cannot be
viewed in the Application Console.
v To grant the Application ConsoleConsole the ability to make modifications to
documents that are normally not allowed based on the status modification
rules you have configured (reference), grant the Override Modification Rules
permission. For example, you may not allow regular users to modify the
instructions of a released sales order. However, specific users should be able
to add instructions on exception conditions. When this permission is granted,
the user is able to make the appropriate overriding modifications in the
order console.

Note: To indicate that a particular field can be only be modified through this
user group permission, the Sterling Selling and Fulfillment
FoundationSterling Application Platform Console displays this field as
editable, with a blue background.
v To grant the Application ConsoleConsole the ability to view the stack trace
error messages, grant the Display Error Details permission.

6. Choose after configuring the permissions.

Note: If you are configuring permissions for a group that has access to the
Application ConsoleConsole, choose the Cross Application Permission button
and expand the Application > Sterling Selling and Fulfillment
FoundationSterling Application Platform Console > Override branch. Select
Display Sensitive Payment Information if you want the users in this group to

196 Sterling Selling and Fulfillment Foundation: Application Platform Configuration Guide
be able to see sensitive payment information, such as credit card name, credit
card expiration date, customer account number, or primary payment reference
in the Application Console. Select Override Modification Rules if you want the
permissions that you have configured for this group to override any
modification rules that you have configured. Otherwise, leave this box
unchecked and the configured modification rules are always applied.

Setting Inner Panels as Read-Only


About this task

Sterling Selling and Fulfillment FoundationSterling Application Platform enables


you to mark inner panels as read-only. This ensures that a specified user group
cannot modify or update any of the data visible to them. When an inner panel is
marked as read-only, all the controls and its values in the page are visible but are
disabled.

There are two ways to make an inner panel read-only:


v Set the read-only attribute for the resource in the RESOURCE_PERMISSION.xml
file.
If the inner panel needs to be marked as read-only for an user, update the
RESOURCE_PERMISSION_CONSOLE.xml file in the factory setup with the
READ-ONLY attribute.
The following example shows the RESOURCE-PERMISSION.xml file with
changes:
<ResourcePermission ActivateFlag="Y" Createprogid="SYSTEM"
Createuserid="SYSTEM" Modifyprogid="SYSTEM" Modifyuserid="SYSTEM"
ResourceKey="YEMS012" ResourcePermissionKey="SYS_YEMS012"
UsergroupKey="SYSTEM" READ-ONLY-FLAG="True"/>
In this example, the database table YFS-RESOURCE-PERMISSION will be
updated for the user SYSTEM and resource YEMS012.
v Use the Applications ManagerConfigurator to apply security permissions and
mark an inner panel as read-only.
1. Log in to the Applications ManagerConfigurator. Select Applications →
Application Platform → Security → Groups.
2. Select a Group or create new Group. Click Permission next to the application
you want to manage.
All of the entities for the application open in tree form. You can double click
an entity to see its views and inner panels.

Chapter 5. Configuring User Security 197


3. Right-click the selected inner panel to set or unset the inner panel as
read-only.

Setting Up Permissions for Interoperability Servlet


About this task

Sterling Selling and Fulfillment FoundationSterling Application Platform enables


you to set up permissions for access to Interoperability Servlet. This ensures that a
specified user group has permissions to access the Interoperability Servlet.

To set up security permissions for Interoperability Servlet using the Applications


ManagerConfigurator:

Procedure
1. Log in to the Applications ManagerConfigurator. Select Applications →
Application Platform → Security → Groups.
2. Select a Group or create new Group. Click Permission next to the application
you want to manage.

198 Sterling Selling and Fulfillment Foundation: Application Platform Configuration Guide
All of the entities for the application open in tree form. You can double click an
entity to set Interoperability Servlet permissions for its elements.

3. Right-click the Access to Interoperability Servlet to grant permissions.

Setting Up Permissions for APIs


About this task

Sterling Selling and Fulfillment FoundationSterling Application Platform enables


you to set up permissions for access to APIs for the authorization check. You must
define access to API resources to control what can be accessed by users when
calling an API.

To set up security permissions for APIs using the Applications


ManagerConfigurator:

Procedure
1. Log in to the Applications ManagerConfigurator. Select Applications →
Application Platform → Security → Groups.

Chapter 5. Configuring User Security 199


2. Select a Group or create new Group. Click Permission next to the API Security.
The API Permissions pop-up window displays.
You can double click on APIs or Services branch. All of the APIs and Services
for the Sterling Selling and Fulfillment FoundationSterling Application Platform
open in tree form.

3. Right-click the individual API or Service to grant permissions.

4. At the upper right of the API Permissions screen, click or to grant or


revoke permission to the user for that API or Service. By default, permission is

revoked for all APIs or Services. Click to list all of the users who have been
granted permission for an API or Service.
5. When you are finished granting and revoking permissions, save the permission
record by clicking .

200 Sterling Selling and Fulfillment Foundation: Application Platform Configuration Guide
Viewing the Users Subscribed to a User Group
About this task

You can view all of the users that are subscribed to the user group. The list can be
viewed by choosing the User Subscriptions tab from the Group Details window.
You can also add or delete a user from the group subscription.

Setting Up Printer Preferences for a User Group


About this task

User Printer Preferences configures printers that are associated with a group of
users. This preference is used to determine the printer to use when a user prints a
document.

For example, receiving office associates all its users to the HP LaserJet 5P located
in the office.

The association of a printer to a station overrides the group preference of the


specified user. The station is a static location where devices may be directly
attached to a station.

It is recommended that User Printer Preferences be configured at the group level


for easier administration.

Procedure
1. From the menu bar, choose Applications > Application Platform. The
Application Platform tree displays in the side panel.
2. From the tree in the application rules side panel, choose Security > Groups. The
Groups window displays with a list of groups.

Chapter 5. Configuring User Security 201


3. In the Groups window, choose the Group whose Printer Preferences are to be
set up.

4. Choose . The Group Details window displays.


5. In the Group Details window, choose the Printer Preferences tab. The Printer
Preferences tab window displays.
6. Enter the information in the applicable fields. Refer Table 58 on page 203 for
field value descriptions.
7. Choose .

Results

For more information about Setting Up a Group (Creating, Modifying, or Deleting


a Group), “Defining User Groups” on page 193.

202 Sterling Selling and Fulfillment Foundation: Application Platform Configuration Guide
Table 58. Printer Preferences Tab Window
Field Description
Printer Association
Printer ID From the drop down, select the printer ID to be associated
with the group.

Note: The printer at the packing station is associated to the station and not to the
packing group or the individual packer. This is also recommended for warehouses
that have only a single pack station.

Deleting a User Group


About this task

To delete a user group:

Procedure
1. From the tree in the application rules side panel, choose Security > Groups. The
Groups window displays in the work area.

2. Select the applicable user group and choose .

Chapter 5. Configuring User Security 203


Defining Data Security Groups
Data security groups are used to control access to the data contained in specific
document types, Enterprises, and ship nodes within the Sterling Application
Platform Console. Creating a data security group is an optional process. If a user is
not associated with a data security group, that user is considered to have the least
restrictive access, or default access. By defining a data security group, you can
further restrict the access to any Enterprises or document types or participating
ship nodes that are a sub-set of the default access list.

The default access list for document types is based on the document types
associated with a particular business module.

There is no default access list for ship nodes. By default, a data security group has
access to all the ship nodes.

The default access list for Enterprise access is based on the type of user for which
the data security group is defined. Only Hub, Enterprise, and Enterprise/Hub
Node users can create data security groups, as described in the following table:
Table 59. Default Access List
Can be Further Filtered by
User Default Enterprise Access List Data Access Group?
Hub All Enterprises in the system. Yes
Enterprise All Enterprises that are children Yes
Enterprises of the Enterprise
you are configuring.
Enterprise/Hub Node All Enterprises with which the Yes
Users node organization participates.
All Other Users All Enterprises with which the No
organization participates.

You can define a data security component for data security groups in the service
definition framework to enable the groups to secure data based on your data
security policies. For more information about data security components, se Section
C.2.11, "Data Security".

Creating a Data Security Group


About this task

To create a data security group:

Procedure
1. From the tree in the application rules side panel, choose Security > Data
Security Groups. The Data Security Groups window displays in the work area.
2. Choose . The Data Security Details window displays.
3. Enter information in the applicable fields. Refer to Table 61 on page 207 for
field value descriptions.

4. Choose .

204 Sterling Selling and Fulfillment Foundation: Application Platform Configuration Guide
Table 60. Data Security Details Window
Field Description
Group ID Enter the data security group name.
Description Enter a brief description of the data security group.
Enterprises
Default Enterprise Access Select Default Enterprise Access to restrict users who belong
to this data security group to be able to only view the
Enterprises belonging to the default Enterprise access list.
Restrict Access To A Select Restrict Access To A Specific List Of Enterprises if you
Specific List Of Enterprises want to create a list of Enterprises that users associated to the
data security group can view.

Choose from the Accessible Enterprises table and search


for the applicable Enterprises in the Organization Search
pop-up window. Choose to add an Enterprise.

Choose to remove an Enterprise from the Accessible


Enterprises list.
Note: The restricted list always includes the primary
Enterprise of the organization you are configuring the data
security group for.
Document Types
Default Document Type Select Default Document Type Access to allow this data
Access security group to only be able to view the document types
belonging to the default access list. The default access list is
based on the document types associated with a particular
business application.
Restrict List To A Specific Select Restrict List To A Specific List Of Document Types if
List Of Document Types you want to specifically determine the document types the
data security group has access to.

When you select this option select the business application


whose associated document types you want to set access
rights to from Applications.

Then select if you want to allow Access To All Document


Types For This Application or Restrict Access To A Specific
List Of Document Types. If you select the latter, the
Accessible Document Types table displays displaying all of
the accessible document types available for the business
application. Select the Accessible check boxes for the
applicable document types.
Ship Node

Chapter 5. Configuring User Security 205


Table 60. Data Security Details Window (continued)
Field Description
All Nodes Select All Nodes to allow this data security group to access
all ship nodes participating in the organization of the
configured Data Security groups organization.
Note: The HUB User (Organization = DEFAULT) has access
to all the ship nodes.
User's Ship Node Select User's Ship Node to allow this data security group to
access only the ship node to which the user belongs.
Restrict Access To Specific Select Restrict Access To Specific Nodes if you want to create
Nodes a list of ship nodes that users associated to the data security
group can view.

Choose from the Accessible ShipNode table and search


for the applicable ship nodes in the Node Search pop-up
window. Choose to add a ship node.

Choose to remove a ship node from the Accessible


ShipNode list.

Modifying a Data Security Group


About this task

To modify a data security group:

Procedure
1. From the tree in the application rules side panel, choose Security > Data
Security Groups. The Data Security Groups window displays in the work area.

2. Select the applicable data security group and choose . The Data Security
Details window displays.
3. Enter information in the applicable fields. Refer to Table 61 on page 207 for
field value descriptions.

4. Choose .

Deleting a Data Security Group


About this task

To delete a data security group:

Procedure
1. From the tree in the application rules side panel, choose Security > Data
Security Groups. The Data Security Groups window displays in the work area.

2. Select the applicable data security group and choose .

Defining Teams
A Team is a collection of users who have common data access requirements. Teams
can have access to specific document types, Enterprises, ship nodes, and
customers. Teams can be assigned to specific customers.

206 Sterling Selling and Fulfillment Foundation: Application Platform Configuration Guide
Note: Enterprises and nodes assigned to a team must belong to the same colony to
which the owner (or creator) organization of the team belongs.

Creating a team is an optional process. If a user is not associated with a team, that
user is considered to have the least restrictive access, or default access to customer
orders and information. By defining a team, you can further restrict the access to
any Enterprises, document types, or participating ship nodes that are a sub-set of
the default access list. For more information about teams and how you can use
them in Sterling Selling and Fulfillment Foundation, see the Sterling Selling and
Fulfillment Foundation: Product Concepts Guide.

Note: Clearing of the database cache is required to take into effect the changes
made to this configuration.

Creating a Team
About this task
To create a team:

Procedure
1. From the tree in the application rules side panel, choose Security > Teams. The
Teams window displays in the work area.

2. Choose . The Team Details window displays.


3. Enter information in the applicable fields. Refer to Table 61 for field value
descriptions.
4. Choose .

Table 61. Team Details Window


Field Description
Team ID Enter the team name.
Parent Team ID Select the name of the team that is the parent team for this
team. If this team is part of a multi-level hierarchical team
structure, this must be the name of a team that is in the next
higher level within the structure.
Description Enter a brief description of the user team.
Enterprise Access
Default Enterprise Access Select Default Enterprise Access to restrict users who belong
to this team to be able to only view the Enterprises belonging
to the default Enterprise access list.

Chapter 5. Configuring User Security 207


Table 61. Team Details Window (continued)
Field Description
Inherited Enterprise Access Select Inherited Enterprise Access to restrict users who belong
to this team to be able to only view the Enterprises based on
the access configuration for the parent team.
Restrict Access To A Select Restrict Access To A Specific List Of Enterprises if you
Specific List Of Enterprises want to create a list of Enterprises that users associated to the
team can view.

Choose from the Accessible Enterprises table and search


for the applicable Enterprises in the Organization Search
pop-up window. Choose to add an Enterprise.

Choose to remove an Enterprise from the Accessible


Enterprises list.
Note: The restricted list always includes the primary
Enterprise of the organization you are configuring the team
for.
Document Type Access
Default Document Type Select Default Document Type Access to allow this team to
Access only be able to view the document types belonging to the
default access list. The default access list is based on the
document types associated with a particular business
application.
Inherited Document Type Select Inherited Document Type Access to restrict users who
Access belong to this team to be able to only view the document
types based on the access configuration for the parent team.
Restrict Access To A Select Restrict List To A Specific List Of Document Types if
Specific List Of Document you want to specifically determine the document types the
Types team has access to.

When you select this option select the business application


whose associated document types you want to set access
rights to from Applications.

Then select if you want to allow Access To All Document


Types For This Application or Restrict Access To A Specific
List Of Document Types. If you select the latter, the
Accessible Document Types table displays displaying all of
the accessible document types available for the business
application. Select the Accessible check boxes for the
applicable document types.
Note: At least one document type must be included in a data
security group for each business application.
Ship Node Access
All Nodes Select this radio button to allow the team to access all the
ship nodes.
Note: This radio button is not available for an organization
whose role is Node.

208 Sterling Selling and Fulfillment Foundation: Application Platform Configuration Guide
Table 61. Team Details Window (continued)
Field Description
User's Node If the user is a node user, selecting this radio button enables
the team to access the node to which the node user belong.

If the user is an enterprise user, selecting this radio button


allows the team to access all the nodes whose parent
organization is the user's enterprise, an enterprise that is
hierarchically lower than the user's enterprise, or both.
Restrict Access To Specific Select this radio button to restrict the team's access to only
Nodes specific nodes, and save the setting.

On saving, is displayed in the Accessible ShipNode


panel. Click , and search for the nodes from the ShipNode
Search dialog box.
Note: The ShipNode Search dialog box displays only those
nodes that are accessible to the administrator creating the
team.

Select the node and click to make this node accessible to


the team. The selected node will be displayed in the
Accessible ShipNode panel.

To remove a node from the Accessible ShipNode panel, select


the node and click . A confirmation dialog box is
displayed. Select OK to confirm the deletion of the node.
Nodes Accessible To Team Select this radio button to allow the team to access all the
Creator nodes that are accessible to the creator of the team.

Notes:
v If the creator of the team is a HUB user (Organization =
DEFAULT), the team can access all the ship nodes.
v If the creator's access to certain nodes changes, the team's
access to those nodes will also change automatically. Also,
the team's access to the nodes ceases when the creator is
deleted from the Applications Manager.

Modifying a Team
About this task

To modify a team:

Procedure
1. From the tree in the application rules side panel, choose Security > Teams. The
Teams window displays in the work area.

2. Select the applicable team and choose . The Team Details window displays.
3. Make revisions to the applicable fields. Refer to Table 61 on page 207 for field
value descriptions.

4. Choose .

Chapter 5. Configuring User Security 209


Deleting a Team
About this task

To delete a team:

Procedure
1. From the tree in the application rules side panel, choose Security > Teams. The
Teams window displays in the work area.

2. Select the applicable team and choose .

Defining Data Access Policies


About this task

Because all applications have different filtering requirements for data access
security, Sterling Selling and Fulfillment Foundation offers a variety of data access
policies that you can apply.

You can define data access policies for Enterprise, Buyer, Seller, and Node users so
that you can control access to data contained in specific document types,
enterprises, and ship nodes. Data access policies apply to the following access
modes:
v Enterprise User Access
v Buyer User Access
v Seller User Access
v Node User Access

You can define these access policies as follows:

Procedure
1. From the tree in the application rules side panel, choose Security > Data Access
Policy Rules. This window displays in the work area.
2. Choose among the Enterprise, Buyer, Seller, and Node User Access tabs
displayed.

Results

The following sections describe how to configure these access modes. For more
information about how the Data Access Policies can be used, see the Sterling Selling
and Fulfillment Foundation: Product Concepts Guide .
v Clearing of the database cache is required to take into effect the changes made to
this configuration.
v The Sterling Selling and Fulfillment Foundation Configurator does not load
configuration data based on the Data Access Policies described in this section.

Enterprise User Access


About this task

You can configure access for an Enterprise user, such as an internal storefront
administrator, in the Data Access Policy Enterprise User screen.

210 Sterling Selling and Fulfillment Foundation: Application Platform Configuration Guide
Procedure
1. Choose the Enterprise User tab.
2. Enter information in the applicable fields. Refer to Table 62 for field value
descriptions.

Table 62. Enterprise User Access Policy Rules


Field Description
Enterprise Access
Users Have Access To Their Users can have access to data belonging to only their
Enterprise Only enterprise.
Users Have Access To All Users can have data access to all enterprises assigned
Enterprises Assigned To Their to their team.
Team
Customer Access
Users Have Access To All Users can have access to all customers in the hierarchy.
Customers
Users Have Access To Selected Users can have access to a customer only as defined by
Customers According To Team rules for customer hierarchy access.
Configuration
Customer Hierarchy Access
Users Have Access To Customers Users can have access to customers and the child
And Their Child Customers customers.
Users Have Access To Their Users can have access to customers who are directly
Customers assigned. (This requires manual user-to-customer
assignment to be configured in the team definition.)
Supervisor Access
Supervisors Have Access To Supervisors can have access to all the customers that
Customers Assigned To Their their team has access to.
Team
Supervisors Have Access To Supervisors can have access to all the customers
Customers Assigned To Their assigned to their team and all child teams.
Team And Child Team

Chapter 5. Configuring User Security 211


Buyer User Access
You can configure access for a buyer user, such as a customer buyer, in the Data
Access Policy Buyer User tab. Refer to Table 63 for field value descriptions.

Table 63. Buyer User Access Policy Rules


Field Description
Customer Access
Default Customer Access
Users Have Access To Data For Buyers can have access to data only for their
Their Customer Organization Only customer organization.
Users Have Access To Data For Buyers have access to data for their customer
Their Customer Organization And organization and child customer organizations.
Child Customer Organizations
Users Have Access To Their Data Buyers can have access to their own data and the
And Data For Subordinate Users data of subordinate users.
Customer Access Exceptions

212 Sterling Selling and Fulfillment Foundation: Application Platform Configuration Guide
Table 63. Buyer User Access Policy Rules (continued)
Field Description
Users Assigned To The Following Select whether buyers can have expanded data
Groups Have Expanded Access access based on their subscription to a group.

Choose to display Group Subscriptions.


Group Subscriptions
Available A list of the available user groups.

To subscribe a user to a user group, select the


applicable user group and choose .
Subscribed A list of the user groups to which the user is
subscribed.

To remove a user from a user group, select the


applicable user group and choose .
Users Have Access To Data For Buyers can have access to data only for their
Their Customer Organization Only customer organization.
Users Have Access To Data For Buyers can have access to data only for their
Their Customer Organization And customer organization and child organizations.
Child Customer Organizations
Assigned Customer Access
Users Have No Assigned Customer Users do not have any assigned customer
Organizations organizations.
Users Have Access To Data Based Users can access data for assigned customers, as
On Their Assigned Customer specified in the Assigned Customer Hierarchy
Organizations Access box.
Assigned Customer Hierarchy Access
Users Have Access To Data For Users can access data for their assigned customers
Their Assigned Customer only.
Organization
Users Have Access To Data For Users can access data for their assigned customers
Their Assigned Customer and child customer organizations.
Organization and Child Customer
Organizations
Anonymous User Access
Users Assigned To The Following Select whether users can have anonymous data
Groups Have Anonymous Access access based on their subscription to a group.

Choose to display Group Subscriptions.


Available A list of the available user groups.

To subscribe a user to a user group, select the


applicable user group and choose .
Subscribed A list of the user groups to which the user is
subscribed.

To remove a user from a user group, select the


applicable user group and choose .

Chapter 5. Configuring User Security 213


Seller User Access
For seller users, the following access rules exist. They are not configurable at this
time. Refer to Table 64 for field value descriptions.

Table 64. Seller User Access Policy Rules


Field Description
Seller Access
Users Have Access To Their Sellers can have access only to their organization.
Organization Only

Node User Access


You can configure node user access in the Data Access Policy Node User tab. Refer
to Table 65 for field value descriptions.

Table 65. Node User Access Policy Rules


Field Description
Node Access
Users Have Access To Their Users have access only to their node.
Node Only
Users Have Access To Nodes Users can have access to any nodes assigned to their
Assigned To Their Team team.

Configuring API Security


You must define access to API resources to control what can be accessed by users
when calling an API.

When calling an API, you must pass through the following two levels of security:
v Authentication with a user ID, a certificate or both. The login API is called
before any other API is called.

214 Sterling Selling and Fulfillment Foundation: Application Platform Configuration Guide
v Authorization, which verifies which resources you can access.

For more information about API security, refer to the Sterling Selling and Fulfillment
Foundation: Customizing APIs.

Note: If you're running Sterling Selling and Fulfillment Foundation components as


Web services with API security enabled, you must expose the Login API as a Web
service. Refer to the Sterling Selling and Fulfillment Foundation Installation Guide for
details about exposing APIs when preparing to build Web services. Additionally,
you must call the Login API, capture the security token that is generated at login,
and then set the token as the "tokenId" in YFSEnvironment. For details about the
YFSEnvironment interface, see the Sterling Selling and Fulfillment Foundation
Javadocs.

Viewing API Security Resources


About this task
To view the list of existing API Security Resources:

Procedure
1. From the tree in the application rules side panel, choose Security > API
Security. The API Security Editor window displays.
2. Expand the APIs or Services branch in All of the APIs and Services for the
Sterling Selling and Fulfillment FoundationSterling Application Platform
3. Select an API or Service. By default, Full Access option is available for an API

or Service. Click to list all of the users who have been granted permission
for an API or Service.

Creating an API Security Resource


About this task

To create an API Security Resource:

Chapter 5. Configuring User Security 215


Procedure
1. From the tree in the application rules side panel, choose Security > API
Security. The API Security Editor window displays.
2. Expand the APIs or Services branch.
3. Select an API for which you want to create new API Security Resource and
click . The Create Api Security Resource window displays.

4. In Resource ID, enter the unique identifier for the API resource.
5. In Description, enter a brief description of the API resource.
6. In Resource Sequence, enter order in which this API resource needs to be
invoked. The output of one API resource may be used as input to another.

7. Choose .

Modifying an API Security Resource:


About this task

Once an API Security Resource has been defined, it can be modified.

To modify an API Security Resource:

Procedure
1. From the tree in the application rules side panel, choose Security > API
Security. The API Security Editor window displays.
2. Expand the APIs or Services branch in All of the APIs and Services for the
Sterling Selling and Fulfillment FoundationSterling Application Platform
3. Select the individual API or Service branch which you want to modify and
choose . The API Security Resource Details window and API Security
Resource Properties window displays.

216 Sterling Selling and Fulfillment Foundation: Application Platform Configuration Guide
4. The API Security Resource Details window displays the various components
associated by default with each API Security Resource. If none of the
components is selected in the API Security Resource Details window, the API
Security Resource Properties window will display the read only information
relates to the selected API Security Resource.
5. Once you select a particular component, the details of that component will
appear in the lower property window.
6. You can configure the following components associated with an API Security
Resource:

Note: When you select Start or End component, the property window This
property screen will simply display the default input apisecurity file and
output apisecurity file respectively in a text area for quick reference. It cannot
be edited, but you can copy the text.

Input Filter
About this task

The Input Filter component provides a mean to edit the API filter input XML.

Chapter 5. Configuring User Security 217


Click to import the default api filter input XML. Click to load the api filter
input XML from a file. Click to load the api filter input XML from string.

To manipulate the Input Filter XML element structure, select the node and click
to add a new child element in the XML tree, and click to add a new attribute
for an element in the XML tree.

Select the appropriate attribute of an element whose value you want to set or
modify and click .

If you want to delete an element or attribute from the XML tree, select the
appropriate element or attribute and click .

If you don't want an attribute to be processed during API call. select the
appropriate attribute and click and if you want to change the status of an
attribute from Unselect to Select, click .

Data Security
About this task

The Data Security component allows you to define a list of XPath expressions that
identify organizations to validate. Click to add a new XPath expression.

Note: Same configuration will be used for both input as well as output API
security.

API
About this task

The API component is used for the API name. It is non-editable.

Output Filter
About this task

The Output Filter component is similar to the Input Filter component except it
provides a mean to edit the API filter output XML.

218 Sterling Selling and Fulfillment Foundation: Application Platform Configuration Guide
Chapter 6. Configuring System Administration Components
You can configure system level information including system level purge criteria,
user exit implementations, and installation rules.

System Administration Components: Defining Purge Criteria


You can define purge criteria rules for data purges not related to specific
document types. Purges are the process by which old data is removed from the
system database. Purges minimize the number of unused database records to
increase search efficiency and reduce the size of the required physical disk.

Table 66 lists the system purge rules provided with the Sterling Selling and
Fulfillment FoundationSterling Application Platform.
Table 66. System-Defined Purge Rules
Retention
Rule Description Days
CAPACITYPRG Purges capacity data. 30
EXPORTTBLPRG Purges data from export tables that are used 30
for publishing data to external systems. This is
a Hub level purge.
IMPORTTBLPRG Purges data from the import tables. This is a 30
Hub level purge.
INBOXPRG Purges the Alert Console messages from the 30
user's inbox. This is a Hub level purge.
INVENTORYPRG Purges inventory information. The inventory 30
purge does not take retention days into
account when purging. All records with
relevant tables with a quantity of 0 are
purged.
MANIFESTPRG Purges manifest information. 30
PERSONINFOHISTPRG Purges historical customer information. 30
PERSONINFOPRG Purges customer information and moves it to 30
a history table.
PRICELISTPRG Purges price lists. 30
REPROCESSPRG Purges any reprocessed information. This is a 30
Hub level purge.
STATTBLPRG Purges statistical information. This is a Hub 30
level purge.
USERACTAUDITPRG Purges all user activity audit data from the 30
system.
USERACTIVITYPRG Purges all user activity data. 30

Modifying a System Purge Criteria Rule


About this task

To modify a purge criteria rule:


© Copyright IBM Corp. 1999, 2011 219
Procedure
1. From the tree in the application rules side panel, choose System Administration
> Purge Criteria. The Purge Criteria List window displays in the work area.

2. Select the applicable purge criteria rule that and choose . The Purge Criteria
Details pop-up window displays.

3. Enter information in the applicable fields. Refer to Table 67 for field value
descriptions.

4. Choose .
Table 67. Purge Criteria Details Pop-Up Window
Field Description
Purge Code Identifies a purge program. This is a system defined code.
Description Describes the type of purge.
Rollback Segment Defines the rollback segment that should be explicitly used
for the purge transaction qualified by the purge code. This is
useful when there are huge logical data sets that have to be
purged. This is optional and used for order related purges.
Retention Days Enter the number of days of data to be retained in the
database (going backwards from the time the program runs).
Make sure that your table size takes into account the number
of retention days entered here.

The inventory purge does not take retention days into


account when purging.
Write to Log File Select this field if you want to log system messages for the
status of the purge. The log can be backed up and used as a
journal at a later date.

220 Sterling Selling and Fulfillment Foundation: Application Platform Configuration Guide
Table 67. Purge Criteria Details Pop-Up Window (continued)
Field Description
Log File Name Enter a log file name. The log file is created in the directory
specified in the yfs.purge.path property. If this is not passed,
it defaults to the value specified in the yfs.properties file. If
a variable is introduced, then the yfs.purge.path is ignored.

To modify this property, add an entry for it in the


<INSTALL_DIR>/properties/customer_overrides.properties
file. For additional information about overriding properties
using the customer_overrides.properties file, see the Sterling
Selling and Fulfillment Foundation: Properties Guide.

For more information about using variables for the log file
directory, see the Sterling Selling and Fulfillment Foundation:
Extending Transactions.

For information about file name limitations related to


internationalization, see the Sterling Selling and Fulfillment
Foundation: Localization Guide.

System Administration Components: Defining User Exit


Implementations
User exits are created to enable business logic extensions to the Sterling Selling and
Fulfillment FoundationSterling Application Platform transactions. Within the
Sterling Selling and Fulfillment FoundationSterling Application Platform
transactions, code exists to invoke user exits so that you may plug-in custom logic.
Since these are pre-defined by Sterling Selling and Fulfillment FoundationSterling
Application Platform, you cannot add or delete user exits. However, you can
configure appropriate implementations for a user exit.

User exits are Java interfaces which can be implemented for creating custom logic
components. Once implemented, they must be configured so that the Sterling
Selling and Fulfillment FoundationSterling Application Platform transactions can
invoke them to perform the necessary logic at runtime. This chapter explains how
to configure user exit implementations within Sterling Selling and Fulfillment
FoundationSterling Application Platform.

Note: If you do not require the Sterling Selling and Fulfillment FoundationSterling
Application Platform transaction extension, you do not need to implement user
exits. If a user exit is not configured, Sterling Selling and Fulfillment
FoundationSterling Application Platform runs its default business logic. User exits
are not relevant when writing custom transactions.

User Exits and Document Types

Document types are a mechanism through which you can manage various business
documents and their life cycle. For more information, see “Document Type
Configuration” on page 119. Sometimes you need different implementations for a
user exit depending on the document type. For example, the
YFSRecalculateHeaderTaxUE user exit allows you to compute order header taxes
using custom logic. If you want your tax computation logic to differ for Sales
Order, Purchase Order, Return, and so forth, you can provide different
implementations for the same user exit at the document type level. Notice that not
all user exits are document type dependent.

Chapter 6. Configuring System Administration Components 221


User Exits and Services

User exits that take XML input and return XML output are service enabled. This
means that for these user exits, instead of writing Java implementations, you can
simply attach a service built through the service builder. At runtime, instead of
invoking the Java class, the Sterling Selling and Fulfillment FoundationSterling
Application Platform transactions invoke the configured service. This allows a
mechanism to build user exit logic in a more declarative fashion than
programmatic.

Guidelines for Usage of User Exits

The following guidelines have to be kept in mind when you are using User Exits
within the Sterling Selling and Fulfillment FoundationSterling Application Platform
API:
v User Exits are structured to return specific information and their usage must be
restricted to such purposes.

Inheritance

You can configure inheritance for resources such as user exits (and their events)
and templates at the Enterprise level. For example, instead of defining a whole
new set of resource configurations, Enterprise "B" may choose to inherit the
resource configuration from Enterprise "A".

You can configure inheritance at the Enterprise level for:

. User Exits

. Templates

Inheritance for User Exits

You can inherit user exit implementations at the Enterprise level.

If a user exit implementation exists for the Enterprise, the system returns that user
exit implementation. But if the user exit implementation is not defined for that
Enterprise, the system checks to see if it inherits configuration from some other
enterprise and uses the inheritance hierarchy to search for the correct user exit
implementation. If no user exit implementation is found, the Hub's implementation
of the user exit for that Enterprise is used.

Inheritance for Events

You can inherit event implementations at the Enterprise level.

Inheritance for Templates

You can inherit the user exit and event templates at the Enterprise level by
specifying the resource identifier for an Enterprise. If the resource identifier is not
specified, it is obtained through the inheritance hierarchy.

222 Sterling Selling and Fulfillment Foundation: Application Platform Configuration Guide
Defining a User Exit
About this task

To configure user exit implementations:

Procedure
1. From the tree in the application rules side panel, choose System Administration
> User Exit Management. The User Exit List window displays in the work area.

If the user exit can be implemented for a document type, the ‘Can Override For
Document Types' column displays ‘Y'. If the user exit can be implemented for
services, the ‘Can Attach Service' column displays ‘Y'. If the user exit is
implemented, the ‘User Exit Implemented' column displays ‘Y'. If the User Exit
can be overridden by an Enterprise, the 'Can Override for Enterprise' column
displays 'Y'.

2. Locate the applicable user exit and choose . The User Exit Details window
displays.

Chapter 6. Configuring System Administration Components 223


The following three fields at the top of the screen are informational and
read-only:
v This User Exit can be overridden for Document Types
v This User Exit can be overridden for an Enterprise
v This User Exit Can Be Designed As a Service
These fields reflect the options selected on the previous screen. The Inherited
User Exit Implementation panel is also informational and read-only. This
panel displays the list of user exits that are inherited by the current
Enterprise from other Enterprises in its hierarchy. For example, consider
three Enterprises, E1, E2, and E3, that have the following hierarchical
relationship:
v Enterprise E1 inherits configurations from Enterprise E2.
v Enterprise E2 inherits configurations from the Enterprise E3.
Because of this hierarchy, Enterprise E1 can view and override all the
configurations that are defined for Enterprise E2 and E3. Enterprise E1 can
also view the configurations defined at the Hub level.
You can add values to the table in the User Exit Implementation List panel.

224 Sterling Selling and Fulfillment Foundation: Application Platform Configuration Guide
3. To add values to the User Exit Implementation List table, choose in the
User Exit Implementation panel. The User Exit Implementation Details
displays. Enter information into the applicable fields. Refer to Table 68 for field
value descriptions.

Table 68. User Exit Implementation Details Fields


Field Description
User Exit Implementation Details
Document Type If the user exit can be implemented for a document type,
select the appropriate document type, if applicable.
Implement As a Service If the user exit can be implemented to use a service and you
are configuring it as such, choose Implement As a Service.
Implement As a Java Class If you are configuring the user exit to be implemented as a
Java class, choose Implement As a Java Class.
Service Name (if selected If you selected Implement As a Service, select the applicable
Implement as Service) service to configure.

Important: Only services defined to return a real-time


response can be selected. For more information about
services, see “Defining Service Definitions” on page 180.
Java Class (if selected If you selected Implement As a Java Class, enter the Java
Implement as Java Class) class as it displays in the User Exit Name field.
Requires Backward Select this field if the user exit requires backward
Compatibility compatibility for another release.
Version If you selected Requires Backward Compatibility, select the
Sterling Selling and Fulfillment FoundationSterling
Application Platform version number that requires user exit
backward compatibility.

Chapter 6. Configuring System Administration Components 225


Table 68. User Exit Implementation Details Fields (continued)
Field Description
Pool Size Indicates total number of concurrent active calls

to User Exit.
Maximum Queue Length The maximum queue length for the number of user exit calls
that wait to become active if the active count is filled up. If
the queue is filled with calls waiting to be active, any new
User Exit requests cause an error.
Wait Time (seconds) Time for which the user exit call waits in queue. If the wait
time exceeds the configured wait time, an exception is
thrown.
User Exit Implementation Enter any additional information regarding user exit
Notes implementation.

System Administration Components: Defining Installation Rules


About this task

You can set up rules that need to be defined when the Hub installs the application.

To set up installation rules:

Procedure
1. From the tree in the application rules side panel, choose System Administration
> Installation Rules. The Installation Rules window displays in the work area.
2. Enter information in the applicable fields. Refer to Table 7–16 for field value
descriptions.

3. Choose .

226 Sterling Selling and Fulfillment Foundation: Application Platform Configuration Guide
Figure 25. Installation Rules

Note: The encryption rules for credit cards and stored value cards are
deprecated.
Table 69. Installation Rules Window
Field Description
Installation
Bar Codes Generated on If checked, the system automatically generates bar codes for
Server all items in the Hub environment.
Encrypt Primary Payment Attributes for the following Payment Type Groups
Note: IBM recommends that payment information entering the system is already tokenized
instead of being encrypted by the following rules.
Credit Card If checked, Sterling Selling and Fulfillment Foundation
encrypts the credit card number in the database.
Note: This field is deprecated. IBM provides an application,
the IBM Sterling Sensitive Data Capture Server, that captures
and tokenizes credit card numbers and store value card
numbers. Review the Sterling Selling and Fulfillment
Foundation: Secure Deployment Guide to understand how to
meet the PCI DSS and PA-DSS requirements.

Chapter 6. Configuring System Administration Components 227


Table 69. Installation Rules Window (continued)
Field Description
Additionally Encrypt Note: The Credit Card field is deprecated. IBM recommends
Credit Card Name And that credit card numbers are tokenized and stored securely in
Credit Card Expiration an external vault system.
Date
If checked, only the Sterling Selling and Fulfillment
FoundationSterling Application PlatformUsers with the
appropriate permissions can view decrypted credit card
numbers. For more information about configuring
permissions, see “Administering User Group Permissions” on
page 194.
Note: Credit Card must be checked first.
Stored Value Card Note: This field is deprecated. IBM recommends that stored
value card numbers are tokenized and stored securely in an
external vault system.

If checked, Sterling Selling and Fulfillment


FoundationSterling Application Platform automatically
encrypts the SVC number, and payment reference 1 in the
database. Only users with the appropriate permissions can
view the decrypted SVC number and payment reference 1.
For more information about configuring permissions, see
“Administering User Group Permissions” on page 194.
Customer Account If checked, Sterling Selling and Fulfillment
FoundationSterling Application Platform automatically
encrypts the customer account number and payment
reference 1 in the database. Only users with the appropriate
permissions can view the decrypted customer account
number and payment reference 1. For more information about
configuring permissions, see “Administering User Group
Permissions” on page 194.
Other If checked, Sterling Selling and Fulfillment
FoundationSterling Application Platform automatically
encrypts the payment reference 1 in the database. Only users
with the appropriate permissions can view the decrypted
payment reference 1. For more information about configuring
permissions, see “Administering User Group Permissions” on
page 194.
Inventory Consolidation Level
Hub Select the Hub option if you want product item IDs to remain
unique across all organizations.

Important: When an organization is created and this option is


selected, the inventory organization is set to the default Hub
organization. This can be changed in the Organization Details
screen for the newly created organization. For more
information about creating a new organization, see “Creating
and Modifying an Organization” on page 23.

228 Sterling Selling and Fulfillment Foundation: Application Platform Configuration Guide
Table 69. Installation Rules Window (continued)
Field Description
Enterprise Select the Enterprise option to allow product item IDs to
repeat across enterprises but still be distinguished within the
inventory model. Also select the Enterprise option if you
want to add this Enterprise organization to a colony different
from the DEFAULT colony.

Important: When creating an Enterprise organization and this


option is selected, the inventory organization is defaulted to
the Enterprise organization you are creating. This can be
changed in the Organization Details screen for the newly
created organization. For more information about creating a
new organization, see “Creating and Modifying an
Organization” on page 23.
Note: If you choose Enterprise, an organization or Enterprise
code must be specified when performing an inventory
adjustment in the Consoles.
Capacity Consolidation Level
Hub Select the Hub option if you want service item IDs to remain
unique across all organizations.

Important: When an organization is created and this option is


selected, the inventory organization is set to the default Hub
organization. This can be changed in the Organization Details
screen for the newly created organization. For more
information about creating a new organization, see “Creating
and Modifying an Organization” on page 23.
Enterprise Select the Enterprise option to allow service item IDs to
repeat across enterprises but still be distinguished within the
inventory model. Also select the Enterprise option if you
want to add this Enterprise organization to a colony different
from the DEFAULT colony.

Important: When creating an Enterprise organization and this


option is selected, the inventory organization is defaulted to
the Enterprise organization you are creating. This can be
changed in the Organization Details screen for the newly
created organization. For more information about creating a
new organization, see “Creating and Modifying an
Organization” on page 23.
Catalog Model
Maintained by Hub Select the Maintained by Hub option if you want the Hub to
set up the a catalog for all of the participants.

Important: When an organization is created and this option is


selected, the catalog organization is set to the default Hub
organization. This can be changed in the Organization Details
screen for the newly created organization. For more
information about creating a new organization, see “Creating
and Modifying an Organization” on page 23.

Chapter 6. Configuring System Administration Components 229


Table 69. Installation Rules Window (continued)
Field Description
Maintained by Enterprise Select the Maintained by Enterprise option if you want the
individual Enterprises to set up the catalog for all of the
participants involved with them.

Important: When an organization is created and this option is


selected, the catalog organization is defaulted to the
organization's primary Enterprise. This can be changed in the
Organization Details screen for the newly created
organization. For more information about creating a new
organization, see “Creating and Modifying an Organization”
on page 23.
Maintained by Participant Select the Maintained by Participant option if you want each
individual participant to maintain their own catalog.

Important: When an organization is created and this option is


selected, the catalog organization is defaulted to the
organization itself. This can be changed in the Organization
Details screen for the newly created organization. For more
information about creating a new organization, see “Creating
and Modifying an Organization” on page 23.
Communication
E-mail Server Name Enter the name of the Hub's e-mail server.
E-mail Protocol Enter the Hub's e-mail protocol.
E-mail Server IP Address Enter the Hub's e-mail server IP address.
E-mail Server Listener Port Enter the Hub's e-mail server listener port.
Item Based Allocation
Item Based Allocation This rule is used to indicate the interval during which the
Agent Execution Interval Item Based Allocation agent should not reprocess the triggers
(hr) that were processed earlier in the YFS_IBA_TRIGGER table.
Backward Compatibility

230 Sterling Selling and Fulfillment Foundation: Application Platform Configuration Guide
Table 69. Installation Rules Window (continued)
Field Description
Use Deprecated Order Check this if you want to use the deprecated order hold
Hold Functionality functionality instead of the enhanced order hold functionality.

For more information about the enhanced order hold


functionality, see the Sterling Selling and Fulfillment Foundation:
Distributed Order Management Configuration Guide.

In the deprecated mode, the order hold functionality works


as follows.

Putting an order on hold freezes the order at its current status


in the sales order fulfillment pipeline. You can place an order
on hold for any reason. For example, you may want to
perform a security check on a particular Buyer, therefore you
place the order on hold until you clear the necessary
information.

The following transactions are not processed when an order


is put on hold:
v Plan Order Complete
v Allocate & Release
v Chained Order Create
v Derived Order Create
v Schedule Order
v Release Order
v Send Release
Note: Held orders are not picked up for scheduling.
Note: If a shipment is created from an order and the order is
then put on hold, the order is still confirmed during shipment
confirmation.
Enable Logical Kit Check this box if you want to enable logical kit functionality.
Functionality By default this box is not checked as bundles is an enhanced
feature of the logical kit.
Is Procurement of Check this box if you want to enable the procurement of
Substitutes Allowed substitutes.

An order gets scheduled and not backordered, if inventory


for the substitutes can be procured.
Create Chained Orders Check this box to create procurement and drop ship orders
Synchronously synchronously when scheduling.

If this rule is enabled, chained orders are created only if the


expected ship date on the child order is within the Advanced
Notification Time of the child orders shipnode.

Chapter 6. Configuring System Administration Components 231


Table 69. Installation Rules Window (continued)
Field Description
Allow Automatic Service Check this box to allow automatic changes in the Service Item
Item Group Change on Group when the Provided Service line is added or removed
Work Order from the work order or when the Service Item Group of a
work order is changed from one type of service to the other.
For example, from a Provided Service to a Delivery Service.

When this box is unchecked, changes cannot be made to the


Service Item Group. For example, if the box is unchecked and
the Provided Service is removed from a work order that
contains the Provided Service, the Delivery Service, and the
Product Item, the work order itself is cancelled. Also, when
the Provided Service is added to a work order that contains
the Delivery Service and the Product Item, a "VAS00002:
Invalid Service Item Group Code" error is thrown.

Note: Existing users who wish to upgrade from an older


version of Yantra 7x or Sterling Supply Chain Applications to
Sterling Selling and Fulfillment Foundation, Release 9.1, but
wish to retain the previous functionality, should not check
this box.
Use Receiving Node's This rule specifies whether the receipt processing time for
Calendar When Applying future inventory and ATP Rule Processing time uses the
Receipt Processing Time node's receiving calendar. If no, then system days are added.
If yes, then the node's receiving calendar days are added.
Enable Extended Item Check this box to extend item validations on orders to
Validation include the following:
v Effective date
v Minimum and maximum quantity
v Item status
v Customer entitlements
v IsSoldSeparately flag
Note: Item validation must be enabled before you extend
validations.
Use Deprecated Pricing Check this box to enable the deprecated pricing functionality
Functionality used prior to Release 9.1 of Sterling Selling and Fulfillment
Foundation.

By default, the deprecated pricing functionality is in effect


after upgrade to Release 9.1. If you uncheck this box after
upgrade to enable the pricing functionality for Release 9.1, be
sure to define your pricing configuration rules in the
Applications ManagerConfigurator and convert your price
lists as described in the Business Center: Pricing Administration
Guide.
Use Deprecated Data Check this box to enable deprecated data access policies used
Access Policy Functionality prior to Release 9.1 across the entire application.

To enable the deprecated data access policies for specific


APIs, see the yfs.properties_ext_ysc.in property.
Note: The application must be restarted to take into effect the
unchecking of this configuration. Clearing of the database
cache is required to take into effect the checking of this
configuration. However, it is recommended to restart the
application for better performance.

232 Sterling Selling and Fulfillment Foundation: Application Platform Configuration Guide
Table 69. Installation Rules Window (continued)
Field Description
Default User's Enterprise Check this box if you want the enterprise code of the user to
from Customer default to the organization code of the customer when you
Organization are creating a customer with a customer contact.
Ship Advice Number Generation
Use Numeric Ship Advice Select this option to use generated numeric values as ship
Number advice numbers.
Maximum Length Of Ship Indicate the maximum length of generated numeric ship
Advice Number advice numbers. Upon reaching the maximum value, the
generation sequence is reset. The default value is 9, the
maximum length allowable.
Note: Due to this constraint, ship advice numbers are not
guaranteed to be unique.
Inventory Tag
Summarize and Maintain Check this checkbox to summarize and maintain total supply
Total Supply and Demand and demand values for tag controlled items.
Values For Tag Controlled
Item This updates the tag descriptors and total supply and
demand fields of inventory tags for tag-controlled items
during inventory updates.
Display User ID
Allow the Display User ID Check this checkbox if you want each User ID to be usable
to be used across all globally across all the enterprises in your deployment. Do not
enterprises check this box if you want each User ID to be unique within
each enterprise.

Creating an Agent Criteria Group


About this task
To create an agent criteria group:

Procedure
1. From the menu bar, choose Applications > Application Platform. The
Application Platform tree displays in the side panel.
2. From the Application Platform tree, choose System Administration > Agent
Criteria Groups. The Agent Criteria Group window displays in the work area.
3. Choose . The Agent Criteria Group Details pop-up window displays.

4. In Agent Criteria Group, enter the agent criteria group name.

Chapter 6. Configuring System Administration Components 233


5. In Short Description, enter the name of the agent criteria group.
6. In Long Description, enter a brief description of the agent criteria group.

7. Choose .

Modifying an Agent Criteria Group


About this task

To modify an agent criteria group:

Procedure
1. From the menu bar, choose Applications > Application Platform. The
Application Platform tree displays in the side panel.
2. From the Application Platform tree, choose System Administration > Agent
Criteria Groups. The Agent Criteria Group window displays in the work area.
3. Select the Agent Criteria Group you want to modify and choose . The Agent
Criteria Group Details pop-up window displays.
4. In Short Description, modify the name of the agent criteria group as needed.
5. In Long Description, modify the brief description of the agent criteria group as
needed.

6. Choose .

Deleting an Agent Criteria Group


About this task

To delete an agent criteria group:

Procedure
1. From the menu bar, choose Applications > Application Platform. The
Application Platform tree displays in the side panel.
2. From the Application Platform tree, choose System Administration > Agent
Criteria Groups. The Agent Criteria Group window displays in the work area.

3. Select the agent criteria group you want to delete and choose .

Defining Initial Context Factory Codes


You can configure additional initial context factory codes to be used to define the
class providing an InitialContext implementation for your application server to
enable remote Java clients to connect. These codes appear in the Initial Context
Factory drop-down field used when configuring time-triggered transactions and
services.

The default initial context factory codes and their class names are:
v WebSphere MQ— com.ibm.websphere.naming.WsnInitialContextFactory
v File—com.sun.jndi.fscontext.RefFSContextFactory
v WebLogic—weblogic.jndi.WLInitialContextFactory
v JBoss—org.jnp.interfaces.NamingContextFactory
v TIBCO—com.tibco.tibcojms.naming.TibjmsInitialContextFactory

234 Sterling Selling and Fulfillment Foundation: Application Platform Configuration Guide
Creating an Initial Context Factory Code
About this task

To create an initial context factory code:

Procedure
1. From the tree in the application rules side panel, choose Nomenclature > Initial
Context Factory Codes. The Initial Context Factory Codes window displays in
the work area.

2. Choose . The Initial Context Factory Details pop-up window displays.

3. In Initial Context Factory, enter the class name to be associated with the code.

Note: The class name must be unique or an error is thrown.


4. In Short Description, enter the name of the initial context factory code as you
want it to appear in the drop-down menus.
5. In Long Description, enter a brief description of the initial context factory code.
6. Choose .

Modifying an Initial Context Factory Code


About this task

To modify an initial context factory code:

Procedure
1. From the tree in the application rules side panel, choose Nomenclature > Initial
Context Factory Codes. The Initial Context Factory Codes window displays in
the work area.

2. Select the code you want to modify and choose . The Initial Context Factory
Details pop-up window displays.
3. In Short Description, enter the name of the initial context factory code as you
want it to appear in the drop-down menus.
4. In Long Description, enter a brief description of the initial context factory code.

5. Choose .

Deleting an Initial Context Factory Code


About this task

To delete an initial context factory code:

Chapter 6. Configuring System Administration Components 235


Procedure
1. From the tree in the application rules side panel, choose Nomenclature > Initial
Context Factory Codes. The Initial Context Factory Codes window displays in
the work area.

2. Select the code you want to delete and choose .

Defining Health Monitor Rules


About this task

You can set up rules that need to be defined for monitoring the health of your
Sterling Selling and Fulfillment FoundationSterling Application Platform.

To set up health monitor rules:

Procedure
1. From the Application Platform tree, choose System Administration > Health
Monitor Rules. The Health Monitor Rules window displays in the work area.
2. Enter information in the applicable fields. Refer to Table 7–16 for field value
descriptions. For more information about the health monitor agent or monitor
thresholds, see the Sterling Selling and Fulfillment Foundation: System Management
and Administration GuidePlatform System Management and Administration Guide.

3. Choose .

Table 70. Health Monitor Rules Window


Field Description
Invoke Service
When Agent/Integration Select a service to run when an agent or integration server
Server Terminates terminates unexpectedly.
Unexpectedly
When Monitoring Select a service to run when a monitoring threshold for API
Threshold Reached or response time, application server response time, agent
Exceeded pending tasks, or JMS queue number of messages is reach or
exceeded for three consecutive health monitor persist
intervals.
When Application Server Select a service to run whenever an application server goes
Goes Down down.

236 Sterling Selling and Fulfillment Foundation: Application Platform Configuration Guide
Viewing the List of Configured Servers
About this task

You can view a list of configured servers for agents and services in the Agent
Server List screen. To view the list of servers:

Procedure
1. From the Application Platform tree in the application rules side panel, choose
System Administration > Configured Servers. The Agent Server List window
displays in the work area as shown below:

Table 71. Agent Server List


Field Description
Server Name The name of the agent server.
Server Type The type of the server. For example, Agent and Service are
valid server types.
Terminate This option specifies whether the server is terminated when
the task is completed.
Monitor Start Time Specifies the monitor start time. This is to ensure that the
(seconds) server does not terminate even before it has completed one
successful execution.
Wait Time (seconds) Specifies the idle wait time before terminating the server.

Note: A server can be deleted only if there are no services or agents configured
to use it.
2. The list of services or agents configured for this server can be viewed by
selecting . Refer to “List of Sub Flows or Criteria ID Configured for Server”
on page 238 to view the services or agent configured on the Server.
3. The factory default agents provided in Sterling Selling and Fulfillment
FoundationSterling Application Platform do not have the "Terminate" option
configured by default.

Chapter 6. Configuring System Administration Components 237


List of Sub Flows or Criteria ID Configured for Server
You can view the list of sub flows or criteria IDs configured for a server in the
Flow List For Server screen. For more information about the field details, see
"Adding a New Server" in Chapter 4, “Configuring Process Models,” on page 119.

Defining Item Configurator Properties


About this task

You must set up a location for the files that are generated by the Item Configurator
when a model item is defined. Additionally, you must define a location for the
property files that are used by the Item Configurator.

To set up the Item Configurator:

Procedure
1. From the Application Platform tree, choose System Administration > Item
Configurator. The Item Configurator window displays in the work area.
2. Enter information in the applicable fields. Refer to Table 72 for field value
descriptions. Platform System Management and Administration Guide

3. Choose .

Table 72. Item Configurator Window


Field Description
Model Repository Specify a location for the model repository. The model
repository stores the compiled XML files that are generated
when a model item is compiled using the Visual Modeler.
You can specify a local or network location.
Location of property files Specify a location for the property files that are used by the
Item Configurator.
Rule Location Specify a location for the Java files that are generated when a
model item is translated using the Item Configurator. These
files define the Item Configurator rules for the model item.

Defining Application Version


You can configure application version and code to be used to define the Qualifier
Version Compatibility for your application. These application codes and versions
appear in the Application Code drop-down field used when configuring qualifier
version compatibility.

238 Sterling Selling and Fulfillment Foundation: Application Platform Configuration Guide
Creating an Application Version
About this task

To create an application version:

Procedure
1. From the tree in the application rules side panel, choose System Administration
> Application Version. The Application Version window displays in the work
area.

2. Choose . The Application Version Details pop-up window displays.

3. In Application Code, enter the code associated with the application as you
want it to appear in the drop-down menus. This is a mandatory field.
4. In Application Version, enter the application version as you want it to appear
in the drop-down menus. This is a mandatory field.
5. In Application Version Description, enter a brief description of the application
version.

6. Choose .

Modifying an Application Version


About this task

To modify an application version:

Procedure
1. From the tree in the application rules side panel, choose System Administration
> Application Version. The Application Version window displays in the work
area.

2. Select the code you want to modify and choose . The Application Version
Details pop-up window displays.
3. In Application Version Description, enter a brief description of the application
version.

4. Choose .

Deleting an Application Version


About this task

To delete an application version:

Chapter 6. Configuring System Administration Components 239


Procedure
1. From the tree in the application rules side panel, choose System Administration
> Application Version. The Application Version window displays in the work
area.

2. Select the application code you want to delete and choose .

240 Sterling Selling and Fulfillment Foundation: Application Platform Configuration Guide
Chapter 7. Configuring Units of Measure
Defining units of measure enables you to set up standard units of measure to
associate with your items and locales. Defining units of measure ensures that each
user sees the data in a familiar format.

Creating a Unit of Measure for Quantity


About this task

To create a unit of measure for quantity:

Procedure
1. From the tree in the application rules side panel, choose Unit of Measure >
Quantity. The Quantity UOMs window displays in the work area.

2. Choose . The Unit of Measure Details window displays.


3. In UOM Code, enter the unit of measure.
4. In UOM Description, enter a brief description of the unit of measure.
5. Choose .

Modifying a Unit of Measure for Quantity


About this task

To modify a unit of measure for quantity:

Procedure
1. From the tree in the application rules side panel, choose Unit of Measure >
Quantity. The Quantity UOMs window displays in the work area.

2. Select the applicable unit of measure and choose . The Unit of Measure
Details window displays.
3. In UOM Description, enter a brief description of the unit of measure.

4. Choose .

Creating a Unit of Measure Conversion Rate for Quantity


About this task

To create a unit of measure conversion for quantity:

Procedure
1. From the tree in the application rules side panel, choose Unit of Measure >
Quantity. The Quantity UOMs window displays in the work area.
2. Select the applicable unit of measure and choose . The UOM Details
window displays.
3. Choose . The UOM Conversion Details window displays.

© Copyright IBM Corp. 1999, 2011 241


4. From Conversion To, select the unit of measure you want to convert to with the
conversion rate.
5. In Conversion Rate, enter the conversion rate between Conversion From to
Conversion To.
6. Choose .

Modifying a Unit of Measure Conversion Rate for Quantity


About this task

To modify a unit of measure conversion for quantity:

Procedure
1. From the tree in the application rules side panel, choose Unit of Measure >
Quantity. The Quantity UOMs window displays in the work area.

2. Select the applicable unit of measure and choose . The UOM Details
window displays.

3. Select the applicable conversion rate and choose . The UOM Conversion
Details window displays.
4. In Conversion Rate, enter the conversion rate between Conversion From to
Conversion To.

5. Choose .

Deleting a Unit of Measure Conversion Rate for Quantity


About this task

To delete a unit of measure conversion for quantity:

Procedure
1. From the tree in the application rules side panel, choose Unit of Measure >
Quantity. The Quantity UOMs window displays in the work area.

2. Select the applicable unit of measure and choose . The UOM Details
window displays.
3. Select the applicable conversion rate and choose .

Deleting a Unit of Measure for Quantity


About this task

To delete a unit of measure for quantity:

Procedure
1. From the tree in the application rules side panel, choose Unit of Measure >
Quantity. The Quantity UOMs window displays in the work area.

2. Select the applicable unit of measure and choose .

242 Sterling Selling and Fulfillment Foundation: Application Platform Configuration Guide
Creating a Unit of Measure for Service Quantity
About this task

To create a unit of measure for service quantity:

Procedure
1. From the tree in the application rules side panel, choose Unit of Measure >
Service Quantity. The Service Quantity UOMs window displays in the work
area.

2. Choose . The Unit of Measure Details window displays.


3. In UOM Code, enter the unit of measure.
4. In UOM Description, enter a brief description of the unit of measure.

5. Choose .

Modifying a Unit of Measure for Service Quantity


About this task

To modify a unit of measure for service quantity:

Procedure
1. From the tree in the application rules side panel, choose Unit of Measure >
Service Quantity. The Service Quantity UOMs window displays in the work
area.

2. Select the applicable unit of measure and choose . The Unit of Measure
Details window displays.
3. In UOM Description, enter a brief description of the unit of measure.
4. Choose .

Creating a Unit of Measure Conversion Rate for Service Quantity


About this task

To create a unit of measure conversion for service quantity:

Procedure
1. From the tree in the application rules side panel, choose Unit of Measure >
Service Quantity. The Service Quantity UOMs window displays in the work
area.
2. Select the applicable unit of measure and choose . The UOM Details
window displays.

3. Choose . The UOM Conversion Details window displays.


4. From Conversion To, select the unit of measure you want to convert to with the
conversion rate.
5. In Conversion Rate, enter the conversion rate between Conversion From to
Conversion To.

6. Choose .

Chapter 7. Configuring Units of Measure 243


Modifying a Unit of Measure Conversion Rate for Service Quantity
About this task

To modify a unit of measure conversion for service quantity:

Procedure
1. From the tree in the application rules side panel, choose Unit of Measure >
Service Quantity. The Service Quantity UOMs window displays in the work
area.

2. Select the applicable unit of measure and choose . The UOM Details
window displays.

3. Select the applicable conversion rate and choose . The UOM Conversion
Details window displays.
4. In Conversion Rate, enter the conversion rate between Conversion From to
Conversion To.
5. Choose .

Deleting a Unit of Measure Conversion Rate for Service Quantity


About this task

To delete a unit of measure conversion for service quantity:

Procedure
1. From the tree in the application rules side panel, choose Unit of Measure >
Service Quantity. The Service Quantity UOMs window displays in the work
area.

2. Select the applicable unit of measure and choose . The UOM Details
window displays.

3. Select the applicable conversion rate and choose .

Deleting a Unit of Measure for Service Quantity


About this task

To delete a unit of measure for service quantity:

Procedure
1. From the tree in the application rules side panel, choose Unit of Measure >
Service Quantity. The Service Quantity UOMs window displays in the work
area.
2. Select the applicable unit of measure and choose .

Creating a Unit of Measure for Dimension


About this task

To create a unit of measure for dimension:

244 Sterling Selling and Fulfillment Foundation: Application Platform Configuration Guide
Procedure
1. From the tree in the application rules side panel, choose Unit of Measure >
Dimension. The Dimension UOMs window displays in the work area.

2. Choose . The Unit of Measure Details window displays.


3. In UOM Code, enter the unit of measure.
4. In UOM Description, enter a brief description of the unit of measure.
5. From Volume UOM Code, select the volume unit of measure that corresponds
to the volume measurement for this dimension. For example, choose cubic
inches if the dimension unit of measure is inches.

6. Choose .

Modifying a Unit of Measure for Dimension


About this task
To modify a unit of measure for dimension:

Procedure
1. From the tree in the application rules side panel, choose Unit of Measure >
Dimension. The Dimension UOMs window displays in the work area.

2. Select the applicable unit of measure and choose . The Unit of Measure
Details window displays.
3. In UOM Description, enter a brief description of the unit of measure.
4. Choose .

Creating a Unit of Measure Conversion Rate for Dimension


About this task

To create a unit of measure conversion for dimension:

Procedure
1. From the tree in the application rules side panel, choose Unit of Measure >
Dimension. The Dimension UOMs window displays in the work area.

2. Select the applicable unit of measure and choose . The UOM Details
window displays.

3. Choose . The UOM Conversion Details window displays.


4. From Conversion To, select the unit of measure you want to convert to with the
conversion rate.
5. In Conversion Rate, enter the conversion rate between Conversion From to
Conversion To.

6. Choose .

Modifying a Unit of Measure Conversion Rate for Dimension


About this task

To modify a unit of measure conversion for dimension:

Chapter 7. Configuring Units of Measure 245


Procedure
1. From the tree in the application rules side panel, choose Unit of Measure >
Dimension. The Dimension UOMs window displays in the work area.

2. Select the applicable unit of measure and choose . The UOM Details
window displays.

3. Select the applicable conversion rate and choose . The UOM Conversion
Details window displays.
4. In Conversion Rate, enter the conversion rate between Conversion From to
Conversion To.
5. Choose .

Deleting a Unit of Measure Conversion Rate for Dimension


About this task

To delete a unit of measure conversion for dimension:

Procedure
1. From the tree in the application rules side panel, choose Unit of Measure >
Dimension. The Dimension UOMs window displays in the work area.

2. Select the applicable unit of measure and choose . The UOM Details
window displays.

3. Select the applicable conversion rate and choose .

Deleting a Unit of Measure for Dimension


About this task

To delete a unit of measure for dimension:

Procedure
1. From the tree in the application rules side panel, choose Unit of Measure >
Dimension. The Dimension UOMs window displays in the work area.

2. Select the applicable unit of measure and choose .

Creating a Unit of Measure for Volume


About this task

To create a unit of measure for volume:

Procedure
1. From the tree in the application rules side panel, choose Unit of Measure >
Volume. The Volume UOMs window displays in the work area.

2. Choose . The Unit of Measure Details window displays.


3. In UOM Code, enter the unit of measure.
4. In UOM Description, enter a brief description of the unit of measure.

5. Choose .

246 Sterling Selling and Fulfillment Foundation: Application Platform Configuration Guide
Modifying a Unit of Measure for Volume
About this task

To modify a unit of measure for volume:

Procedure
1. From the tree in the application rules side panel, choose Unit of Measure >
Volume. The Volume UOMs window displays in the work area.

2. Select the applicable unit of measure to modify and choose . The Unit of
Measure Details window displays.
3. In UOM Description, enter a brief description of the unit of measure.

4. Choose .

Creating a Unit of Measure Conversion Rate for Volume


About this task

To create a unit of measure conversion for volume:

Procedure
1. From the tree in the application rules side panel, choose Unit of Measure >
Volume. The Volume UOMs window displays in the work area.

2. Select the applicable unit of measure and choose . The UOM Details
window displays.

3. Choose . The UOM Conversion Details window displays.


4. From Conversion To, select the unit of measure you want to convert to with the
conversion rate.
5. In Conversion Rate, enter the conversion rate between Conversion From to
Conversion To.
6. Choose .

Modifying a Unit of Measure Conversion Rate for Volume


About this task

To modify a unit of measure conversion for volume:

Procedure
1. From the tree in the application rules side panel, choose Unit of Measure >
Volume. The Volume UOMs window displays in the work area.

2. Select the applicable unit of measure and choose . The UOM Details
window displays.

3. Select the applicable conversion rate and choose . The UOM Conversion
Details window displays.
4. In Conversion Rate, enter the conversion rate between Conversion From to
Conversion To.
5. Choose .

Chapter 7. Configuring Units of Measure 247


Deleting a Unit of Measure Conversion Rate for Volume
About this task

To delete a unit of measure conversion for volume:

Procedure
1. From the tree in the application rules side panel, choose Unit of Measure >
Volume. The Volume UOMs window displays in the work area.

2. Select the applicable unit of measure and choose . The UOM Details
window displays.

3. Select the applicable conversion rate and choose .

Deleting a Unit of Measure for Volume


About this task

To delete a unit of measure for volume:

Procedure
1. From the tree in the application rules side panel, choose Unit of Measure >
Volume. The Volume UOMs window displays in the work area.

2. Select the applicable unit of measure and choose .

Creating a Unit of Measure for Weight


About this task

To create a unit of measure for weight:

Procedure
1. From the tree in the application rules side panel, choose Unit of Measure >
Weight. The Weight UOMs window displays in the work area.

2. Choose . The Unit of Measure Details window displays.


3. In UOM Code, enter the unit of measure.
4. In UOM Description, enter a brief description of the unit of measure.

5. Choose .

Modifying a Unit of Measure for Weight


About this task

To modify a unit of measure for weight:

Procedure
1. From the tree in the application rules side panel, choose Unit of Measure >
Weight. The Weight UOMs window displays in the work area.

2. Select the applicable unit of measure and choose . The Unit of Measure
Details window displays.
3. In UOM Description, enter a brief description of the unit of measure.

248 Sterling Selling and Fulfillment Foundation: Application Platform Configuration Guide
4. Choose .

Creating a Unit of Measure Conversion Rate for Weight


About this task

To create a unit of measure conversion for weight:

Procedure
1. From the tree in the application rules side panel, choose Unit of Measure >
Weight. The Weight UOMs window displays in the work area.

2. Select the applicable unit of measure and choose . The UOM Details
window displays.

3. Choose . The UOM Conversion Details window displays.


4. From Conversion To, select the unit of measure you want to convert to with the
conversion rate.
5. In Conversion Rate, enter the conversion rate between Conversion From to
Conversion To.

6. Choose .

Modifying a Unit of Measure Conversion Rate for Weight


About this task

To modify a unit of measure conversion for weight:

Procedure
1. From the tree in the application rules side panel, choose Unit of Measure >
Weight. The Weight UOMs window displays in the work area.

2. Select the applicable unit of measure and choose . The UOM Details
window displays.
3. Select the applicable conversion rate and choose . The UOM Conversion
Details window displays.
4. In Conversion Rate, enter the conversion rate between Conversion From to
Conversion To.

5. Choose .

Deleting a Unit of Measure Conversion Rate for Weight


About this task

To delete a unit of measure conversion for weight:

Procedure
1. From the tree in the application rules side panel, choose Unit of Measure >
Weight. The Weight UOMs window displays in the work area.

2. Select the applicable unit of measure and choose . The UOM Details
window displays.

Chapter 7. Configuring Units of Measure 249


3. Select the applicable conversion rate and choose .

Deleting a Unit of Measure for Weight


About this task

To delete a unit of measure for weight:

Procedure
1. From the tree in the application rules side panel, choose Unit of Measure >
Weight. The Weight UOMs window displays in the work area.

2. Select the applicable unit of measure and choose .

Creating a Unit of Measure for Time


About this task

To create a unit of measure for time:

Procedure
1. From the tree in the application rules side panel, choose Unit of Measure >
Time. The Time UOMs window displays in the work area.

2. Choose . The Unit of Measure Details window displays.


3. In UOM Code, enter the unit of measure.
4. In UOM Description, enter a brief description of the unit of measure.

5. Choose .

Modifying a Unit of Measure for Time


About this task

To modify a unit of measure for time:

Procedure
1. From the tree in the application rules side panel, choose Unit of Measure >
Time. The Time UOMs window displays in the work area.

2. Select the applicable unit of measure and choose . The Unit of Measure
Details window displays.
3. In UOM Description, enter a brief description of the unit of measure.

4. Choose .

Creating a Unit of Measure Conversion Rate for Time


About this task

To create a unit of measure conversion for time:

Procedure
1. From the tree in the application rules side panel, choose Unit of Measure >
Time. The Time UOMs window displays in the work area.

250 Sterling Selling and Fulfillment Foundation: Application Platform Configuration Guide
2. Select the applicable unit of measure and choose . The UOM Details
window displays.

3. Choose . The UOM Conversion Details window displays.


4. From Conversion To, select the unit of measure you want to convert to with the
conversion rate.
5. In Conversion Rate, enter the conversion rate between Conversion From to
Conversion To.

6. Choose .

Modifying a Unit of Measure Conversion Rate for Time


About this task

To modify a unit of measure conversion for time:

Procedure
1. From the tree in the application rules side panel, choose Unit of Measure >
Time. The Time UOMs window displays in the work area.

2. Select the applicable unit of measure and choose . The UOM Details
window displays.

3. Select the applicable conversion rate and choose . The UOM Conversion
Details window displays.
4. In Conversion Rate, enter the conversion rate between Conversion From to
Conversion To.

5. Choose .

Deleting a Unit of Measure Conversion Rate for Time


About this task

To delete a unit of measure conversion for time:

Procedure
1. From the tree in the application rules side panel, choose Unit of Measure >
Time. The Time UOMs window displays in the work area.

2. Select the applicable unit of measure and choose . The UOM Conversion
Details window displays.

3. Select the applicable conversion rate and choose .

Deleting a Unit of Measure for Time


About this task

To delete a unit of measure for time:

Procedure
1. From the tree in the application rules side panel, choose Unit of Measure >
Time. The Time UOMs window displays in the work area.

Chapter 7. Configuring Units of Measure 251


2. Select the applicable unit of measure and choose .

252 Sterling Selling and Fulfillment Foundation: Application Platform Configuration Guide
Chapter 8. Configuring Internationalization Rules
Internationalization rules are used to set up rules and common codes associated
with making Sterling Selling and Fulfillment FoundationSterling Application
Platform functional for international use.

Defining Country or Region Codes


You can use the Countries branch to set up the following common codes:
v Country or region codes. This common code identifies the country or region that
the locale is located in. The following are examples of country or region codes:
– US (United States)
– FR (France)
– GB (United Kingdom)
v Short zip code regex. This common code converts long zip codes to a simplified
format. The short zip code format is used by the best region schema matching
mechanism for features such as reports, sourcing, and resource pools. T

Creating a Country or Region Code Definition


About this task

To create a country or region code definition:

Procedure
1. From the tree in the application rules side panel, choose Internationalization >
Countries. The Country/Region Codes window displays in the work area.

2. Choose . The Country/Region Details pop-up window displays.


3. In Country/Region, enter a two character country or region code definition.

Note: The country or region code should be in accordance with the


International Standard Organization (ISO) specifications (the two character code
in the ISO 3166-1 document).
4. In Short Description, enter a brief description of the country or region code
definition.
5. In Long Description, enter a more detailed description of the country or region
code definition.
6. In Short Zip Code RegEx, enter the regular expression for short zip codes for
this country or region. If you specify a grouping for the regular expression,
Sterling Selling and Fulfillment Foundation matches the zip code with the
regular expression in the first parenthesis to define a short zip code. However,
if no grouping is specified, Sterling Selling and Fulfillment Foundation uses the
first characters that match the entire regular expression. For example, if the zip
code has five characters, Sterling Selling and Fulfillment Foundation matches
the first five characters to the regular expression. See the Javadocs for the
java.util.regex.Pattern class for more information about regular expressions.

Note: If you enter a regular expression with too many characters that require
escaping, you may receive a database error. Sterling Selling and Fulfillment

© Copyright IBM Corp. 1999, 2011 253


Foundation recommends using an alternative to the POSIX character classes,
which can exceed database limits due to their long length.

7. Choose .

Modifying a Country or Region Code Definition


About this task

To modify a country or region code definition:

Procedure
1. From the tree in the application rules side panel, choose Internationalization >
Countries. The Country/Region Codes window displays in the work area.

2. Select the applicable country or region code definition and choose . The
Country/Region Details pop-up window displays.
3. In Short Description, enter a brief description of the country or region code
definition.
4. In Long Description, enter a more detailed description of the country or region
code definition.
5. In Short Zip Code RegEx, enter the regular expression for short zip codes for
this country or region. If you specify a grouping for the regular expression,
Sterling Selling and Fulfillment Foundation matches the zip code with the
regular expression in the first parenthesis to define a short zip code. However,
if no grouping is specified, Sterling Selling and Fulfillment Foundation uses the
first characters that match the entire regular expression. For example, if the zip
code has five characters, Sterling Selling and Fulfillment Foundation matches
the first five characters to the regular expression. See the Javadocs for the
java.util.regex.Pattern class for more information about regular expressions.

Note: If you enter a regular expression with too many characters that require
escaping, you may receive a database error. Sterling Selling and Fulfillment
Foundation recommends using an alternative to the POSIX character classes,
which can exceed database limits due to their long length.

6. Choose .

Deleting a Country or Region Code Definition


About this task

To delete a country or region code definition:

Procedure
1. From the tree in the application rules side panel, choose Internationalization >
Countries. The Country/Region Codes window displays in the work area.

2. Select the applicable country or region code definition and choose .

Defining Language Codes


You can set up common codes for language definitions used when setting up
locales. This common code identifies the language used in the locale. You can
create, modify, and delete language definitions.

254 Sterling Selling and Fulfillment Foundation: Application Platform Configuration Guide
Following is the Sterling Selling and Fulfillment FoundationSterling Application
Platform default language definition:
v EN (English)

Creating a Language Definition


About this task

To create a language definition:

Procedure
1. From the tree in the application rules side panel, choose Internationalization >
Languages. The Language Codes window displays in the work area.

2. Choose . The Language Definition Details pop-up window displays.

3. In Language Definition, enter a two character language definition

Note: The language definition should be in accordance with the International


Standard Organization (ISO) specifications (the two character code from the
ISO 639 document).
4. In Short Description, enter a brief description of the language definition.
5. In Long Description, enter a more detailed description of the language
definition.

6. Choose .

Modifying a Language Definition


About this task

To modify a language definition:

Procedure
1. From the tree in the application rules side panel, choose Internationalization >
Languages. The Language Codes window displays in the work area.

2. Select the applicable language definition and choose . The Language


Definition Details pop-up window displays.
3. In Short Description, enter a brief description of the language definition.
4. In Long Description, enter a more detailed description of the language
definition.

5. Choose .

Chapter 8. Configuring Internationalization Rules 255


Deleting a Language Definition
About this task

To delete a language definition:

Procedure
1. From the tree in the application rules side panel, choose Internationalization >
Languages. The Language Codes window displays in the work area.

2. Select the applicable language definition and choose .

Defining Date Formats


You can set up common code formats for date formats used when setting up
locales. This common code format identifies how dates are entered at a locale. You
can create, modify, and delete date formats.

The following are examples of date formats:


v MM/dd/yyyy
v dd/MM/yyyy

Creating a Date Format


About this task

To create a date format:

Procedure
1. From the tree in the application rules side panel, choose Internationalization >
Date Formats. The Date Formats window displays in the work area.

2. Choose . The Date Format Details pop-up window displays.

3. In Date Format, enter the date format using ‘M' to stand for month, ‘d' to stand
for day, and ‘y' to stand for year.
4. In Short Description, enter a brief description of the date format.
5. In Long Description, enter a more detailed description of the date format.

6. Choose .

Modifying a Date Format


About this task

To modify a date format:

256 Sterling Selling and Fulfillment Foundation: Application Platform Configuration Guide
Procedure
1. From the tree in the application rules side panel, choose Internationalization >
Date Formats. The Date Formats window displays in the work area.

2. Select the applicable date format and choose . The Date Format Details
pop-up window displays.
3. In Short Description, enter a brief description of the date format.
4. In Long Description, enter a more detailed description of the date format.

5. Choose .

Deleting a Date Format


About this task

To delete a date format:

Procedure
1. From the tree in the application rules side panel, choose Internationalization >
Date Formats. The Date Formats window displays in the work area.

2. Select the applicable date format and choose .

Defining Time Formats


You can set up common code formats for time formats used when setting up
locales. This common code format identifies how times are entered at a locale. You
can create, modify, and delete time formats.

Note: Sterling Selling and Fulfillment FoundationSterling Application Platform


uses Java time/date conventions. For example, if you enter hh for hour you are
indicating you want to use a 12 hour clock. If you enter HH for hour you are
indicating you want to use a 24 hour clock. However, the application only
supports the 24 hour clock.

Creating a Time Format


About this task

To create a time format:

Procedure
1. From the tree in the application rules side panel, choose Internationalization >
Time Formats. The Time Formats window displays in the work area.

2. Choose . The Time Format Details pop-up window displays.

Chapter 8. Configuring Internationalization Rules 257


3. In Time Format, enter the date format using ‘H' to stand for hour, ‘m' to stand
for minute, and ‘s' to stand for second.
4. In Short Description, enter a brief description of the time format.
5. In Long Description, enter a more detailed description of the time format.

6. Choose .

Modifying a Time Format


About this task

To modify a time format:

Procedure
1. From the tree in the application rules side panel, choose Internationalization >
Time Formats. The Time Formats window displays in the work area.

2. Select the applicable time format and choose . The Time Format Details
pop-up window displays.
3. In Short Description, enter a brief description of the time format.
4. In Long Description, enter a more detailed description of the time format.

5. Choose .

Deleting a Time Format


About this task

To delete a time format:

Procedure
1. From the tree in the application rules side panel, choose Internationalization >
Time Formats. The Time Formats window displays in the work area.

2. Select the applicable time format and choose .

Defining Date/Time Formats


You can set up common code formats for date/time formats used when setting up
locales. This common code format identifies how dates with time are entered at a
locale. You can create, modify, and delete date/time formats.

Note: Sterling Selling and Fulfillment FoundationSterling Application Platform


uses Java time/date conventions. For example, if you enter hh for hour you are

258 Sterling Selling and Fulfillment Foundation: Application Platform Configuration Guide
indicating you want to use a 12 hour clock. If you enter HH for hour you are
indicating you want to use a 24 hour clock. However, the application only
supports the 24 hour clock.

Creating a Date/Time Format


About this task

To create a date/time format:

Procedure
1. From the tree in the application rules side panel, choose Internationalization >
Date Time Formats. The Time Formats window displays in the work area.

2. Choose . The Date/Time Format Details pop-up window displays.

3. In Date/Time Format, enter the date/time format using ‘M' to stand for month,
‘d' to stand for day, ‘y' to stand for year, ‘h' to stand for hour, ‘m' to stand for
minute, and ‘s' to stand for second.
4. In Short Description, enter a brief description of the date/time format.
5. In Long Description, enter a more detailed description of the date/time format.

6. Choose .

Modifying a Date/Time Format


About this task
To modify a date/time format:

Procedure
1. From the tree in the application rules side panel, choose Internationalization >
Date Time Formats. The Time Formats window displays in the work area.

2. Select the applicable date/time format and choose . The Date/Time Format
Details pop-up window displays.
3. In Short Description, enter a brief description of the date/time format.
4. In Long Description, enter a more detailed description of the date/time format.

5. Choose .

Deleting a Date/Time Format


About this task

To delete a date/time format:

Chapter 8. Configuring Internationalization Rules 259


Procedure
1. From the tree in the application rules side panel, choose Internationalization >
Date Time Formats. The Time Formats window displays in the work area.

2. Select the applicable date/time format and choose .

Defining Currency Definitions


Currency Definitions define each currency’s symbols and indicate Euro currency
membership and expiration date, if applicable. You can also set rules for an order’s
currency conversion and euro conversion.

The Euro currency is part of the plan to convert all of the European nations to one
defined currency. The following countries’ use the euro as their currency as of
August 2003:
v Austria
v Belgium
v Finland
v France
v Germany
v Ireland
v Italy
v Luxembourg
v The Netherlands
v Portugal
v Spain

Creating a Currency Definition


About this task

To create currency definitions:

Procedure
1. From the tree in the application rules side panel, choose Internationalization >
Currency Definitions. The Currency Definition window displays in the work
area.
2. Choose . The Currency Details pop-up window displays.
3. Enter information in the applicable fields. Refer to the following table for field
value descriptions.

4. Choose .

260 Sterling Selling and Fulfillment Foundation: Application Platform Configuration Guide
Table 73. Currency Details Pop-Up Window
Field Description
Currency Enter the name of the currency.
Description Enter a brief description of the currency.
Prefix Symbol Enter the symbol that precedes the currency amount (if
applicable).
Postfix Symbol Enter the symbol that follows the currency amount (if
applicable).
Euro Member Select the check box if the currency is a Euro Member
Currency.
Expiration Date If Euro Member is selected, enter the date that the currency is
set to expire. For example, if you are creating a currency
definition for one of the original 11 Euro Members, enter
`01/01/2002'.

Modifying a Currency Definition


About this task

To modify currency definitions:

Procedure
1. From the tree in the application rules side panel, choose Internationalization >
Currency Definitions. The Currency Definition window displays in the work
area.

2. Select the applicable currency definition and choose . The Currency Details
pop-up window displays.
3. Enter information in the applicable fields.

4. Choose

Deleting a Currency Definition


About this task

To delete currency definitions:

Chapter 8. Configuring Internationalization Rules 261


Procedure
1. From the tree in the application rules side panel, choose Internationalization >
Currency Definitions. The Currency Definition window displays in the work
area.

2. Select the applicable currency definition and choose .

Defining the Default Reporting Conversion Rate and Euro


Currency Code
About this task

To define the default reporting conversion rate and euro currency code:

Procedure
1. From the tree in the application rules side panel, choose Internationalization >
Currency Definitions. The Currency Definition window displays in the work
area.
2. Check Default Reporting Conversion Rate to default the reporting conversion
rate on the order at the time it is created.
3. From Euro Currency Code, select the currency to represent the euro currency in
conversions, if applicable.

Defining Currency Conversions


Currency Conversion enables you to set up exchange rates from one currency to
another.

Exchange rates are used to translate between currencies used by organizations as


defined by their locale. The exchange rate is stored as part of the order document
type when it is created. The stored exchange rate can be reassessed, based on
fluctuating currency markets or any time the price of an order changes, such as
when you cancel a line, add quantity, or add a charge.

Creating a Currency Conversion


About this task

To create a currency conversion:

Procedure
1. From the tree in the application rules side panel, choose Internationalization >
Currency Conversions. The Currency Conversion window displays in the work
area.

2. Choose . The Currency Conversion Details window displays.


3. Enter information in the applicable fields. Refer to Table 7–18 for field value
descriptions.
4. Choose .

262 Sterling Selling and Fulfillment Foundation: Application Platform Configuration Guide
Table 74. Currency Conversion Details
Field Description
Base Currency Select the currency you want to convert to and from.
Effective From Enter the beginning day on which the exchange rate is valid.
Effective To Enter the last day on which the exchange rate is valid.
Other Currency Select a currency to use for conversion with the base
currency.
Conversion Rate From Base Enter the conversion rate from the Base Currency to the
Other Currency.
Conversion Rate To Base Enter the conversion rate from the Other Currency to the
Base Currency.

Modifying a Currency Conversion


About this task

To modify a currency conversion:

Procedure
1. From the tree in the application rules side panel, choose Internationalization >
Currency Conversions. The Currency Conversion window displays in the work
area.

2. Select the applicable currency conversion and choose . The Currency


Conversion Details window displays.
3. Enter information in the applicable fields. Refer to Table 7–18 for field value
descriptions.

4. Choose .

Chapter 8. Configuring Internationalization Rules 263


Deleting a Currency Conversion
About this task

To delete a currency conversion:

Procedure
1. From the tree in the application rules side panel, choose Internationalization >
Currency Conversions. The Currency Conversion window displays in the work
area.

2. Select the applicable currency conversion and choose .

264 Sterling Selling and Fulfillment Foundation: Application Platform Configuration Guide
Chapter 9. Configuring Presentation Components
The Presentation Framework provides an interface that enables you to customize
the graphical user interface.

Defining Locales
You can set up locales and associate them with multiple organizations and users
within the Hub. Locales are only established by the Hub. A locale defines a set of
standards that enable people within a geographic area to communicate and
conduct business transactions in a unambiguous way. For example, the locale
defines the unique time zone, language, date/time format, currency, and units of
measurement for a specific geographical area.

Locale standards enable international organizations to interact globally and ensure


that UOM, currency conversions, and time zones calculations are taken into
consideration during a transaction. For example, the following locale definitions for
organizations in San Francisco and Tokyo enable them to transact business with
each other:

Figure 26. San Francisco, United States

v Locale - California
v Country/Region - United States
v Language - English
v Date/Time - DD/MM/YYYY; HH:MM:SS
v Time Zone - GMT-8:00
v Currency - Dollar
v Unit of Measure - Inch/Pound

Figure 27. Tokyo, Japan

v Locale - Tokyo
v Country/Region - Japan
v Language - Japanese
v Date/Time - DD/MM/YYYY; HH:MM:SS
v Time Zone - GMT+9:00
v Currency - Yen
v Unit of Measure - Meter/Kilogram

Creating a Locale
About this task

To create a locale:

Procedure
1. From the tree in the application rules side panel, choose Presentation > Locales.
The Locale window displays in the work area.

© Copyright IBM Corp. 1999, 2011 265


2. Choose . The Locale Details window displays.
3. Enter information in the applicable fields. Refer to Table 75 for assistance.

4. Choose .
Table 75. Locale Details Window
Field Description
Locale Code Enter the name of the locale as you want it to appear
throughout Sterling Selling and Fulfillment
FoundationSterling Application Platform. Cannot contain
spaces. The recommended syntax is to join the entries for
Country/Region and Language with an underscore. For
example, use fr_CA to represent Canadian French.
Locale Description Enter a brief description of the locale.
Country/Region Select the country or region. Using the two-character
upper-case ISO-3166 code is recommended. For example,
enter CA for Canada.
Time Zone Select the time zone of the locale.
Variant Enter the locale variant.
Language Select the language spoken in the locale. Using the
two-character lower-case ISO-639 code is recommended. For
example, enter fr for French.
Currency Select the currency used in the locale.
Dimension UOM Select the unit of measure the locale uses for dimension.
Volume UOM Select the unit of measure the locale uses for volume.
Weight UOM Select the unit of measure the locale uses for weight.
Date and Time Formats
Date Time Format Select the date/time format used in the locale.
Date Format Select the date format used in the locale.
Month Display Date Select the date format that should be used when a month
Format displays.
Day Display Date Format Select the date format that should be used when a day of
week displays.
Time Format Select the time format used in the locale.
Hour/Minute Time Format Select the time format that should be used when a time
consisting of an hour and minutes displays.
Date/Hour/Minute Format Select the date/time format that should be used when a that
should be used when a date and time (consisting of an hour
and minutes) displays.
Client Time Format Select the time format used in the locale. It also supports
AM/PM time format.
Note: This field is applicable only for Rich Client Platform
applications.
Client Date Time Format Select the date/time format used in the locale. It also
supports AM/PM time format.
Note: This field is applicable only for Rich Client Platform
applications.

266 Sterling Selling and Fulfillment Foundation: Application Platform Configuration Guide
Modifying a Locale
About this task

To modify a locale:

Procedure
1. From the tree in the application rules side panel, choose Presentation > Locales.
The Locale window displays in the work area.

2. Select the applicable locale and choose . The Locale Details window
displays.
3. Enter information in the applicable fields. Refer to Table 75 on page 266 for
assistance.
4. Choose .

Deleting a Locale
About this task

To delete a locale:

Procedure
1. From the tree in the application rules side panel, choose Presentation > Locales.
The Locale window displays in the work area.

2. Select the applicable locale and choose .

Defining Menus
You can define the menu (and screen structure) a user sees. Menu configuration
contains the standard Sterling Selling and Fulfillment FoundationSterling
Application Platform resources as well as the ones that you define when
configuring resources.

All menus are grouped into a menu group. The default menu group contains the
standard menu configuration of the Application ConsoleConsole.

No other applications can be added.

This default group is linked to the default Administrator user. When creating your
own users, you can reuse this menu group or create a completely new menu
group. Your own custom menus may contain different menu items.

Saving a Menu Group as a New Menu Grouping


About this task

You can save an existing menu group as a new customizable menu group.

To save a menu group as a new menu grouping:

Procedure
1. From the tree in the application rules side panel, choose Presentation → Menu.
The Menu Hierarchy window displays in the work area.

Chapter 9. Configuring Presentation Components 267


2. Select the applicable menu group and choose . The Menu Group Details
pop-up window displays.

3. In Menu Group, enter the menu group name using the resource key used in
the resource bundle.
4. In Description, enter the name of the menu group as you want it to appear in
the menu hierarchy interface.
5. Choose .

Modifying Application Menu Details


About this task

You can modify the name of the application menu as it displays in the menu
hierarchy.

To modify the Application Menu details:

Procedure
1. From the tree in the application rules side panel, choose Presentation > Menu.
The Menu Hierarchy window displays in the work area.
2. Expand the applicable menu group branch.
3. Select the applicable application menu and choose . The Application Menu
Details pop-up window displays.

4. In Description, enter the name of the application menu as you want it to


appear in the menu hierarchy interface.

5. Choose .

Defining Submenus
You can create submenu for a given menu item only if you have not provided the
resource key for that menu item (i.e. the resource key is empty or null).

268 Sterling Selling and Fulfillment Foundation: Application Platform Configuration Guide
To create a submenu for a menu item, when you create a new menu item, you
must leave the Resource ID attribute empty. For more information about defining
menu items, see “Defining Menu Items.”

Note: By default, submenus are not displayed on the UI for a given menu item.
You must enable submenus in the UI by adding some context parameters to the
<module_id>_config.xml file. For more information about enabling submenus in
the UI, see Sterling Selling and Fulfillment Foundation: Customizing Console JSP
Interface for End-User .

Defining Menu Items


The menu hierarchy contains a list of all possible menu items you can provide to a
user. You can create, modify, and delete menu items.

Creating a Menu Item


About this task

To create a menu item:

Procedure
1. From the tree in the application rules side panel, choose Presentation > Menu.
The Menu Hierarchy window displays in the work area.
2. Expand the applicable menu group branch.
3. Expand the applicable application menu.

4. Choose . The Menu Item Details pop-up window displays.


5. Enter information in the applicable fields. Refer to the Menu Item Details
Pop-Up Window table for field value descriptions.
6. Choose .

Table 76. Menu Item Details Pop-Up Window


Control Description
Menu ID Enter a value identifier for this menu option.
Description Enter a value to correlate with the on-screen literals stored in
the resource bundles.

Chapter 9. Configuring Presentation Components 269


Table 76. Menu Item Details Pop-Up Window (continued)
Control Description
Icon Enter a relative path to any images associated with the menu
item. The image is picked up from an image .jar file, so
specify these images as follows:
v The default icons are located in the <INSTALL_DIR>/jar/
<install_dir_name>/<version>/
<application>scfoundationiconsbe.jar file. Inside the
.jar file, many of the icons are located in the
<INSTALL_DIR>/repository/eardata/
smcfs<application_name>/war/console/icons directory.

The image is shown before the text in the UI.


Menu Sequence Enter the menu sequence of the menu item. The sequence
number is used to order the way menus appear at one level.
By changing the menu sequence, you can switch the order.
Resource ID Enter the resource ID of the menu item.

When a menu is tagged to an entity's resource ID in by


default it means that when the user clicks on that menu on
the screen it takes you to the first Search view available
under that entity in the Resource Hierarchy tree.

The resource ID contains details about the screen that needs


to be invoked when the menu item is selected. The results on
the search window for this field shows all resources that are
either detail view resources or entity resources.
Note: If a resource of type Detail View is selected, the detail
view is invoked when the menu is selected.

If a resource of type entity is selected, the default search view


of that entity is invoked.Note: If you want to create a
submenu for this menu item leave this field empty.

Modifying a Menu Item


About this task

To modify a menu item:

Procedure
1. From the tree in the application rules side panel, choose Presentation > Menu.
The Menu Hierarchy window displays in the work area.
2. Expand the applicable menu group branch.
3. Expand the applicable application menu.

4. Select the applicable menu item and choose . The Menu Item Details pop-up
window displays.
5. Enter information in the applicable fields. Refer to Table 76 on page 269 for
field value descriptions.

6. Choose .

270 Sterling Selling and Fulfillment Foundation: Application Platform Configuration Guide
Deleting a Menu Item
About this task

To delete a menu item:

Procedure
1. From the tree in the application rules side panel, choose Presentation > Menu.
The Menu Hierarchy window displays in the work area.
2. Expand the applicable menu group branch.
3. Expand the applicable application menu.

4. Select the applicable menu item and choose .

Defining Resources
A resource is a self-contained unit that controls the display of on-screen
information and the execution of program logic associated with the display. For
example, screens and APIs are types of resources.

Figure 28. Resource Hierarchy Tree

Sterling Selling and Fulfillment FoundationSterling Application


Platform Resources
All Sterling Selling and Fulfillment FoundationSterling Application Platform
resources have a set of primary properties (common to all resource types) and a set
of unique properties (specific to a particular type of resource). Common primary
properties are characteristics all resources have in common. For example, all
resources have a Resource ID. These resources are used to define screens within
the Application ConsoleConsole.

For an explanation of all primary resource information, refer to the following table.

In addition to primary information, each type of resource has unique


characteristics. For information about each resource type, see the list of tables
within this chapter.

Chapter 9. Configuring Presentation Components 271


Table 77. Primary Information of the Resource Details
Field Description
Resource ID Unique identifier for each resource. Each type of resource has its
own Resource ID syntax convention:
v API - <Parent Resource ID>AP<one up sequence number>. For
example, the Order Console uses the getOrderList() API, whose
Resource ID is orderAP2.
v Detail View - Y<two-character module code> D<sequence
number>. For example the Order Management has a detail view
Resource ID YOMD010.
v Entity- Free form. For example, Order.
v Icon - <Parent Resource ID>C<two-digit sequence number>. For
example, YOMD010D1C02.
v Inner Panel - <Parent Resource ID>I<two-digit sequence
number>. For example, YOMDO101I01.
v Link - <Parent Resource ID>L<two-digit sequence number>. For
example, YOML010.
v List View - Y<two-character module code> L<sequence
number>. For example, YOML010.
v Action - <Parent Resource ID>A<two-digit sequence number>.
For example, YOMD010I02A01.
v Related Entity - <Parent Entity ID>S<sequence number>. For
example, OrderS01.
v Search View - Y<two-character module code>S<sequence
number>. For example, YOMS010.
v RCP Resource - <three-character pca code>RCP<sequence
number>. For example, YCDRCP0122.
Description Literal value displayed as a label on the target screen and within
the Resource Hierarchy tree. This value is stored within the
resource bundle.
URL For Sterling Selling and Fulfillment FoundationSterling Application
Platform enter the uniform resource locator of the resource.

For the Rich Client Platform applications, enter the ID of the action
that the resource is associated to. This ID is the action id of the
class that invokes the screen, which is defined in the plugin.xml
file. For more information about how to create actions, see the
Sterling Selling and Fulfillment Foundation: Customizing the Rich Client
Platform Interface .

272 Sterling Selling and Fulfillment Foundation: Application Platform Configuration Guide
Table 77. Primary Information of the Resource Details (continued)
Field Description
Resource Type Sets of characteristics that define a set of features on the user
interface. For the Application Consoles resources, see the following:
v Application Consoles Entity
v Application Consoles Related Entity
v Application Consoles Search View
v Application Consoles Detail View
v Application Consoles List View
v Application Consoles API
v Application Consoles Inner Panel
v Application Consoles Action
v Application Consoles Link
v Application Consoles Icon

For the Sterling Selling and Fulfillment FoundationSterling


Application Platform Rich Client Platform application resources,
see the following:
v Rich Client Platform Action
v Rich Client Platform Task
Resource Sequence The order in which screen-related literals and logic display or
executed. Resource sequencing is valid only in the context of
sibling resources.
v Related Entity - Order in which the entity's popup shows up in
the search panel.
v Search View - Order in which search views are listed in the
search view popup menu.
v Detail View - Order in which detail views are listed in the detail
view popup menu.
v List View - Order in which the list views are listed in the list
view popup menu.
v API - Order in which APIs are invoked. The sequencing is
particularly important in the case of APIs, since the output of
one API may be used as input to another.
v Action - Order in which actions display in the UI.
v Icon - Order in which icon links to other views display in the
UI.
v RCP Action or Task - Order in which the menu displays in a
Sterling Selling and Fulfillment FoundationSterling Application
Platform Rich Client Platform application.

Application Consoles Entity


The Application Consoles Entity Resource Details dialog box enables you set the
Document Type of an entity. An entity is an associated group of UI displays and
program logic that pertain to a specific business entity, such as an order entity.

You can view the list of JSPs used by the resource and its corresponding
sub-resources and the list of users with permissions to access the resource by
performing a right-click on the entity and selecting JSP List or User List or by
choosing from the menu panel.

Chapter 9. Configuring Presentation Components 273


Each entity has a default search view, list view, and detail view. A default view is
determined by the sequencing of these views within the Resource Hierarchy tree.
For example, if the Order entity has four search views, the default search view is
determined as the one with the lowest resource sequence number among the four
search views.

Under each entity resource, you can configure one detail API and one list API. The
detail API configured is automatically called when a user navigates to the detail
view of that entity. The list API is called when a user navigates to the list view of
that entity.

You can prevent this default API from being called for a specific view by selecting
the Ignore Default API parameter in the resource configuration screen.

Note: While you can create any number of API Resources under an Entity, you
should create only one list and one detail API.
Table 78. Entity Resource Dialog Box
Control Description
Document Type When specified, this is passed as input to any APIs
configured within this entity (including all sub-resources).

Document Type is passed at the root node with the


DocumentType attribute name. This is also used to pick up
literals from the resource bundle when the i18n taglib is used
in all the JSPs configured for this entity (and all
sub-resources). Specifically, the application looks for an entry
with <DocumentType>_<ResourceKey>. If that is not found,
the entry for <ResourceKey> is picked up.

Application Consoles Related Entity


The Application Consoles Related Entity Resource Details dialog box enables you
to specify which entities appear as options on the drop-down menu of an entity on
a search view.

274 Sterling Selling and Fulfillment Foundation: Application Platform Configuration Guide
Figure 29. Related Entities on a Drop-Down Menu

Table 79. Console Related Entity Resource Dialog Box


Control Description
Related Entity The Resource ID of the related entity. Related Entities show
up in search screens as other entities by which you can
search. For example, when you choose Order from Menu, a
search screen displays. In the drop-down menu on the top
left corner of the search screen, you can see Order Lines and
Order Releases. These are configured as related entities of
Order entity.

After you choose Order Line, your current entity becomes


Order Line. Now, the drop-down menu shows Order and
Order Releases as related entities, because they are explicitly
defined as related entities for the entity Order Line.

Permissions cannot be maintained for Related Entity resources. This means that all
users are able to see the Related Entities in the entity drop-down of a search view.

Application Consoles Search View


The Console's Search View Resource Details dialog box enables you to specify
details that enable you to customize a search view.
Table 80. Search View Resource Dialog Box
Control Description
Java Server Page The JSP file name with full path relative to the
<INSTALL_DIR>/extensions/global/webpages directory.

Your custom resources typically points to a file within the


/extensions directory. For example, if you are changing the
alert search by order search view, specify the
<INSTALL_DIR>/extensions/global/webpages/em/alerts/
search/alert_search_byorder.jsp file.

As you populate the /extensions directory with custom JSP


files, mimic the structure of the directory containing the
standard JSP files.
Output Name Space Namespace of the XML bindings of the search criteria input
fields on the search JSP. The inputs that have this namespace
are sent to the List API of the entity.
Height N/A
Width N/A
Ignore Default API N/A
Hide Maximum Records Choose this to prevent the Max Records field from displaying.
Field

Chapter 9. Configuring Presentation Components 275


Table 80. Search View Resource Dialog Box (continued)
Control Description
View Group ID Within a specific search view of an entity, you can switch to
any other detail view having the same View Group ID as the
current search view.
Input N/A
Template N/A

Application Consoles Detail View


The Application Consoles Detail View Resource Details dialog box enables you to
customize a detail view.
Table 81. Detail View Resource Dialog Box
Control Description
Java Server Page In the case of detail views, this field is used as the JSP for the
anchor page. Typically, this JSP is used to simply include
other inner panels and lay them out in the manner desired.

If this field is not filled in, and the detail view has multiple
inner panels, they are laid out one below the other, stretching
all the way across horizontally.

Specify the full path relative to the <INSTALL_DIR>/


extensions/global/webpages directory. Your custom resources
typically points to a file within the /extensions directory. For
example, if you are changing the anchor page of the alert
detail view, your JSP might be /extensions/global/webpages/
em/alerts/detail/alert_detail_anchor.jsp.

As you populate the /extensions directory with custom JSP


files, mimic the structure of the directory containing the
standard JSPs.
Output Name Space N/A
Height When this view displays in a pop-up screen, this is the height
of the popup window.
Width When this view displays in a popup screen, this is the width
of the popup window.
Ignore Default API When this option is set, any detail API that might be
configured for the current entity is not invoked when the
current detail view displays.

Typically, an entity has a standard detail API and several


views that need different parts of the same detail API output.
So, typically, you can simply define a detail API at the entity
level and expect that the default detail API is called whenever
a detail view for that entity is shown. However, some of the
views of that entity may be special and may require a
different API to be called. In such cases, this field can be
checked and the alternate API can be configured for any one
of the inner panels of the special detail view.
Hide Navigation Panel When this option is set, the Next and Previous navigation
buttons do not show up on this detail view.

276 Sterling Selling and Fulfillment Foundation: Application Platform Configuration Guide
Table 81. Detail View Resource Dialog Box (continued)
Control Description
Hide Title Bar When this option is set, the entire title bar does not show up
for this detail view. Note that the title bar includes the screen
title, Save, Help, and Close buttons.
View Group ID Within a specific detail view of an entity, you can switch to
any other detail view having the same View Group ID as the
current detail view.
Input N/A
Template N/A
Redirector View When this is set the detail view is used only to redirect to
another detail view. The JSP for this view should not contain
any HTML intended for display. It should only contain
conditional JSP statements that eventually call the
goToDetailView JSP method to navigate to the final view.

Application Consoles List View


The Application Consoles List View Resource Details dialog box enables you to
customize a list view.
Table 82. List View Resource Dialog Box
Control Description
Java Server Page The JSP file name with full path relative to the
<INSTALL_DIR>/extensions/global/webpages directory. Your
custom resources typically point to a file within the
/extensions directory. For example, if you are changing the
alert list verbose view, specify the /extensions/global/
webpages/em/alerts/list/alerts_list_verbose.jsp file.

As you populate the /extensions directory with custom JSP


files, mimic the structure of the directory containing the
standard JSP files.
Output Name Space N/A
Height N/A
Width N/A

Chapter 9. Configuring Presentation Components 277


Table 82. List View Resource Dialog Box (continued)
Control Description
Ignore Default API When this option is set, any list API that might be configured
checkbox for the current entity is not invoked when the current list
view displays.
Note: Also, when this option is set, you must handle the
search panel collapse functionality as well as the total number
of records displayed on the UI in your custom JSP. For
example, you can handle the logic for fetching the number of
records returned by an external API call in your custom JSP
by writing the following lines of code:
<%
int numberOfRecords = /* logic to find out the
number of records returned by an external API
call.*/
if (numberOfRecords > 0){
%>
<script type="text/javascript">
slideSearchPanelView();
yfcOverrideResultSetCount(numberOfRecords);
</script>
<%
}
%>
Supports Direct List to When this is set and the related search results in one record,
Detail Navigations When the list screen is bypassed and the details display.
One Record Returned
View Group ID Within a specific list view of an entity, you can switch to any
other detail view having the same View Group ID as the
current list view.
Input N/A
Template When the default List API is invoked for a view, this is the
output template that is passed to the API.

Application Consoles API


The Application Consoles API Resource Details dialog box enables you to specify
whether or not to call an API and how that API is called.

Permissions cannot be maintained for API resources. An API resource can call a
Sterling Selling and Fulfillment FoundationSterling Application Platform standard
API or invoke a service that has been configured.

Note: Although you can create any number of API resources under an Entity, you
should create only one list and one detail API.
Table 83. API Resource Dialog Box
Control Description
Invoke a Service Specifies that a service is invoked in the UI for this resource.
Service Name Applies only to services. Enabled through the Invoke a
Service radio button. Provides a drop-down list of available
services that have been previously configured in the Services
of the Applications ManagerConfigurator.

278 Sterling Selling and Fulfillment Foundation: Application Platform Configuration Guide
Table 83. API Resource Dialog Box (continued)
Control Description
Templates Applies only to services. Enabled through the Invoke a
Service radio button. Provides a way for you to add, modify,
and delete a list of templates. You can enter an API Name
and a Template for each row in the table. This way you can
enter templates for all APIs that are called within the service.

Important: note that one service should not execute the same
API twice because you cannot configure multiple template
elements for the same API.
Invoke an API Specifies that a Sterling Selling and Fulfillment
FoundationSterling Application Platform standard API is
invoked in the UI for this resource. When checked, it enables
the API Name drop-down list and API Template.
API Name Applies only to APIs. Enabled through the Invoke an API
radio button. Provides a drop-down list of standard or
extended APIs available through the Service Definition
Framework. If the API you select is backward compatible, the
Requires Backward Compatibility checkbox is enabled.
Requires Backward Applies only to APIs that can be invoked in backward
Compatibility compatibility mode. Enables you to specify if the API should
run in backward compatibility mode. When checked, Version
must also be supplied.
Version Applies only to APIs running in backward compatibility
mode. Provides a drop-down list of the versions for which an
API is backward compatible.
Input Namespace Namespace corresponding to the text box that passes input to
a Save API. Applies only to a detail view, as they may have
several text boxes that are bound to different XML
namespaces. However, only one of the text boxes can pass
input to the API.
Output Namespace The output of the API is saved in this namespace. Namespace
is optional, but if it is not specified, it is defaulted to the root
node name of the XML under consideration. Therefore, while
referring to the output of the API, even if namespace is not
specified here, it can be assumed to be the same as the root
node name of the output.

A namespace is a tag that can be used to identify a specific


XML. The Presentation Framework enables you to call
multiple APIs and store the outputs in different namespaces.
In your JSP or in the input to an API, you can refer to values
from any namespace that is available at that point.
Ignore Exception If this API throws an exception then it is not displayed to the
user. This option is not available for API resources that are
created directly under an Entity resource.
Skip Automatic Execution When this option is checked, the API is not called
automatically when the view displays. You can then call this
API within the JSP using the callAPI taglib. This option is
not available for API resources that are created directly under
an Entity resource.

Chapter 9. Configuring Presentation Components 279


Table 83. API Resource Dialog Box (continued)
Control Description
Call In Rollback-Only Check this box if you want to call this API in rollback-only
Mode mode to roll back the changes made in the database.

By default, this checkbox is disabled for all Sterling Selling


and Fulfillment FoundationSterling Application Platform
APIs.
Note: However, in order to execute this rollback-only
operation, a custom action needs to be created. For
information about creating custom actions in a screen, refer to
the Sterling Selling and Fulfillment Foundation: Customizing
Console JSP Interface for End-User .
API Type Specify the type of view from which the API may be invoked.
This option is only available for API resources that are
created directly under an Entity resource. Such resource types
are:
v List - invokes the API from a list view
v Detail - invokes the API from a detail view
Input Provide an XML structure that can be used to pass specific
input to the API. You can specify dynamic attributes here.
Template Provide a template XML here. This template XML is passed
to the API through the YFSEnvironment class.

Although YFSEnvironment class supports passing a complete


XML or simply an XML file name, you can only provide a
complete XML in this field.

Application Consoles Inner Panel


The Application Consoles Inner Panel Resource Type dialog box enables you to
customize inner panels. Inner panels are the UI components that make up detail
views.
Table 84. Inner Panel Resource Dialog Box
Control Description
Java Server Page The JSP file name with full path relative to the
<INSTALL_DIR>/extensions/global/webpages directory. Your
custom resources typically point to a file within the
/extensions directory. For example, if you are changing the
person info inner panel, specify the /extensions/global/
webpages/pm/personinfo/detail/
personinfo_detail_anchor.jsp file.

As you populate the /extensions directory with custom JSP


files, mimic the structure of the directory containing the
standard JSPs.
Override Entity ID For future use.
Entity Key Name For future use.
Template When the default Detail API is invoked for a view, all the
templates specified for each inner panel for the view are
merged to form the output template that is passed to the API.

280 Sterling Selling and Fulfillment Foundation: Application Platform Configuration Guide
Note: Inner panels can be marked as read-only; see “Setting Inner Panels as
Read-Only” on page 197 for more information.

Application Consoles Action


The Application Consoles Action Resource Details dialog box enables you to
customize details of an action that can be used in the Application ConsoleConsole.
Table 85. Action Resource Dialog Box
Control Description
Java Server Page When an action is executed in the user interface, this JSP is
called. This can be used to do server-side processing, such as
calling multiple APIs.
JavaScript The JavaScript function specified here is executed through the
eval() function. The function body needs to be present in
extensions/global/webpages/extn.js. This JS file is included
in the container.jsp file and is therefore available in all JSPs.
Note: The container.jsp file is one of the Presentation
Framework JSPs. This JSP defines the basic structure of all
screens and includes other JSPs, as defined against inner
panels, search views, list views and detail views.
View ID When a View ID is specified for an Action, the view opens in
a modal dialog when user clicks on the action.

However, if an API is also configured for the Action, the


behavior is as follows: The API is called first, and after the
API is called, the current window itself is updated with the
view configured here.

When a JavaScript is also configured, that's what is called


before view or API is called. If the JavaScript returns false,
none of the other actions are invoked.

If the Action is configured for a list view, the specified View


ID opens up in the same browser window, and not in a
separate popup.
View Group ID View group that is navigated to when you choose this action.
Input Name Space Namespace of the XML that is passed as input to this API if
this action calls an API. It is assumed that this namespace
exists.
Binding You can specify an XML Binding here.

If the XML attribute returns true or greater than 0 or Y, the


action is enabled and the user cannot click on the action.
Since it considers all other values disabled.
Selection Key Name This is the name or the ID attribute of the checkboxes in the
inner panel that needs to be checked before this action is
clicked up. For example, in an order list screen, only if some
orders are selected, you can view the details. Clicking the
View Details action without selecting any order results in a
client-side error message. This happens because for the View
Details action, the resource has been configured to have a
selection key name, which is the ID of the checkboxes in the
order_list_concise.jsp file.

If this field is not specified, it means that the action is not


dependent upon any checkbox being checked.

Chapter 9. Configuring Presentation Components 281


Table 85. Action Resource Dialog Box (continued)
Control Description
Input Key Name If the action being configured requires the user to select
records from a list using check boxes within the list, specify
the name or ID of the check box object within the JSP here to
ensure that the key the check box is associated to is passed as
input to the target of this view.

For example, the order detail screen contains a service


requests inner panel that displays all of the service requests
for that order. The cancel action defined on the inner panel
requires the user to select one or more service requests (using
the check box that displays in the first column of the list).
The name of this check box inside the JSP is chkEntityKeyPS.
Therefore, to ensure the selected keys are appropriately
passed to the API that is called for the cancel action, the
Input Key Name of the cancel action is set to chkEntityKeyPS.
Popup N/A
Close Window On When this is specified, the current window closes after the
Complete current action is performed. For example, use this control for
the Save action on a popup window that should close
automatically after Save is performed.

Application Consoles Link


The Application Consoles Link Resource Details dialog box enables you to specify
the details of a hyperlink used within an inner panel.

Links are not permission controlled. This means that any Links you modify does
not show up on the Permission tree of the User Group Applications
ManagerConfigurator.
Table 86. Link Resource Dialog Box
Control Description
View ID The View ID to open when the link is clicked.
View Group ID View group that is navigated to when you choose this link.

Application Consoles Icon


The Application Consoles Icon Resource Details dialog box enables you to specify
the details of an icon that displays on the upper left section of the inner panel title.
These icons are referred to as view icons.

282 Sterling Selling and Fulfillment Foundation: Application Platform Configuration Guide
Table 87. Icon Resource Dialog Box
Control Description
JavaScript The JavaScript function specified here is executed through the
eval() function. The function body needs to be present in the
/extensions/global/webpages/scripts/extn.js file. This JS
file is included in the container.jsp file and is therefore
available in all JSPs.

Note: The container.jsp file is one of the Presentation


Framework JSP files. This JSP file defines the basic structure
of all screens and includes other JSPs, as defined against
inner panels, search views, list views and detail views.
View ID The View ID to open when this icon is clicked.
View Group ID View group that is navigated to when you choose this icon.
Enabled Binding You can specify an XML Binding here.

If the XML attribute returns true or greater than 0 or Y, the


action is enabled and the user cannot click on the action.
Since it considers all other values disabled.
Display Binding You can specify an XML Binding here.

If the XML attribute returns true or greater than 0 or Y, the


action is enabled and the user cannot click on the action.
Since it considers all other values disabled.
Image Relative path of the image file. For a ConsoleApplication
Console menu item, specify the com/
smcfs<application_name>/ycp/ui/icons/configmenu.gif file.
Tooltip You can specify an XML Binding here.

When the screen displays, the XML pointed to by the binding


is evaluated. If the XML attribute returns a numeric value
other than zero (0), this number displays in parenthesis next
to the resource description in the tooltip of this icon.
Alternate Image Binding You can specify an XML Binding here.

This field is used to display a different icon on the console


inner panel based on the value of this binding. If the XML
attribute returns a value of “Y”, “true”, or a number greater
than 0, then the alternative icon is used.
Alternate Image Relative path of the alternate image file.

Rich Client Platform Action


In the Sterling Selling and Fulfillment FoundationSterling Application Platform
Rich Client Platform, actions are defined as resources. The Rich Client Platform
actions enables you to specify the ID of the action which is called when a menu
item is invoked. The Rich Client Platform Action resources are permission
controlled.
v ActionID—The identifier of the action that gets invoked when you click on a
menu item.

The URL field in the resource configuration should point to the Rich Client
Platform ActionID. For more information about URL field, see Table 77 on page
272.

Chapter 9. Configuring Presentation Components 283


The Rich Client Platform Action resource types can be linked to Menu items within
Rich Client Platform. To configure the Rich Client Platform Action resource type
with menu items, see “Defining Menus” on page 267.

For more information about Rich Client Platform Actions, refer to the Sterling
Selling and Fulfillment Foundation: Customizing the Rich Client Platform Interface .

Rich Client Platform Task


Each Rich Client Platform Task resource type is associated with a resource
identifier. The Rich Client Platform Task resource types are permission controllable.
The user can view only those Rich Client Platform tasks for which the user has
permissions. The Rich Client Platform Task resources types are the logical
representation of related tasks within the Rich Client Platform. The Rich Client
Platform task contains a set of actions. When you create the related tasks, you
must specify the specify the identifier of the resource that you want to associate
with the related task. Based on the permissions assigned for the resource, the
related tasks view displays to the user.

The URL field in the resource configuration should point to the Rich Client
Platform ActionID. For the URL field description, see Table 77 on page 272.

For more information about Related Tasks and Rich Client Platform Actions, see
the Sterling Selling and Fulfillment Foundation: Customizing the Rich Client Platform
Interface .

Defining Themes
You can define the labels that identify themes used in Sterling Selling and
Fulfillment FoundationSterling Application Platform. All themes used by Sterling
Selling and Fulfillment FoundationSterling Application Platform are defined
centrally through CSS and XML files. Themes contain the standard Sterling Selling
and Fulfillment FoundationSterling Application Platform themes as well as the
ones that you define.

Creating a Theme
About this task

To create a theme:

Procedure
1. From the tree in the application rules side panel, choose Presentation > Themes.
The Themes window displays in the work area.

2. Choose . The Theme Details pop-up window displays.

284 Sterling Selling and Fulfillment Foundation: Application Platform Configuration Guide
3. In Theme, enter the name of the XML or CSS files, for example, if the theme
file is called malachite.xml, enter ‘malachite'. Refer to the Sterling Selling and
Fulfillment Foundation: Localization Guide for naming conventions regarding
localization.
4. In Short Description, enter a brief description of the theme.
5. In Long Description, enter a more detailed description of the theme.
6. Choose .

Modifying a Theme
About this task

To modify a theme:

Procedure
1. From the tree in the application rules side panel, choose Presentation > Themes.
The Themes window displays in the work area.

2. Select the applicable theme and choose . The Theme Details pop-up window
displays.
3. In Short Description, enter a brief description of the theme.
4. In Long Description, enter a more detailed description of the theme.
5. Choose .

Deleting a Theme
About this task

To delete a theme:

Procedure
1. From the tree in the application rules side panel, choose Presentation > Themes.
The Themes window displays in the work area.

2. Select the applicable theme and choose .

Chapter 9. Configuring Presentation Components 285


Defining Custom Common Code Types
Common codes are values that enable a user to choose from a list of options rather
than having to enter the data manually. They can be made available to the user
from drop-down lists in extended Sterling Selling and Fulfillment
FoundationSterling Application Platform console screens. For example, if an item is
backordered, the user can choose a reason, such as No Stock, from a list. The list of
reasons is a list of common codes.

By default, the fields on the standard interface have lists of common codes to
which you can add your own common codes.

When adding fields to the user interface, you can provide drop-down lists of
custom common codes by adding combo boxes. These common code values can be
retrieved within an extended screen using the getCommonCodeList() API.

Creating a Custom Common Code Type


About this task

To create a custom common code type:

Procedure
1. From the tree in the application rules side panel, choose Presentation > Custom
Common Code Types. The Custom Common Code Types window displays in
the work area.

2. Choose . The Code Type Details pop-up window displays.

3. In Code Type, enter the name of the custom common code type.

Note: Value of the new common code type Maximum length is 15 characters.
This value is automatically appended with .ex extension so that it does not
conflict with the Sterling Selling and Fulfillment FoundationSterling Application
Platform-defined common codes. This value must be passed to the
getCommonCodeList() API.
4. In Short Description, enter a brief description of the theme.
5. In Long Description, enter a more detailed description of the theme.
6. In Maximum Code Value Length, enter the maximum length of a code value
for this custom common code type. When users create code values for this
common code type, they can enter values that have a maximum length of the
value specified here.
286 Sterling Selling and Fulfillment Foundation: Application Platform Configuration Guide
7. Choose .

Modifying a Custom Common Code Type


About this task

To modify a custom common code type:

Procedure
1. From the tree in the application rules side panel, choose Presentation > Custom
Common Code Types. The Custom Common Code Types window displays in
the work area.

2. Select the applicable custom common code type and choose . The Code
Type Details pop-up window displays.
3. In Short Description, enter a brief description of the code type.
4. In Long Description, enter a more detailed description of the code type.

5. Choose .

Deleting a Custom Common Code Type


About this task

To delete a custom common code type:

Procedure
1. From the tree in the application rules side panel, choose Presentation > Custom
Common Code Types. The Custom Common Code Types window displays in
the work area.

2. Select the applicable common code type and choose .

Defining Custom Common Code Values

Adding Values to a Custom Common Code


About this task

To add values to a custom common code:

Procedure
1. From the tree in the application rules side panel, choose Presentation > Custom
Common Codes. The Custom Common Code Types window displays in the
work area.
2. Select the applicable custom common code and choose . The Common Code
Values pop-up window displays.
3. Choose . The Common Code Details pop-up window displays.

Chapter 9. Configuring Presentation Components 287


4. In the Common Code Field, enter the code value.
5. In Short Description, enter a brief description of the code value.
6. In Long Description, enter a more detailed description of the code value.

7. Choose .

Modifying a Custom Common Code's Values


About this task

To modify a custom common code value:

Procedure
1. From the tree in the application rules side panel, choose Presentation > Custom
Common Codes. The Custom Common Code Types window displays in the
work area.

2. Select the applicable custom common code and choose . The Common
Codes pop-up window displays.

3. Locate the applicable code value and choose . The common code's Details
pop-up window displays.
4. In Short Description, enter a brief description of the code value.
5. In Long Description, enter a more detailed description of the code value.

6. Choose .

Deleting a Custom Common Code's Values


About this task

To delete a custom common code value:

Procedure
1. From the tree in the application rules side panel, choose Presentation > Custom
Common Codes. The Custom Common Code Types window displays in the
work area.

2. Select the applicable custom common code and choose . The Common
Codes pop-up window displays.

3. Locate the applicable code value and choose .

288 Sterling Selling and Fulfillment Foundation: Application Platform Configuration Guide
Defining Custom Error Codes
You can define custom error codes and the descriptions to be used along with the
default error codes provided by Sterling Selling and Fulfillment FoundationSterling
Application Platform. For example, you can use these custom error codes when the
user exit to validate passwords returns validation failure reasons. Moreover, the
custom error codes are localizable through existing mechanisms.

All the error codes must start with EXTN, if not an exception is thrown when you
save the custom error code.

Searching for a Customer Error Code


About this task

To search for a customer error code:

Procedure
1. From the tree in the application rules side panel, choose Presentation > Custom
Error Codes. The Custom Error Code Search window displays in the work area.
2. Enter the applicable error code and description for which you want to search.
3. Choose and a list of custom error codes displays.

Adding a Custom Error Code


About this task

To add values to a custom error code:

Procedure
1. From the tree in the application rules side panel, choose Presentation > Custom
Error Codes. The Custom Error Codes List window displays in the work area.

2. Choose . The Custom Error Code Details pop-up window displays.

3. In the Error Code Field, enter the code value.


4. In Error Message, enter the message to be displayed for this code value.
5. In Cause, enter the cause for the error to be raised.
6. In Action, enter the action to be taken when the error is raised.

7. Choose .

Chapter 9. Configuring Presentation Components 289


Modifying a Custom Error Code
About this task

To modify a custom error code value:

Procedure
1. From the tree in the application rules side panel, choose Presentation > Custom
Error Codes. The Custom Error Code search window displays in the work area.

2. Choose and a list of custom error codes displays.

3. Select the applicable custom error code from the list and choose . The Error
Codes pop-up window displays.
4. In Error Message, modify the message displayed for this code value.
5. In Cause, modify the cause for the error to be raised.
6. In Action, modify the action be taken when the error is raised.

7. Choose .

Deleting a Custom Error Code


About this task

To delete a custom error code value:

Procedure
1. From the tree in the application rules side panel, choose Presentation > Custom
Error Codes. The Custom Error Code search window displays in the work area.

2. Choose and a list of custom error codes display.

3. Select the code value you want to delete and choose .

290 Sterling Selling and Fulfillment Foundation: Application Platform Configuration Guide
Chapter 10. Configuring Business Communication
Components
You can configure business communication components to define the codes and
documents used to communicate between Sterling Selling and Fulfillment
FoundationSterling Application Platform and external systems as well as different
business organizations within your business model.

Defining Protocol Codes


You can use Protocol Code Setup to set up codes to identify the different protocols
organizations used to communicate with each other.

The following are examples of different protocols:


v FTP
v E-Mail
v Fax

Creating a Protocol Code


About this task

To create a protocol code:

Procedure
1. From the tree in the application rules side panel, choose Communication >
Protocols. The Protocol List window displays in the work area.

2. Choose . The Protocol Details pop-up window displays.

3. In Protocol Name, enter the name of the protocol.


4. In Description, enter a brief description of the protocol.

5. Choose .

Modifying a Protocol Code


About this task

To modify a protocol code:

Procedure
1. From the tree in the application rules side panel, choose Communication >
Protocols. The Protocol List window displays in the work area.

© Copyright IBM Corp. 1999, 2011 291


2. Select the applicable protocol and choose . The Protocol Details pop-up
window displays.
3. In Description, enter a brief description of the protocol.

4. Choose .

Deleting a Protocol Code


About this task

To delete a protocol code:

Procedure
1. From the tree in the application rules side panel, choose Communication >
Protocols. The Protocol List window displays in the work area.

2. Select the applicable protocol and choose .

Defining Document Format Codes


You can use Document Format Code Setup to set up codes to identify the different
document formats organizations use to communicate with each other.

The following are examples of different document formats:


v EDI
v XML
v Flat-file

Creating a Document Format Code


About this task

To create a document format code:

Procedure
1. From the tree in the application rules side panel, choose Communication >
Document Formats. The Document Format List window displays in the work
area.

2. Choose . The Document Format Details pop-up window displays.

3. In Format ID, enter the name of the document format.


4. In Description, enter a brief description of the document format.

5. Choose .

292 Sterling Selling and Fulfillment Foundation: Application Platform Configuration Guide
Modifying a Document Format Code
About this task

To modify a document format code:

Procedure
1. From the tree in the application rules side panel, choose Communication >
Document Formats. The Document Format List window displays in the work
area.

2. Select the applicable document format and choose . The Document Format
Details pop-up window displays.
3. In Description, enter a brief description of the document format.

4. Choose .

Deleting a Document Format Code


About this task

To delete a document format code:

Procedure
1. From the tree in the application rules side panel, choose Communication >
Document Formats. The Document Format List window displays in the work
area.

2. Select the applicable document format and choose .

Defining Business Document Codes


You can use Business Document Code Setup to set up codes to identify the
different documents organizations use to communicate with each other.

The following are examples of different document formats:


v Purchase Order (PO)
v Advanced Shipment Notice (ASN)
v Invoice

Creating a Business Document Code


About this task

To create a business document code:

Procedure
1. From the tree in the application rules side panel, choose Communication >
Business Document. The Business Document List window displays in the work
area.

2. Choose from the top portion of the screen. The Business Document Details
pop-up window displays.

Chapter 10. Configuring Business Communication Components 293


3. In Document ID, enter the ID of the business document.
4. In Document Name, enter the name of the business document.
5. In Description, enter a brief description of the document format.

6. Choose .

Modifying a Business Document Code


About this task

To modify a business document code:

Procedure
1. From the tree in the application rules side panel, choose Communication >
Business Document. The Business Document List window displays in the work
area.

2. Select the applicable business document and choose . The Business


Document Details pop-up window displays.
3. In Document Name, enter the name of the business document.
4. In Description, enter a brief description of the document format.

5. Choose .

Deleting a Business Document Code


About this task

To delete a business document code:

Procedure
1. From the tree in the application rules side panel, choose Communication >
Business Document. The Business Document List window displays in the work
area.
2. Select the applicable document format and choose .

Classifying an Existing Business Document


About this task

You can classify any existing business documents to be identified as a Buyer, Seller,
or Carrier Document. For example, an advanced shipment notice is a document
sent to carriers to alert them that an order has been made and a shipment of a
certain set of items is necessary. You would identify this document as a carrier
document.

294 Sterling Selling and Fulfillment Foundation: Application Platform Configuration Guide
To classify an existing business document as a Buyer, Seller, or Carrier document:

Procedure
1. From the tree in the application rules side panel, choose Communication >
Business Document. The Business Document List window displays in the work
area.
2. Choose the either the Seller Documents tab, Buyer Documents tab, or Carrier
Documents tab dependant on which role you want to associate the business
document with.

3. Choose . The Role Document Details pop-up window displays.

4. From Document ID, select the business document you want to associate with
the role.
5. In Document Name, enter the name of the business document.
6. In Description, enter a brief description of the document format.

7. Choose .

Chapter 10. Configuring Business Communication Components 295


296 Sterling Selling and Fulfillment Foundation: Application Platform Configuration Guide
Chapter 11. Configuring Nomenclature Components
The Nomenclature Runtime components provide a mapping tool that allows you
to configure unique terms you use to match unique terms your trading partners
use.

When trading partners or external systems exchange information with Sterling


Selling and Fulfillment FoundationSterling Application Platform, they may identify
entity values differently than Sterling Selling and Fulfillment FoundationSterling
Application Platform and each other. For example, a carrier code may be called UPS
in Sterling Selling and Fulfillment FoundationSterling Application Platform and
UnitedParcelService by a trading partner or external system.

The Nomenclature Transformation Engine enables you to define these entities, its
values, and the mappings between interacting systems or trading partners. Then,
when data is exchanged between Sterling Selling and Fulfillment
FoundationSterling Application Platform and an external system or trading partner,
the Nomenclature Transformation Engine automatically applies the mapping rules
specified.

Using the United Parcel Service example above, when data is sent from Sterling
Selling and Fulfillment FoundationSterling Application Platform to the external
system or trading partner, the Nomenclature Transformation Engine transforms the
carrier code literal UPS to UnitedParcelService and back again.

Defining Nomenclature Codes


About this task

Nomenclature Codes allows you to create, modify, and delete attribute codes that
can be used to define entities in Nomenclature Definition.

To create a nomenclature code:

Procedure
1. From the menu bar, choose Applications > Application Platform. The
Application Platform tree displays in the side panel.
2. From the Application Platform tree, choose Nomenclature > Nomenclature
Codes. The Nomenclature Codes window displays in the work area.
3. Choose . The Nomenclature Code Details pop-up window displays.

© Copyright IBM Corp. 1999, 2011 297


4. In Nomenclature Code, enter the name of the attribute code.
5. In Short Description, enter a brief description of the nomenclature code.
6. In Long Description, enter a detailed description of the nomenclature code.

7. Choose .

Defining Nomenclature Definitions


About this task

Nomenclature Definition allows for entities requiring transformation to be created.


These entities are identified for each System and Participant (Enterprise, Buyer,
Seller, Carrier). Entities definitions are created for a combination of one or more
attribute codes. The attribute codes that make an entity are common across all
participating systems and participants.

To create a nomenclature definition:

Procedure
1. From the tree in the application rules side panel, choose Nomenclature >
Nomenclature Definition. The Nomenclature Definition Search window
displays in the work area.

2. Choose . The Nomenclature definition details pop-up window displays.


Enter information, using the following table, Nomenclature Definition Menu,
for help.

3. Choose .

Table 88. Nomenclature Definition Menu


Property Description
System Name Enter a unique System Name for each system you are
defining this entity for. This is a required parameter. The
System Name STERLING is reserved.

298 Sterling Selling and Fulfillment Foundation: Application Platform Configuration Guide
Table 88. Nomenclature Definition Menu (continued)
Property Description
Organization Code Select a participant for Organization Code. Select the
DEFAULT organization from the drop down list if the
definition applies across participants. This is a required
parameter.

The Organization code uniquely identifies the Trading partner


or the external system.
Code Description Enter a unique description for the entity being created.
View Values Defaults to view values. Check this if you do not want to see
a list of valid values for a System and Participant. Valid
values for the entity are not displayed when mapping if this
is not checked.
Code Name 1-4 Select up to four attribute codes that can be grouped together
to define the entity. A minimum of one attribute must be
selected. Additional attributes may be added to the list
through Nomenclature Code Maintenance. The list is
displayed from the YFS_COMMON_CODE table for
CODE_TYPE='XREF_CODE'.
Code Value API Check on the code value API box and enter a class name,
which retrieves the list of values for the code.
Class Name Enter the class name used to get values from the external
system.

The system has pre-defined classes for certain attribute codes,


which retrieve data for the System Name STERLING (the
Sterling Selling and Fulfillment FoundationSterling
Application Platform-defined code values).

Using a class to get a list of valid value for an attribute code


is not mandatory. The code values can be created and
mapped directly when mapping entities.

Creating Mappings Between Nomenclature Definitions


About this task
To create mapping between nomenclature definitions:

Procedure
1. From the tree in the application rules side panel, choose Nomenclature >
Nomenclature Definition. The Nomenclature Definition Search window
displays in the work area.
2. Select the two Entities that you want to map and choose the Mapping button.
The Nomenclature Mapping panel displays.

Chapter 11. Configuring Nomenclature Components 299


The Nomenclature Mapping panel has the list of valid values for the entities
selected. The from/to Entity to be mapped can be changed by changing the
System Name, Organization Code, or the Entity description.

Note: The list is not displayed if the View Values option is not checked when
creating the Entity Definition.

3. Choose . The new entity defined is added to the list of entities in the search
results.
4. Enter values for each attribute and choose .
5. To create a mapping between the two entities, select a row from the list of
values displayed in the from/to system and choose the Create Mapping button.

Defining Nomenclature Configuration


About this task

Nomenclature Configuration allows you to define the rules to be applied and the
entities that need to be transformed when data is exchanged between Sterling
Selling and Fulfillment FoundationSterling Application Platform and external
systems or trading partners. The configuration is captured for each document
exchanged.

300 Sterling Selling and Fulfillment Foundation: Application Platform Configuration Guide
To create a unique configuration between two systems:

Procedure
1. From the tree in the application rules side panel, choose Nomenclature >
Nomenclature Configuration. The Nomenclature Configuration Search window
displays in the work area.

2. Choose . The Create Nomenclature Configuration pop-up window displays.


3. Enter information in the applicable fields. Refer to the following table for field
level descriptions.

Table 89. Nomenclature Configuration


Property Description
XML Name Enter a unique name for the document being exchanged
between two systems or participants.
From System Enter the system name from which document is originating.
To System Enter the system name to which the document is delivered to
From Organization Enter the organization from which the document is
originating.
To Organization Enter the organization to which the document is delivered to

4. Choose . The Configuration Details window displays.

5. Choose . The Configuration Detail pop-up window displays capturing all


the fields in the document that need to be transformed.

Chapter 11. Configuring Nomenclature Components 301


6. Enter information in the applicable fields. Refer to the following table for field
level descriptions.

Table 90. Nomenclature Configuration Details


Property Description
XML Name The unique name by which the document exchanged is
identified.
Attribute Location Enter the full XML path of the element under which the
attributes that need transformation are present.

If this is a repeating node in the XML document, the


transformation is applied to all the nodes.

For example, if the publishShipAdvice output XML is being


sent to a warehouse management system for fulfillment and
the carrier code needs to be transformed, the attribute
location should be entered as ShipmentAdvices/
ShipmentAdvice.

302 Sterling Selling and Fulfillment Foundation: Application Platform Configuration Guide
Table 90. Nomenclature Configuration Details (continued)
Property Description
Attribute 1-4 Enter the XML attribute name(s) that need to be transformed
when the document is being published.

For example, if the publishShipAdvice output XML is being


sent to a warehouse management system for fulfillment and
the carrier code needs to be transformed, the attribute should
be entered as Scac in the document location ShipmentAdvices
> ShipmentAdvice.
New Attribute 1-4 For each attribute being transformed, either the existing value
can be replaced in the document or a new attribute can be
inserted in the XML in the same level. Enter the new XML
attribute name to be inserted when the transformation occurs.

For example, the publishShipAdvice output XML is being


sent to a warehouse management system for fulfillment and
the carrier code needs to be transformed in the location
ShipmentAdvices > ShipmentAdvice in the document for the
SCAC attribute. This is specified as WhseCarrier and a new
attribute is inserted in the location ShipmentAdvices >
ShipmentAdvice called WhseCarrier. This XML attribute
carries the new transformed value and the old attribute and
value are left intact.
Mapping Type Select Nomenclature if the values are retrieved from the
mapping specified in the Nomenclature transformation
Engine.

Select Constant if the value is always transformed to a


Constant value.
Abort Processing on Error If this is selected and the Mapping Type is set to
nomenclature, if mapping is not found a ‘No Default' is set
and processing stops.
Nomenclature Specifies the entity definition to use for the system participant
to determine the transformed values. Select the from/to code
descriptions to use.
Use Default Values If this is selected, enter the default values to apply when
mapping is not found.
Constant 1-4 If you selected Constant, enter the constant value for XML
attribute transformation.

Chapter 11. Configuring Nomenclature Components 303


304 Sterling Selling and Fulfillment Foundation: Application Platform Configuration Guide
Chapter 12. Configuring Alert Queues
Queue ManagementQueue Management is used to define rules and methods
pertaining to user alert notifications.

Alerts

An alert is a message directed to a user or an alert queue about a transaction that


needs manual intervention. An alert can come in different formats including
e-mail, faxes, and so on.

Alerts are sent to different queues depending on the notification definitions you
have configured.

Alert Queues

Alert queues are set up to distribute alerts to users. You determine which users
receive different alert types by assigning them to queues. You can also set up alert
priorities and actions raised when certain conditions are met for the alert.

Creating an Alert Queue


About this task

To create an alert queue:

Procedure
1. From the tree in the application rules side panel, choose Queue Management.
The Queue Search window displays in the work area.

2. Choose . The Queue Details window displays.


3. Enter information in the applicable fields. Refer to the following table for field
value descriptions.

© Copyright IBM Corp. 1999, 2011 305


Table 91. Queue Details Window
Field Description
Queue ID Enter a unique identifier for the queue.
Queue Name Enter the name of the queue.
Queue Description Enter a brief description of the queue.
Queue Group Enter the group this queue is a part of.
Queue Priority Enter a numerical priority for the queue with 1 being the
highest and 0 being no priority. This is used to identify a
queue's importance in the business environment.
Audit Queue Select Audit Queue if you want to audit the alerts coming
into the queue and how they are resolved.

Note: The Exception Monitor has to be running in the background for the
above configuration to work.

Defining How Unresolved Alerts are Handled Based on Size


About this task

You can configure unresolved alerts to be escalated to a different queue after a


specified number of unresolved alerts has been exceeded.

To set up a size-based escalation:

306 Sterling Selling and Fulfillment Foundation: Application Platform Configuration Guide
Procedure
1. In the Queue Details window, choose the Size Based Escalation tab.
2. Enter information in the applicable fields. Refer to the following table for field
value descriptions.

Table 92. Size Based Escalation Tab


Field Description
Escalate If Number of Enter the maximum number of unresolved alerts that can be
Unresolved Alerts Exceeds logged in this queue before an action is raised.
Raise Action Select an action to be taken when the number of unresolved
alerts in this queue is greater or equal to the specified
maximum.
Re-Alert After (in hours) Enter the number of elapsed hours before a re-alert is
generated.

Defining How Unassigned Alerts are Handled Based on Time


About this task

You can configure alerts that have not been assigned to a user to be escalated to
another queue, raise an action after a given amount of time passes, or both.

To set up a time-based escalation for unassigned alerts:

Procedure
1. In the Queue Details window, choose the Unassigned Alerts tab.
2. Enter information in the applicable fields. Refer to the following table for field
value descriptions.

Table 93. Unassigned Alerts Tab


Field Description
Escalate Alert After (in Enter the maximum number of hours after which an
hours) unassigned alert is moved to another queue.
Move Alert To Different Select the name of the queue where unassigned alerts should
Queue be moved, typically a higher priority queue.
Raise Action Select the action to be raised, if applicable.

Chapter 12. Configuring Alert Queues 307


Table 93. Unassigned Alerts Tab (continued)
Field Description
Re-Alert After (in hours) Enter the number of elapsed hours before a re-alert is
generated.

Defining How Unresolved Alerts are Handled Based on Time


About this task

You can configure unresolved alerts to be escalated to another queue, raise an


action after a given amount of time passes, or both.

Note: You cannot resolve unassigned alerts.

To set up a time-based escalation for unresolved alerts:

Procedure
1. In the Queue Details window, choose the Unresolved Alerts tab.
2. Enter information in the applicable fields. Refer to the following table for field
value descriptions.

Table 94. Unresolved Alerts Tab


Field Description
Escalate Alert After (in Enter the maximum number of hours an alert can remain
hours) unresolved in this queue.
Move Alert To Different Select the name of the queue where unresolved alerts should
Queue be moved, typically a higher priority queue.
Raise Action Select the action to be raised, if applicable.
Re-Alert After (in hours) Enter the number of elapsed hours before a re-alert is
generated.

Viewing an Alert Queue's User List


About this task

You can view the users that are subscribed to an alert queue and modify their
subscription details. For more information about users, see “Defining Users” on
page 187.

To view and modify users subscribed to a queue:

Procedure
1. In the Queue Details window, choose the User List tab. The User Detail list
displays.

308 Sterling Selling and Fulfillment Foundation: Application Platform Configuration Guide
2. Select the applicable user and choose . The User Detail window displays.
For more information about how to modify a user, see “Creating a User” on
page 187.

3. To remove a user from the queue choose .

Modifying an Alert Queue


About this task

Once an alert queue has been defined, it can be modified.

To modify an alert queue:

Procedure
1. From the tree in the application rules side panel, choose Queue Management.
The Queue Search window displays in the work area.

2. Enter applicable search criteria and choose . The Queue list displays.

3. Select the applicable queue and choose . The Queue Details window
displays.
4. Refer to the topics under “Creating an Alert Queue” on page 305 for assistance.

Deleting an Alert Queue


About this task
To delete an alert queue:

Procedure
1. From the tree in the application rules side panel, choose Queue Management.
The Queue Search window displays in the work area.

2. Enter applicable search criteria and choose . The Queue list displays.

3. Select the applicable queue and choose .

Chapter 12. Configuring Alert Queues 309


310 Sterling Selling and Fulfillment Foundation: Application Platform Configuration Guide
Chapter 13. Configuring Region Definitions
Region definitions allows you to configure the components that are used by the
Sterling Selling and Fulfillment FoundationSterling Application Platform
geography engines. The individual components consisting of regions and region
levels can be used to create region schemas that can then be used throughout
Sterling Selling and Fulfillment FoundationSterling Application Platform business
application models whenever geography is considered (for example, when
determining the regions a delivery service delivers to).

Defining Region Levels


A region level classifies regions into distinct categories. You can define region
levels such as Country or Region, State, County, City, and so on, based on the
levels at which you want to aggregate your regions, and define the address field a
region level corresponds to. Region levels also allow users to create a region
hierarchy.

Creating a Region Level


About this task

To create a region level:

Procedure
1. From the tree in the application rules side panel, choose Region Definition >
Region Levels. The Region Levels window displays in the work area.

2. Choose . The Region Level Details window displays.


3. Enter information in the applicable fields. Refer to the following table for field
value descriptions.
4. Choose .

© Copyright IBM Corp. 1999, 2011 311


Table 95. Region Level Details Window
Field Description
Region Level Name Enter the name of the region level.
Description Enter a brief description of the region level.
This Region Level Select the corresponding address field for this region level
Corresponds To from the drop-down list. For more information about region
matching, see “Defining Region Match Preferences” on page
313.
This Region Level Can Be Select This Region Level Can Be Defined By A Set Of Postal
Defined By A Set Of Postal Codes if you want to indicate that regions associated with
Codes this region level can define a postal code range. This is used
to default the Postal Codes Define This Region field when
defining a region for this region level only.
Valid Child Region Levels If this region has any child region levels that have already
been defined, select the applicable region levels from the
Available table and choose the right-arrow button.

Note: We recommend creating region levels from the lowest region level to the
highest. For example, you create a region level called Town. Then you create a
region level called County. Since Town was created earlier you can move it
under County at the same time you are creating the County region level.

Note: If you had created County first, you would have had to close it, then
create Town, then close Town and reopen County to add Town beneath it.

Modifying a Region Level


About this task

To modify a region level:

Procedure
1. From the tree in the application rules side panel, choose Region Definition >
Region Levels. The Region Levels window displays in the work area.

2. Select the applicable region level and choose . The Region Level Details
window displays.
3. Enter information in the applicable fields. Refer to Table 95 for field value
descriptions.

4. Choose .

Deleting a Region Level


About this task

To delete a region level:

Procedure
1. From the tree in the application rules side panel, choose Region Definition >
Region Levels. The Region Levels window displays in the work area.

2. Select the applicable region level and choose .

312 Sterling Selling and Fulfillment Foundation: Application Platform Configuration Guide
Defining Region Match Preferences
Region match preferences allow you to specify the level at which addresses should
be matched to regions, for each country or region. For more information about
region matching, see the Sterling Selling and Fulfillment Foundation: Product Concepts
Guide.

Setting a Region Match Preference


About this task

To set a region match preference:

Procedure
1. From the tree in the application rules side panel, choose Region Definition >
Region Match Preferences. The Region Match Preferences window displays in
the work area.
2. Enter information in the applicable fields. Refer to the following table for field
value descriptions.

3. Choose .
Table 96. Region Match Preferences
Field Description
Country/Region Select the country or region code from the drop-down list.
Find Regions By Select the address field to match regions to for the specified
country or region.

Deleting a Region Match Preference


About this task

To delete a region match preference

Procedure
1. From the tree in the application rules side panel, choose Region Definition >
Region Match Preferences. The Region Match Preferences window displays in
the work area.

2. Select the applicable region match preference and choose .

Defining Region Schemas


A region schema is the complete hierarchical set of regions that define a given
geography. A region is configured as a specific territory. For example, you can
create a region for a complete state, city, or town.

You can create a region hierarchy by defining certain regions as a parent region of
a smaller region.

Creating a Region Schema


About this task

To create a region schema:

Chapter 13. Configuring Region Definitions 313


Note: Region schemas should be created from the top down. For example, if your
region schema consists of country, state, and city regions, you need to create the
country region first, then states, followed by cities.

Procedure
1. From the tree in the application rules side panel, choose Region Definition >
Region Schemas. The Region Schemas window displays in the work area.

2. Choose . The Region Schema Details window displays.


3. Enter information in the applicable fields. Refer to the following table for field
value descriptions.

4. Choose .
Table 97. Region Schema Details Window
Field Description
Region Schema Name Enter the name of the region schema.
Country/Region Select the country or region in which the region schema is
located (can be the whole country or region, a territory in the
country or region, and so forth). This field is optional and is
only used for defaulting a country or region when entering
postal code ranges when defining an individual region.
Description Enter a brief description of the region schema.
Regions A graphical representation of the region hierarchy.

Creating a Region
About this task

To create a region:

Procedure
1. In the Region Schema Details window, highlight a region in the region
hierarchy under which you want to add a new region and choose . The
Region Details window displays.
2. Enter information in the applicable fields. Refer to the following table for field
value descriptions.

3. Choose .
Table 98. Region Details Window
Field Description
Level Select the region's level. For more information about region
levels, see “Defining Region Levels” on page 311.
Region Name Enter the name of the region.

If a region level has been selected that maps to the


‘Country/Region' field, this field provides a drop-down of
available country or region codes to select from.

314 Sterling Selling and Fulfillment Foundation: Application Platform Configuration Guide
Table 98. Region Details Window (continued)
Field Description
Postal Codes Define This Check this box if you want to define this region by one or
Region more postal codes.

Checking this box enables the Postal Code Ranges table.

If the region level you have selected for this region does not
have the "This Region Level Can Be Defined By A Set Of
Postal Codes" option checked, then this checkbox is disabled.

For more information of defining region levels, see “Defining


Region Levels” on page 311.
Postal Code Ranges If you selected Postal Codes Define This Region, enter the
postal code range of the region you are configuring and select
the country or region in which the postal codes are defined
for.

Modifying a Region
About this task

To modify a region:

Procedure
1. In the Region Schema Details window, select the applicable region from the
region hierarchy and choose . The Region Details window displays.
2. Enter information in the applicable fields. Refer to Table 98 on page 314 for
field value descriptions.
3. Choose .

Deleting a Region
About this task

To delete a region, select the applicable region in the Region Details window and
choose .

Note: All child regions are also deleted.

Modifying a Region Schema


About this task

To modify a region schema:

Procedure
1. From the tree in the application rules side panel, choose Region Definition >
Region Schemas. The Region Schemas window displays in the work area.
2. Select the applicable region schema and choose . The Region Schema Details
window displays.
3. Enter information in the applicable fields. Refer to Table 97 on page 314 for
field value descriptions.

4. Choose .

Chapter 13. Configuring Region Definitions 315


Deleting a Region Schema
About this task

To delete a region schema:

Procedure
1. From the tree in the application rules side panel, choose Region Definition >
Region Schemas. The Region Schemas window displays in the work area.

2. Select the applicable region schema and choose .

316 Sterling Selling and Fulfillment Foundation: Application Platform Configuration Guide
Chapter 14. Configuring Devices
A warehouse consists of a number of hand-held and stationary devices. These
devices have their unique definitions and sometimes are associated specifically to
stations or equipment. Examples of devices include printer, RF scanner and
weighing scale.

Each individual group of devices is represented as a device type and sub-type


combination. A device and its unique communication requirements are represented
when each device is configured.

Defining a Device Type


All devices are associated with a Device Type in Sterling Selling and Fulfillment
FoundationSterling Application Platform. An individual unit is defined as a sub
type for a device type.

For example, device types include RF scanners, printers, and weighing scale.

Creating a Device Type


About this task

To create a device type:

Procedure
1. From the tree in the application rules side panel, choose Device. The Device
Setup window displays.

© Copyright IBM Corp. 1999, 2011 317


2. In the Device Setup window, choose . The Device Type pop-up window
displays.
3. Enter information in the applicable fields. Refer to the following table for field
value descriptions.

4. Choose .

318 Sterling Selling and Fulfillment Foundation: Application Platform Configuration Guide
Table 99. Device Type Pop-up Window
Field Description
Device Type Enter a name for the device type.

This helps in identifying the type of device. For example,


device type may be weighing scale or printer.
Description Enter a brief description for the device type.

Modifying a Device Type


About this task

Once a Device Type has been created, it can be modified.

To modify a device type:

Procedure
1. From the tree in the application rules side panel, choose Device.
2. The Device Setup window displays with the list of Device Types.

3. Select the Device Type to be modified. Choose .


4. The Device Type pop-up window displays.
5. Enter information in the applicable fields. Refer Table 99 for field value
descriptions.

6. Choose .

Deleting a Device Type


About this task

To delete a device type:

Procedure
1. From the tree in the application rules side panel, choose Devices.
2. The Device Setup window displays with the list of Device Types.

3. Select the Device Type to be deleted. Choose .

Defining a Device Sub Type


A Device Sub Type categorizes a device type.

For example, a device type of Printers is further categorized or sub-typed into HP


LaserJet 5P, Eltron, Unimark, and Zebra 170. Each individual sub-type allows for
device configuration and its respective parameters.

Other examples include sub types of hand-held scanner models and equipment
mounted models used under a device type of RF Scanners.

Creating a Device Sub Type


About this task

To create a device sub type:

Chapter 14. Configuring Devices 319


Procedure
1. From the tree in the application rules side panel, choose Device. The Device
Setup window displays.
2. In the Device Setup window, select Device Type whose Device Sub Type is to
be created.
3. Choose . The Device Sub Type pop-up window displays.
4. Enter information in the applicable fields. Refer to the following table for field
value descriptions.

5. Choose .

Table 100. Device Sub Type Pop-up Window


Field Description
Device Type Device Type indicates the device type for which the device
sub type is being created.

This is populated by the system, based on the selection of


device type in the Device Setup window.
Device Sub Type Enter a name for the device sub type.
Description Enter a brief description for the device sub type.
Printer Type Document Association
This panel is available when the value of the Device Type is set to "Printer."
Printer Type Document Select which print documents you would like to associate
Association with the selected printer.

Note: If you are configuring a new Device Sub Type for printing the FedEx
Carrier Label, ensure that you map the value of the new Device Sub Type in
the YCS Mapping table. For more information about the YCS Mapping table,
see the Parcel Carrier: Adapter Guide.

320 Sterling Selling and Fulfillment Foundation: Application Platform Configuration Guide
Modifying a Device Sub Type
About this task

Once a Device Sub Type has been created, it can be modified.

To modify a device sub type:

Procedure
1. From the tree in the application rules side panel, choose Device. The Device
Setup window displays.
2. In the Device Setup window, select the Device Type whose Device Sub Type is
to be modified. The list of Device Sub Type is now displayed.
3. Select the Device Sub Type to be modified. Choose .
4. The Device Sub Type pop-up window displays.
5. Enter information in the applicable fields. Refer Table 100 on page 320 for field
value descriptions.

6. Choose .

Deleting a Device Sub Type


About this task

To delete a device sub type:

Procedure
1. From the tree in the application rules side panel, choose Device. The Device
Setup window displays.
2. In the Device Setup window, select the Device Type whose Device Sub Type is
to be deleted. The list of Device Sub Type is now displayed.
3. Select the Device Sub Type to be deleted.
4. Choose .

Defining a Device
A device represents an actual device existing on the network, or directly connected
to a station or equipment. All instances of a device type and sub-type combination
require to be defined as devices.

For example, a warehouse that has five HP LaserJet 5P printers and four Zebra
R140 printers has all the nine printers configured as devices.

Creating a Device Overview


Sterling Selling and Fulfillment FoundationSterling Application Platform supplies a
list of standard device type, sub type and individual devices that is supported. The
definition of a new device type, sub type and resultant device requires the creation
of the appropriate attributes that define the communication with the device.

The list of attributes that control communication to a printer are:


v DropDirectory - The directory where the print files are ‘dropped' by the Sterling
Selling and Fulfillment FoundationSterling Application Platform Server. The
Loftware Print Server keeps polling this directory to pick up print requests.

Chapter 14. Configuring Devices 321


When mentioning the directory structure you can use the full path name or
replace the path name with a variable. For more information about including
this variable, see the Sterling Selling and Fulfillment Foundation: Extending the
Condition Builder.

Note: The DropDirectory attribute appears in the Applications Manager only if


the yfs.loftware.tcpip.sockets property is set to N in the <INSTALL_DIR>/
properties/customer_overrides.properties file.

Note: For information about overriding properties using the


customer_overrides.properties file, see the Sterling Selling and Fulfillment
Foundation: Properties Guide.
v PrinterAlias - The printer alias as configured in the Loftware printer setup.

Note: While setting up a Printer device in Sterling Selling and Fulfillment


FoundationSterling Application Platform, ensure that the Printer Alias is exactly
the same as specified in the Loftware printer set-up.

Note: In instances where a network printer is used, ensure that the Printer Alias
on Sterling Selling and Fulfillment FoundationSterling Application Platform does
NOT contain the prefix "\\". However, Loftware may require the printer to be
defined by prefixing "\\".
v PrinterServerHostName - The host name for the Loftware Print Server. While IP
Address may be sufficient, the use of host name is recommended for ease of
maintenance.
v PrintServerPort - The port on which Loftware Print Server listens for print
requests. By default, the print server port for Loftware Print Server is 2723.

Note: The PrinterServerHostName and PrintServerPort attributes appear in the


Applications Manager only if the yfs.loftware.tcpip.sockets property is set to
Y in the <INSTALL_DIR>/properties/customer_overrides.properties file.

Note: For information about overriding properties using the


customer_overrides.properties file, see the Sterling Selling and Fulfillment
Foundation: Properties Guide.

The list of attributes that control communication to a weighing scale are:


v ClassName
v PortId
v BaudRate
v DataBits
v StopBits
v Parity
v FlowIn
v FlowOut

Note: The ClassName for the Mettler Toledo Weighing Scale is


com.yantra.ycp.ui.io.YCPToledoPSImpl. For specifications pertaining to the
other attributes, see the weighing scale user manual.

322 Sterling Selling and Fulfillment Foundation: Application Platform Configuration Guide
Creating a Device
About this task

To create a device:

Procedure
1. From the tree in the application rules side panel, choose Device. The Device
Setup window displays.
2. In the Device Setup window, select the relevant Device Type and Device Sub
Type whose Device is to be created.

3. Choose . The Device pop-up window displays.


4. Enter information in the applicable fields. Refer Table 100 on page 320 for field
value descriptions.

5. Choose .

Chapter 14. Configuring Devices 323


Table 101. Device Pop-up Window
Field Description
Device Type Device Type indicates the device type for which the device is
being created.

This is populated by the system, based on the selection of


device type in the Device Setup window.
Device Sub Type Device Sub Type indicates the device sub type for which the
device is being created.

This is populated by the system, based on the selection of


device sub type in the Device Setup window.
Device ID Enter the name for the device.

This identifies the device throughout the system.


Device Attributes This indicates the additional attributes of the device.

For more information about setting up a device attribute,


refer to “Setting Up a Device Attribute”.

Setting Up a Device Attribute


About this task

Device attributes define the method of communication with the appropriate device.
An HP LaserJet printer has a different parameter list in comparison to a weighing
scale. Each individual brand of printer also has its own unique set of parameters
and values.

For example, a weighing scale connected through a serial port has specific device
attributes including stop bits, parity.

To set up a device attribute:

324 Sterling Selling and Fulfillment Foundation: Application Platform Configuration Guide
Procedure
1. In Device Attributes panel of the Device pop-up window, choose .
2. The Criteria Parameter Details pop-up window displays.
3. Enter information in the applicable fields. Refer Table 102 for field value
descriptions.

4. Choose .

Table 102. Criteria Parameter Details Pop-up Window


Field Description
Parameter Name Enter the parameter name for the device attribute.
Parameter Value Enter the parameter value for the device attribute.

Overview of Creating a New Device from a Device


Sterling Selling and Fulfillment FoundationSterling Application Platform supplies a
list of standard device type, sub type and individual devices that is supported. The
definition of a new device type, sub type and resultant device requires the creation
of the appropriate attributes that define the communication with the device.

The list of attributes that control communication to a printer are:


v DropDirectory - The directory where the print files are ‘dropped' by the Sterling
Selling and Fulfillment FoundationSterling Application Platform Server. The
Loftware Print Server keeps polling this directory to pick up print requests.
When mentioning the directory structure you can use the full path name or
replace the path name with a variable. For more information about including
this variable, see the Sterling Selling and Fulfillment Foundation: Extending the
Condition Builder .

Note: The DropDirectory attribute appears in the Applications Manager only if


the yfs.loftware.tcpip.sockets property is set to N in the <INSTALL_DIR>/
properties/customer_overrides.properties file.

Note: For information about overriding properties using the


customer_overrides.properties file, see the Sterling Selling and Fulfillment
Foundation: Properties Guide.
v PrinterAlias - The printer alias as configured in the Loftware printer setup.

Note: While setting up a Printer device in Sterling Selling and Fulfillment


FoundationSterling Application Platform, ensure that the Printer Alias is exactly
the same as specified in the Loftware printer set-up.

Chapter 14. Configuring Devices 325


Note: In instances where a network printer is used, ensure that the Printer Alias
on Sterling Selling and Fulfillment FoundationSterling Application Platform does
NOT contain the prefix "\\". However, Loftware may require the printer to be
defined by prefixing "\\".
v PrinterServerHostName - The host name for the Loftware Print Server. While IP
Address may be sufficient, the use of host name is recommended for ease of
maintenance.
v PrintServerPort - The port on which Loftware Print Server listens for print
requests. By default, the print server port for Loftware Print Server is 2723.

Note: The PrinterServerHostName and PrintServerPort attributes appear in the


Applications Manager only if the yfs.loftware.tcpip.sockets property is set to
Y in the <INSTALL_DIR>/properties/customer_overrides.properties file.

Note: For information about overriding properties using the


customer_overrides.properties file, see the Sterling Selling and Fulfillment
Foundation: Properties Guide.

The list of attributes that control communication to a weighing scale are:


v ClassName
v PortId
v BaudRate
v DataBits
v StopBits
v Parity
v FlowIn
v FlowOut

For more information about creation of the appropriate attributes, see “Setting Up
a Device Attribute” on page 324.

Note: The ClassName for the Mettler Toledo Weighing Scale is


com.yantra.ycp.ui.io.YCPToledoPSImpl. For specifications pertaining to the other
attributes, see the weighing scale user manual.

Creating a New Device from a Device


About this task

To create a new device from a device:

Procedure
1. From the tree in the application rules side panel, choose Device. The Device
Setup window displays.
2. In the Device Setup window, select the relevant Device Type and Device Sub
Type whose Device is to be copied.
3. The list of Devices displays. Select the Device to be copied to create a new
device.

4. Choose . The Device pop-up window displays.


5. Enter information in the applicable fields. Refer to Table 100 on page 320 for
field value descriptions.

6. Choose .

326 Sterling Selling and Fulfillment Foundation: Application Platform Configuration Guide
Modifying a Device
About this task

Once a Device has been created, it can be modified.

To modify a device:

Procedure
1. From the tree in the application rules side panel, choose Device. The Device
Setup window displays.
2. In the Device Setup window, select the relevant Device Type and Device Sub
Type whose Device is to be modified.
3. The list of Devices displays. Select the Device to be modified.

4. Choose . The Device pop-up window displays.


5. Enter information in the applicable fields. Refer to Table 100 on page 320 for
field value descriptions.
6. Choose .

Deleting a Device
About this task

To delete a device:

Procedure
1. From the tree in the application rules side panel, choose Device. The Device
Setup window displays.
2. In the Device Setup window, select the relevant Device Type and Device Sub
Type whose Device is to be deleted.
3. The list of Devices displays. Select the Device to be deleted.
4. Choose .

Chapter 14. Configuring Devices 327


328 Sterling Selling and Fulfillment Foundation: Application Platform Configuration Guide
Chapter 15. Configuring Prints
The operation of a warehouse requires numerous documents, be it labels or
reports, to be printed daily. The printing of the documents is either initiated by the
occurrence of specific events or is requested ad-hoc by a user.

For example, carrier labels being printed at a manifest station after carton is
scanned or a truck manifest (MBOL) being requested when a trailer loading is
complete and truck is ready to close.

Documents are printed either individually or in a set or group. A document set


consists of multiple documents that are related to individual activity that is
performed.

For example, the release of a wave triggers print of wave summary report, carton
content labels, batch sheets, and packing slips.

Examples of documents printed in a warehouse include packing lists, BOL, carrier


labels, SKU labels, and UCC128 SCM labels.

Sterling Selling and Fulfillment FoundationSterling Application Platform provides


standard documents that include:
v Batch Sheet for picking
v Cart Manifest for picking
v Packing Slip
v VICS Bill Of Lading (BOL)
v UCC-128 compliant 4x6 Shipping Labels including WALMART® compliance
v UPS Standard carrier labels
v Wave release prints document set consisting of one or more of the above prints

Sterling Selling and Fulfillment FoundationSterling Application Platform provides


standard documents that include:

A specific document has a label format and device sub type associated to it.

The association of a print document to the device sub type (for example, packing
slips on HP LaserJet printers) is done through setting up a device sub type. For
more information about setting up a device sub type, see “Defining a Device Sub
Type” on page 319.

The association of a document to a label format and name is done here.

Defining Print Documents


A document is assigned a name and a corresponding label format here. Sterling
Selling and Fulfillment FoundationSterling Application Platform provides a
standard list of documents for the prints supported.

For example, VICS BOL is associated with the VICS BOL label format.

Print documents and label formats created are at the HUB level.

© Copyright IBM Corp. 1999, 2011 329


Creating a Print Document
About this task

To create a print document:

Procedure
1. From the tree in the application rules side panel, choose Prints > Print
Documents. The Print Documents window displays with Sterling Selling and
Fulfillment FoundationSterling Application Platform default print documents.
2. Enter information in the applicable fields. Refer to the following table for field
value descriptions.

3. Choose .

Table 103. Print Documents Window


Field Description
Print Document Enter name of the document to be printed.
Document Description Enter a brief description of the print document.

330 Sterling Selling and Fulfillment Foundation: Application Platform Configuration Guide
Table 103. Print Documents Window (continued)
Field Description
Save Directory Enter the directory path where the print document is saved.

This is used for documents that are pre-generated but printed


on demand at a later time.

Typical example is a packing list that is pre-generated, but


printed when last carton is scanned.

If you are using variables instead of the full path names


ensure that the variable is set in the <INSTALL_DIR>/
properties/customer_overrides.properties file. For
additional information about overriding properties using the
customer_overrides.properties file, see the Sterling Selling
and Fulfillment Foundation: Properties Guide.
Default Label Format Choose the default label format for printing.

This indicates the default label format for this document


across all organizations. Label format is the name of the label
design file (.LWL) created using Loftware Label Manager™.

Modifying a Print Document


About this task

Once a Print Document has been created, it can be modified.

To modify a print document:

Procedure
1. From the tree in the application rules side panel, choose Prints > Print
Documents. The Print Documents window displays with a list of print
documents.
2. Enter information in the applicable fields. Refer Table 103 on page 330 for field
value descriptions.
3. Choose .
Do not modify the standard print documents provided by the Sterling Selling
and Fulfillment FoundationSterling Application Platform.

Deleting a Print Document


About this task

To delete a print document:

Procedure
1. From the tree in the application rules side panel, choose Prints → Print
Documents. The Print Documents window displays with a list of print
documents.
2. Choose the Print Document to be deleted.
3. Choose .
4. Do not delete the standard print documents provided by the Sterling Selling
and Fulfillment FoundationSterling Application Platform.

Chapter 15. Configuring Prints 331


Defining Label Formats
Label formats corresponding to the documents are defined here. This allows
association of a label format to the Loftware™ label format and the mapping XML
file.

The Loftware™ label format associated here is created using Loftware™ tools. The
mapping XML file is created using the Sterling Selling and Fulfillment
FoundationSterling Application Platform-supplied toolkit. The field binding
between the fields in the label and the field in the standard XML published are
specified in the mapping XML.

See the Sterling Selling and Fulfillment Foundation: Installation Guide for further
information about installing and configuring Loftware Label Manager™.

Sterling Selling and Fulfillment FoundationSterling Application Platform provides


standard label formats and mapping files for all standard documents supported. A
print is executed through a service flow defined in the Service Definition
Framework (SDF). Sterling Selling and Fulfillment FoundationSterling Application
Platform provides data flow for the standard documents provided.

Creating a Label Format


About this task

To create a label format:

Procedure
1. From the tree in the application rules side panel, choose Prints > Label
Formats. The Label Formats window displays with the Sterling Selling and
Fulfillment FoundationSterling Application Platform default label formats.

332 Sterling Selling and Fulfillment Foundation: Application Platform Configuration Guide
2. In the Label Formats window, choose . The Label Details pop-up window
displays.
3. Enter information in the applicable fields. Refer to the following table for field
value descriptions.

4. Choose .

Chapter 15. Configuring Prints 333


Table 104. Label Details Pop-up Window
Field Description
Label Format Name Enter the name of the label format for this label.

Label format is the name of the .lwl (Label Design) file


created using Loftware Label Manager™.
Label Format File Name Enter the name of the Loftware™ designed ‘.LWL' file for this
label.

For custom labels, enter the file name as extn/ followed by


'.lwl' file.
Mapping XML File Name Enter the file name for the mapping XML for this label.

Mapping XML contains the binding or association between


the events published XML and the field names used in the
label definition.

For custom labels, enter the file name as extn/ followed by


'.lwl' file.

Modifying a Label Format


About this task

Once a Label Format has been created, it can be modified.

To modify a label format:

Procedure
1. From the tree in the application rules side panel, choose Prints > Label
Formats. The Label Formats window displays with a list of label formats.

2. Select the Label Format you want to modify and choose .


3. Enter information in the applicable fields. Refer Table 104 for field value
descriptions.
4. Choose .
Do not to modify the standard label formats provided by the Sterling Selling
and Fulfillment FoundationSterling Application Platform.

Deleting a Label Format


About this task

To delete a label format:

Procedure
1. From the tree in the application rules side panel, choose Prints > Label
Formats. The Label Formats window displays with a list of label formats.
2. Choose the Label Format to be deleted.

3. Choose .
Do not to delete the standard label formats provided by the Sterling Selling and
Fulfillment FoundationSterling Application Platform.

334 Sterling Selling and Fulfillment Foundation: Application Platform Configuration Guide
Chapter 16. Managing Password Policies
Sterling Selling and Fulfillment Foundation provides an in-built and flexible
password management policy for controlling password use and behavior. A
password policy is a set of rules to define, control, and manage user passwords. A
set of default rules is provided; however, you can configure your own rules for the
password policy.

For detailed information about managing password policies, see the Sterling Selling
and Fulfillment Foundation: Password Policy Management .

© Copyright IBM Corp. 1999, 2011 335


336 Sterling Selling and Fulfillment Foundation: Application Platform Configuration Guide
Chapter 17. Configuring Alerts
An alert is a message directed to a user or an alert queue about a transaction that
needs manual intervention. An alert can come in different formats including
e-mail, faxes, and so on.

When configuring alerts, you can create exceptions to classify them in one or more
types. When creating exception types, you can assign priority and high priority
number to the exception types. You can also specify whether or not the
consolidation for an exception type is required. You can configure consolidation for
an exception type by specifying the consolidation window and consolidation User
Exit (UE) implementation. You can configure the context sensitive resolution screen
for an exception type by specifying the resolution form and resolution UE
implementation. In addition, you can define some additional configurations for an
exception type by specifying the configuration form and list form.

You have to associate an exception type to an application such as PCA or a role


such as BUYER and SELLER. You can configure one or more exception types for
an organization. You can also create routing rules for an organization level
exception type and use a particular routing logic for routing these exception types
to a specific alert queue.

Creating an Exception Type


About this task

To create an exception type:

Procedure
1. From the tree in the application rules side panel, choose Alerts > Exception
Type. The Alert Type window displays in the work area.

2. Choose . The Exception Type Details window displays.


3. Enter information in the applicable fields. Refer to the following table for field
value descriptions.

4. Choose .

© Copyright IBM Corp. 1999, 2011 337


Figure 30. Exception Type Details Window

Table 105. Exception Type Details Pop-Up Window


Field Description
Exception Type Enter name for the new exception type to be created.
This is a mandatory field.
Exception Type Description Enter a brief description of the exception type. This is a
mandatory field.
Priority Enter the priority for the exception type.
High Priority Number Enter the threshold number for the high priority
exceptions of this type.
Expiration Days Enter the number of days after which the exception type
should expire.
Followup Hours Enter the number of hours in which the exception type
should be followed up.
Queue Select the name of the alert queue to which the exception
type is routed. For more information about creating alert
queues, see Chapter 12, “Configuring Alert Queues,” on
page 305.
Owner Role Select the role to which the organization belongs from
the drop-down list.
Configurable Check this box if you want to define additional
configurations for the exception type.
Consolidation Hook Enter the name of the class which provides the
implementation for the consolidation of the exception
type.

338 Sterling Selling and Fulfillment Foundation: Application Platform Configuration Guide
Table 105. Exception Type Details Pop-Up Window (continued)
Field Description
Resolution Hook Enter the name of the class which provides the
implementation for the resolution of the exception type.
Consolidation Required Check this box if you want to consolidate the exceptions
of this type.
Consolidation Window Enter the information about the window that is to be
used for consolidating exceptions of this type. The valid
values are: HOUR, DAY, and FOREVER.
Configuration Form Enter the information about the form that is to be used
to capture the additional configuration for the exception
type.
Resolution Form Enter the information about the form to be launched to
resolve this type of exception.
List Form Enter the information about the form to list the
exceptions for the exception type.

Modifying an Exception Type


About this task

Once an exception type has been created, it can be modified.

To modify an exception type:

Procedure
1. From the tree in the application rules side panel, choose Alert > Exception
Type.
2. The Alert Type window displays with the list of Alert Types.

3. Select the Alert Type to be modified. Choose .


4. Enter information in the applicable fields. Refer Table 105 on page 338 for field
value descriptions.
5. Choose .

Deleting an Exception Type


About this task

To delete an exception type:

Procedure
1. From the tree in the application rules side panel, choose Alert > Exception
Type.
2. The Alert Type window displays with the list of Alert Types.
3. Select the Alert Type to be deleted. Choose .

Defining Exception Type Role


You can specify a list of exception types for an application, such as PCA, and a
role, such as BUYER or SELLER, that the application supports.

Chapter 17. Configuring Alerts 339


Creating an Exception Type Role
About this task

To create an exception type role:

Procedure
1. From the tree in the application rules side panel, choose Alerts > Exception
Type Role. The Exception Type Role window displays in the work area.

2. Choose . The Exception Type Role Details window displays.


3. Enter information in the applicable fields. Refer to the following table for field
value descriptions.

4. Choose .

Table 106. Exception Type Role Details Pop-Up Window


Field Description
Application Code Select the code of the application. This is a mandatory
field.
Role Select the role. For example: BUYER, NODE, and so
forth.
Exception Type Select the exception type that you want to associate with
an application and role.

Modifying an Exception Type Role


About this task

Once an exception type role has been created, it can be modified.

To modify an exception type role:

Procedure
1. From the tree in the application rules side panel, choose Alert > Exception Type
Role.
2. The Exception Type Role window displays with the list of Exception Type roles.

3. Select the Exception Type role to be modified. Choose .


4. Enter information in the applicable fields. Refer Table 106 for field value
descriptions.

5. Choose .

340 Sterling Selling and Fulfillment Foundation: Application Platform Configuration Guide
Deleting an Exception Type Role
About this task

To delete an exception type role:

Procedure
1. From the tree in the application rules side panel, choose Alert > Exception Type
Role.
2. The Exception Type Role window displays with the list of Exception Type roles.
3. Select the Exception Type role to be deleted. Choose .

Defining Organization Exception Type Configuration


Organization Exception Type Configuration allows you to activate or override
additional parameters for an exception type at an organization level. These
attributes are used by the alert routing service builder component. You can also
create multiple routing rules for an organization level exception type. The routing
rules indicate the type of routing. When creating a routing rule, you can specify
the routing logic that you want to use for routing the organization level exception
types to a particular queue.

Creating an Exception Type for an Organization


About this task

To create an exception type for an organization:

Procedure
1. From the tree in the application rules side panel, choose Alerts > Organization
Exception Type Configuration. The Exception Type for Organization window
displays in the work area.
2. Choose . The Exception Type for Organization Details window displays.
3. Enter information in the applicable fields. Refer to the following table for field
value descriptions.

4. Choose .

Table 107. Exception Type for Organization Details Pop-Up Window


Field Description
Exception Type Select the exception type that you want to associate with
an organization.
Priority Enter the priority for exceptions of this type.
Active Check this box if you want to activate exception of this
type for an organization.

Chapter 17. Configuring Alerts 341


Modifying an Exception Type for an Organization
About this task

Once an exception type for an organization has been created, it can be modified.

To modify exception type for an organization:

Procedure
1. From the tree in the application rules side panel, choose Alert > Organization
Exception Type Configuration.
2. The Organization Exception Type Configuration window displays with the list
of Exception Type configured for an organization.
3. Select the Exception Type to be modified. Choose .
4. Enter information in the applicable fields. Refer Table 107 on page 341 for field
value descriptions.
5. Choose .

Creating an Exception Routing Rule


About this task

To create an exception routing rule for an organization level exception type:

Procedure
1. From the tree in the application rules side panel, choose Alert > Organization
Exception Type Configuration. The Organization Exception Type for
Organization window displays in the work area.

2. Select the applicable exception type and choose . The Exception Type for
Organization Details window displays.

3. Choose . The Exception Routing Rule Details window displays.


4. Enter information in the applicable fields. Refer to the following table for field
value descriptions.

5. Choose .

Table 108. Exception Routing Rule Details Pop-Up Window


Field Description
Exception Routing Sequence Enter the exception routing sequence number.

342 Sterling Selling and Fulfillment Foundation: Application Platform Configuration Guide
Table 108. Exception Routing Rule Details Pop-Up Window (continued)
Field Description
Routing Type Select the appropriate type of routing rule. The valid
value are:
v Use Department's Queue—Select this routing rule if
you want to create the exception in the default queue
of the department.
v Use Specified Queue—Select this routing rule if you
want to create the exception in the specified queue.
v Use Interface to obtain Queue—Select this routing rule
if you want to configure a java class for determining
the queue in which the exception should be created.
v Route to Role—If you select this type of routing rule,
the SDF component picks up the seller or buyer
organizations. If routing configuration exists for the
organization the same rules are applied.
v Route to Custom Role—If you select this type of
routing rule, the SDF component picks up the custom
organization. If routing configuration exists for the
organization the same rules are applied.
v Route to Exception Types Queue—If you select this
routing rule, an exception is created in the default
queue configured for the exception type.
Queue Select the name of the alert queue to which the
exceptions of this type are routed. For more information
about creating alert queues, see Chapter 12, “Configuring
Alert Queues,” on page 305.
Java Class If you have specified the routing type as "Use Interface
to Obtain Queue", specify the java class which
implements the interface.
Routing Role Select the routing role. For example, BUYER, SELLER,
and so forth.
Custom Role Enter the custom role.
Email Required Check this box if you want to specify the e-mail id for
this exception routing rule.
Email Template Enter the template for the e-mails.
Email Id Enter the e-mail id for one of the following routing rules:
v Use Departments Queue
v Use Specified Queue
v Use Interface to Obtain Queue

Modifying an Exception Routing Rule


About this task

To modify an exception routing rule:

Procedure
1. From the tree in the application rules side panel, choose Alert > Organization
Exception Type Configuration. The Organization Exception Type for
Organization window displays in the work area.

Chapter 17. Configuring Alerts 343


2. Select the applicable exception type and choose . The Exception Type for
Organization Details window displays.

3. Select the applicable exception routing rule and choose . The Exception
Routing Rule Details window displays.
4. Enter information in the applicable fields. Refer Table 108 on page 342 for field
value descriptions.
5. Choose .

Deleting an Exception Routing Rule


About this task

To delete an exception routing role:

Procedure
1. From the tree in the application rules side panel, choose Alert > Organization
Exception Type Configuration. The Organization Exception Type for
Organization window displays in the work area.

2. Select the applicable exception type and choose . The Exception Type for
Organization Details window displays.

3. Select the applicable exception routing rule and choose .

Deleting an Exception Type for an Organization


About this task

To delete an exception type for an organization:

Procedure
1. From the tree in the application rules side panel, choose Alert > Organization
Exception Type Configuration.
2. The Organization Exception Type Configuration window displays with the list
of Exception Type configured for an organization.
3. Select the exception type to be deleted. Choose .

344 Sterling Selling and Fulfillment Foundation: Application Platform Configuration Guide
Chapter 18. Configuring Data Version Labels
Configuration data is an integral part of all implementations. Often, there is a need
to track changes to an implementation's configuration. Furthermore, if the changes
in configuration data are found to be inadequate, there is no easy way of rolling
back changes to their original states.

In an offsite and onsite implementation model, master configuration data is


maintained onsite, which is where the production environment is hosted. When a
patch must be applied to the production environment, offsite test developers must
write instructions regarding any configuration data changes for the patch and pass
it to the onsite configuration manager; that is, certain values of business rules need
to be changed. The onsite configuration manager has to replicate the configuration
changes onto the production environment.

To make it easier to track versions of configuration data, or sets of changes to


configuration data, Sterling Selling and Fulfillment Foundation[Sterling Application
Platform] includes the Configuration Data Versioning Tool, which is part of the
Configuration Deployment Tool (CDT). It enables you to capture changes from a
source database, compare and deploy them onto a target database (this can be the
same or a different database).

The config table must have AuditRequired set to Y and the table name must exist
in config_db.xml

Note: To enable this functionality the configuration table must have AuditRequired
flag set to Y. By default, most of the configuration tables have AuditRequired flag
set to Y.

You can create version labels in the Applications ManagerConfigurator to represent


timestamps in a time line when changes occur in configuration data. The system
can then identify any changes in the configuration data between timestamps of
version labels based on the audit information in the system.

The Configuration Versioning Tool allows you to select different version labels
from a source database and compare the data and apply them to a target database.
You can see the details of each difference and detect conflicts. Once all conflicts are
resolved, you can deploy the changes. For more information about this tool, see the
Sterling Selling and Fulfillment Foundation: Configuration Deployment Tool Guide.

Creating Configuration Data Version Labels


About this task

Before you can use the comparison tools, you must create version labels for the
databases using the Applications ManagerConfigurator.

To create Configuration Version Labels:

Procedure
1. In the Applications ManagerConfigurator, select Application Platform.
2. Select Configuration Version Labels.

© Copyright IBM Corp. 1999, 2011 345


The Configuration Version Labels screen is displayed on the right-hand panel.
You can filter existing version labels based on Version Label ID and version
label timestamps, and manage version labels based on the filter results.

3. To create or modify a new label, click and enter a version label ID and
description of the label.

4. Click .
Table 109. Label Details Pop-up Window
Field Description
Version Label ID Enter the name of the identifier for this label.
Description Enter a description for this label.
Time The current timestamp displays by default for this label.

Modifying Configuration Data Version Labels


About this task

Once a Configuration Version Label has been created, it can be modified.

To modify a configuration version label:

Procedure
1. In the Applications ManagerConfigurator, select Application Platform.
2. Select Configuration Version Labels.
The Configuration Version Labels screen is displayed on the right-hand panel.

3. Select the Version Label ID you want to modify and choose .


4. Enter information in the applicable fields. Refer Table 109 for field value
descriptions.

5. Choose .

Deleting Configuration Data Version Labels


About this task

To delete configuration version label:

346 Sterling Selling and Fulfillment Foundation: Application Platform Configuration Guide
Procedure
1. In the Applications ManagerConfigurator, select Application Platform.
2. Select Configuration Version Labels.
The Configuration Version Labels screen is displayed on the right-hand panel.
3. Select the Version Label ID you want to delete.

4. Choose .

Chapter 18. Configuring Data Version Labels 347


348 Sterling Selling and Fulfillment Foundation: Application Platform Configuration Guide
Chapter 19. Configuring Qualified Tag Information
Qualified Tag Information branch is used to define Qualified Tag and Qualified
Tag Types pertaining to rules and common codes.

QUALIFIED TAG

You can configure Qualified Tag to associate a rule or a common code to a


particular Sterling Application PlatformSterling Selling and Fulfillment Foundation
version. You can define different rules and common codes based on the Qualified
Tag. You can then associate a Qualified Tag to a particular Sterling Application
PlatformSterling Selling and Fulfillment Foundation.

QUALIFIED TAG TYPE

Qualified Tag Type is used to configure the class that will validate the Qualified
Tags against a particular Sterling Application PlatformSterling Selling and
Fulfillment Foundation version. You can associate a particular Qualified Tag Type
with one or more Qualified Tags.

Note: If you configure two Qualifier Tags, Q1 and Q2, with Q1 being valid for
Sterling Application PlatformSterling Selling and Fulfillment Foundation versions
V1 and V2, and Q2 being valid for Sterling Application PlatformSterling Selling
and Fulfillment Foundation versions V2 and V3, and you call the getRuleDetails
API and pass V2 as the Sterling Application PlatformSterling Selling and
Fulfillment Foundation version, the system randomly returns one of the rule
values.

Creating a Qualified Tag Type


About this task

To create a Qualified Tag type:

Procedure
1. From the tree in the application rules side panel, choose Qualified Tag
Information > Qualified Tag Type. The Qualified Tag Type window displays in
the work area.

2. Choose . The Qualified Tag Type Details window displays.


3. Enter information in the applicable fields. Refer to the following table for field
value descriptions.

4. Choose .

© Copyright IBM Corp. 1999, 2011 349


Figure 31. Qualified Tag Type Details Window

Table 110. Qualified Tag Type Details Pop-Up Window


Field Description
Qualified Tag Type Enter name for the new Qualified Tag Type to be created.
This is a mandatory field.
Qualified Tag Type Description Enter a brief description of the Qualified Tag Type.
Qualified Tag Validator Class Enter the Qualified Tag class name that validates the
whether or not a Qualified Tag Id is valid for a particular
application code and application version.
Note: If left blank, default implementation of the
Qualified Tag Validator class will be used to validate the
Qualified Tag.

Modifying a Qualified Tag Type


About this task

Once a Qualified Tag Type has been created, it can be modified.

To modify an Qualified Tag Type:

Procedure
1. From the tree in the application rules side panel, choose Qualified Tag
Information > Qualified Tag Type.
2. The Qualified Tag Type window displays with the list of Qualified Tag Types.

3. Select the Qualified Tag Type to be modified. Choose .


4. Enter information in the applicable fields. Refer Table 110 for field value
descriptions.

5. Choose .

Deleting a Qualified Tag Type


About this task

To delete an Qualified Tag Type:

Procedure
1. From the tree in the application rules side panel, choose Qualified Tag
Information > Qualified Tag Type.
2. The Qualified Tag Type window displays with the list of Qualified Tag Types.
3. Select the Qualified Tag Type to be deleted. Choose .

350 Sterling Selling and Fulfillment Foundation: Application Platform Configuration Guide
Defining Qualified Tags
You can specify a list of Qualified Tags for rule and common code for a particular
Sterling Application PlatformSterling Selling and Fulfillment Foundation. You can
associate one or more Qualified Tags with a particular Qualified Tag Type.

Creating a Qualified Tag


About this task

To create a Qualified Tag:

Procedure
1. From the tree in the application rules side panel, choose Qualified Tag
Information > Qualified Tag. The Qualified Tag window displays in the work
area.

2. Choose . The Qualified Tag Details window displays.


3. Enter information in the applicable fields. Refer to the following table for field
value descriptions.
4. Choose .

Table 111. Qualified Tag Details Pop-Up Window


Field Description
Qualified Tag ID Enter the Qualified Tag ID. This is a mandatory field.
Qualified Tag Description Enter a description about the Qualified Tag.
Qualified Tag Type Select the Qualified Tag Type that you want to associate
with the Qualified Tag Id. This is a mandatory field.

Modifying a Qualified Tag


About this task

Once a Qualified Tag has been created, it can be modified.

To modify a Qualified Tag:

Procedure
1. From the tree in the application rules side panel, choose Qualified Tag
Information > Qualified Tag.
2. The Qualified Tag window displays with the list of Qualified Tags.

Chapter 19. Configuring Qualified Tag Information 351


3. Select the Qualified Tag to be modified. Choose .
4. Enter information in the applicable fields. Refer Table 111 on page 351 for field
value descriptions.

5. Choose .

Deleting a Qualified Tag


About this task

To delete a Qualified Tag:

Procedure
1. From the tree in the application rules side panel, choose Qualified Tag
Information > Qualified Tag.
2. The Qualified Tag window displays with the list of Qualified Tags.
3. Select the Qualified Tag to be deleted. Choose .

Configuring Qualified Tag Version Compatibility


About this task
To configure Qualified Tag version compatibility:

Procedure
1. From the tree in the application rules side panel, choose Qualified Tag
Information > Qualified Tag Version Compatibility. The Qualified Tag Version
Compatibility window displays in the work area.

2. Choose . The Qualified Tag Version Compatibility Details window displays.


3. Enter information in the applicable fields. Refer to the following table for field
value descriptions.
4. Choose .

352 Sterling Selling and Fulfillment Foundation: Application Platform Configuration Guide
Table 112. Qualified Tag Version Compatibility Details Pop-Up Window
Field Description
Application Code Select the Sterling Application PlatformSterling Selling
and Fulfillment Foundation code. This is a mandatory
field.
Qualified Tag ID Select the Qualified Tag ID. This is a mandatory field.
Minimum Version Supported Select the minimum Sterling Application PlatformSterling
Selling and Fulfillment Foundation version which
supports the Qualified Tag identifier.
Note: This is a mandatory field, if you have not
specified the Maximum Version Supported.
Maximum Version Supported Select the maximum Sterling Application
PlatformSterling Selling and Fulfillment Foundation
version which supports the Qualified Tag identifier.
Note: This is a mandatory field, if you have not
specified the Minimum Version Supported.
Support Level Enter the level of support for the Sterling Application
PlatformSterling Selling and Fulfillment Foundation
version which is below the supported minimum version.

Modifying Qualified Tag Version Compatibility


About this task

Once the Qualified Tag version compatibility has been configured, it can be
modified.

To modify Qualified Tag version compatibility:

Procedure
1. From the tree in the application rules side panel, choose Qualified Tag
Information > Qualified Tag Version Compatibility.
2. The Qualified Tag Version Compatibility window displays with the Qualified
Tag Version Compatibility list containing Application Code, Qualified Tag Id,
Minimum Version Supported, Maximum Version Supported, and Support Level
fields.
3. Select the Qualified Tag Version Compatibility list item to be modified. Choose
.
4. Enter information in the applicable fields. Refer Table 112 for field value
descriptions.

5. Choose .

Deleting Qualified Tag Version Compatibility


About this task

To delete a Qualified Tag version compatibility:

Procedure
1. From the tree in the application rules side panel, choose Qualified Tag
Information > Qualified Tag Version Compatibility.

Chapter 19. Configuring Qualified Tag Information 353


2. The Qualified Tag Version Compatibility window displays with the Qualified
Tag Version Compatibility list containing Application Code, Qualified Tag Id,
Minimum Version Supported, Maximum Version Supported, and Support Level
fields.
3. Select the Qualified Tag Version Compatibility list item to be deleted. Choose
.

354 Sterling Selling and Fulfillment Foundation: Application Platform Configuration Guide
Chapter 20. Configuring Attribute Postfix Rules
Defining common codes for attribute postfixes enables you to set up postfixes to
associate with attributes. Defining postfixes ensures that each customer sees
attribute data in a familiar format. For example, you can define "dollars" as the
postfix for the price attribute.

Creating an Attribute Postfix Definition


About this task

To create an attribute postfix definition:

Procedure
1. From the tree in the application rules side panel, choose Attribute Postfix. The
Attribute Postfix window displays in the work area.

2. Choose . The Attribute Postfix Details pop-up window displays.

3. In Attribute Postfix, enter an attribute postfix definition.


4. In Short Description, enter a brief description of the attribute postfix.
5. In Long Description, enter a more detailed description of the attribute postfix.

6. Choose .

Modifying an Attribute Postfix Definition


About this task

To modify an attribute postfix definition:

Procedure
1. From the tree in the application rules side panel, choose Attribute Postfix. The
Attribute Postfix window displays in the work area.

2. Select the applicable attribute postfix definition and choose . The Attribute
Postfix Details pop-up window displays.
3. In Short Description, enter a brief description of the attribute postfix definition.
4. In Long Description, enter a more detailed description of the attribute postfix
definition.

© Copyright IBM Corp. 1999, 2011 355


5. Choose .

Deleting an Attribute Postfix Definition


About this task

To delete an attribute postfix definition:

Procedure
1. From the tree in the application rules side panel, choose Attribute Postfix. The
Attribute Postfix window displays in the work area.

2. Select the applicable attribute postfix definition and choose .

356 Sterling Selling and Fulfillment Foundation: Application Platform Configuration Guide
Chapter 21. Configuring Analytics
You can use Analytics to associate pre-existing region schemas with Data
Warehouse Analytics. This association enables reporting on the best region
matching mechanism for features such as sourcing and resource pools. In analytics,
the region schema determines the level of granularity that is used in Data
Warehouse reports. For more information about configuring region schemas, see
the Chapter 13, “Configuring Region Definitions,” on page 311.

Note: When associating a region schema with analytics, do not specify a schema
that includes 9-digit zip codes. Otherwise, system performance is effected.

Defining Analytics Region Usage


About this task

Use the Analytics branch to define a region schema for analytics.

To define analytics region usage:

Procedure
1. From the tree in the application rules side panel, choose Analytics > Region
Usage For Analytics. The Region Usage For Analytics window displays.

2. From Schema for Analytics, select the region schema you want to use for Data
Warehouse Reports.

3. Choose .

© Copyright IBM Corp. 1999, 2011 357


358 Sterling Selling and Fulfillment Foundation: Application Platform Configuration Guide
Chapter 22. Time-Triggered Transaction Reference
Time-Triggered Transaction Reference
Sterling Selling and Fulfillment FoundationSterling Application Platform provides
a collection of time-triggered transactions, which are utilities that perform a variety
of individual functions, automatically and at specific time intervals.

Time-triggered transactions perform repetitive actions on a scheduled basis,


typically performing database updates, raising events, or calling APIs. One type of
transaction, monitors, are designed to watch for processes or circumstances that are
out of bounds and then raise alerts. Often, but not always, they retrieve tasks from
the task queue or work from the pipeline.

Some transactions enable you to collect statistical data regarding the application's
health. This data is collected periodically, using the value specified for the
yantra.statistics.persist.interval attribute in the yfs.properties file. By
default, statistics collection set to on. To override this property, add an entry in the
<INSTALL_DIR>/properties/customer_overrides.properties file. For additional
information about overriding properties using the customer_overrides.properties
file, see the Sterling Selling and Fulfillment Foundation: Properties GuidePlatform
Property File Management for File System Users Guide.

For more information about statistics persistence, see the Sterling Selling and
Fulfillment Foundation: Performance Management Guide. For more information about
the specific statistics parameters used, see the applicable time-triggered
transactions.

The time-triggered transactions described in this chapter are unique transactions,


that may or may not be document type specific. For document specific
transactions, the nomenclature helps define which unique transaction it is based
on: a transaction ID is in the format Unique_Transaction_ID.Document_Type_Code.
For example, the transaction ID for Purge Return is PURGE.0003, indicating that it is
based on the unique transaction PURGE, for document type 0003, which is Return
Order. Therefore, in order to be able to configure Purge Return, you should look
for the PURGE transaction ID in this chapter, which is Order Purge.

Sterling Selling and Fulfillment FoundationSterling Application Platform provides


the following types of time-triggered transactions:
v Business Process Time-Triggered Transactions - responsible for processing
v Time-Triggered Purge Transactions - clear out data that may be discarded after
having been processed
v Task Queue Syncher Time-Triggered Transactions - update the task queue
repository with the latest list of open tasks to be performed by each transaction,
based on the latest pipeline configuration
v Monitors - watch and send alerts for processing delays and exceptions

Sterling Selling and Fulfillment FoundationSterling Application Platform tracks the


following statistics for each time-triggered transaction:
v ExecuteMessageCreated - The number of jobs added to the JMS queue in a given
time interval.

© Copyright IBM Corp. 1999, 2011 359


v ExecuteMessageSuccess - The number of jobs that were run successfully in a
given time interval.
v ExecuteMessageError - The number of jobs that failed to run in a given time
interval.
v GetJobsProcessed - The number of GetJob messages that were processed in a
given time interval.

Note: Some of the statistics collected and tracked in Release 9.1 for
time-triggered transactions, monitors, and integration and application servers
may change with the next release of Sterling Selling and Fulfillment
FoundationSterling Application Platform.

Running Time-Triggered Transactions


All time-triggered transactions are threadable. This means that you can run
multiple instances of a transaction within a single process. For more information
about running time-triggered transactions, see the Sterling Selling and Fulfillment
Foundation: Installation Guide. For more information about fine-tuning system
performance while running them concurrently, see the Sterling Selling and
Fulfillment Foundation: Performance Management Guide.

Steps to Complete Before Scheduling Time-Triggered


Transactions
About this task

Before running and scheduling a time-triggered transaction, ensure that you have
completed the following:

Procedure
1. Configure a JMS Connection Factory to correlate with the QCF name
configured for the time-triggered transaction. The Sterling Selling and
Fulfillment FoundationSterling Application Platform factory defaults include
the AGENT_QCF as the JMS Connection Factory. For more information about
configuring JMS, see the documentation for your specific application server.
2. Configure JMS Server Destinations to correlate with the group or individual
name of the time-triggered transaction. The Sterling Selling and Fulfillment
FoundationSterling Application Platform factory defaults include the
DefaultAgentQueue as the server destination.
Do not put a dot (.) in the name of a JMS Server Destination, for
example,'A.0001'. If you do, Sterling Selling and Fulfillment FoundationSterling
Application Platform is unable to communicate with it.
3. Using the Applications Manager, configure each time-triggered transaction
required for your business process as described in the section entitled "Defining
Transactions" in the Sterling Selling and Fulfillment Foundation: Application
Platform Configuration Guide. Each set of time-triggered transaction criteria
parameters must ensure the appropriate association of a JMS Agent Server.

360 Sterling Selling and Fulfillment Foundation: Application Platform Configuration Guide
Configuring Communication Between an Agent and a JMS Server
About this task

Setting up communication between an agent (time-triggered transaction) and a


remote JMS server requires that you do some prerequisite setup on your JMS
system, then do some configuration within the application, which consists of the
following procedures:
v If an initial context factory code for your JMS system is not provided with the
application, you must create one. See “Create an Initial Context Factory Code”
for the list of codes that are provided.
v Defining the transaction details – the time-triggered transaction, or agent, must
be edited to include connection information for your JMS system and the initial
context factory you create. See “Define the Transaction Information” on page
362.

For more information about time-triggered transactions and how they fit into the
larger picture of application business process modeling, see the Configuring Process
Models chapter. Also see the Configuring Alert Queues chapter for additional
information about queues and agents.

Prerequisites
About this task

Before starting, complete these tasks for your JMS Server. See your JMS Server
documentation for more information about performing these tasks.

Procedure
1. Configure the JMS Queue Connection Factory (QCF) and queues on your JMS
server.
2. Configure the JNDI representation of the queues on your JMS server.
Ensure that you have the following information available from these tasks:
v JNDI name for each queue
v JNDI QCF lookup
v JMS location - the provider URL for the JMS server

Results

Once you have completed the preceding tasks, complete the next two procedures
in the order shown. These are both done in the application.

Create an Initial Context Factory Code


About this task

Using an Initial Context Factory (ICF) class enables remote Java clients to connect
to your application. This class is provided by the application vendor. The
application uses ICF codes to identify these when setting up agents. Initial context
factory codes are predefined in the application for the following JMS vendors:
v IBM WebSphere MQ (for MQSeries accessed through a IBM WebSphere Internet
Inter-ORB Protocol URL)
v File (for MQSeries accessed through a file URL, as with Oracle WebLogic)
v Oracle WebLogic (for WebLogic JMS)

Chapter 22. Time-Triggered Transaction Reference 361


v JBoss (for JBoss JMS)

If you are using a JMS server that is not in the preceding list (for example,
ActiveMQ), you must create an initial context factory code for it in the application:

Procedure
1. Open the Applications Manager. From the tree in the application rules side
panel, choose System Administration > Initial Context Factory Codes. The
Initial Context Factory Codes window displays in the work area.
2. Select the + icon to create a new initial context factory code. The Initial Context
Factory window is displayed.
3. In the Initial Context Factory field, enter the name of the class provided by
your JMS vendor. For example, for ActiveMQ, the class name is
org.apache.activemq.jndi.ActiveMQInitialContextFactory.
4. In the Short Description field, enter a descriptive name, up to 40 characters.
Make note of this name, because you will use it in the next procedure (see
“Define the Transaction Information”). For ActiveMQ, enter ActiveMQ.
5. In the Long Description field, enter a more detailed description for the initial
context factory, up to 100 characters.
6. Save the new initial context factory code and close the window.

Results

For more information about ICFs, see Creating an Initial Context Factory Code.

Define the Transaction Information


About this task

For the JMS server to communicate with the application, there must be a
time-triggered transaction configured with the JMS server and ICF information.

Procedure
1. Open the Applications Manager. From the tree in the application rules side
panel, double-click Process Modeling. The Process Modeling window displays
in the work area.
2. Select the desired tab, then Base Document Type, then double-click Process
Type.
3. Double-click the transaction that corresponds to the agent to be run.
4. Select the Time Triggered tab.
5. Create or select an existing Agent Criteria Definition to edit.
6. The Agent Criteria Details screen is displayed. Select the Runtime Properties
tab.
7. Select an existing Agent Server from the list or create your own
(recommended).
8. Select an existing Alert Queue from the list or create your own.
9. In the JMS Queue Name field, enter the JNDI name for the queue that you
created. See “Prerequisites” on page 361.
10. Enter the desired number of threads the agent should run (recommended not
to exceed 5 threads - if more than 5 are needed, start another agent in its own
JVM).

362 Sterling Selling and Fulfillment Foundation: Application Platform Configuration Guide
11. Select the Initial Context Factory code you created. See “Create an Initial
Context Factory Code” on page 361.
12. In the QCF Lookup field, enter the JNDI QCF lookup for the queue that you
created (this is the Queue Connection Factory created for the applicable JMS
Server). See “Prerequisites” on page 361.
13. Enter the Provider URL. This is the location where the JMS system resides,
and is JMS vendor specific.
14. Select whether the agent should trigger itself (recommended) and at what
interval (in minutes) or use an external trigger (triggeragent.sh in the
<install_dir>/install/bin directory).
15. See Setting up the JMS Security Properties for information about setting the
JMS Security option.
16. Leave the Criteria Parameters tab values at the default values.
17. Save the Agent Criteria Details and close the window.
18. Launch the agent in its own JVM by executing the startagentserver.sh/cmd
script in the <install_dir>/install/bin directory.

Results
For additional information about defining transactions and about this procedure,
see the sections Defining Transactions and Specifying a Transaction as Time-Triggered in
the Sterling Selling and Fulfillment Foundation: Application Platform Configuration
Guide.

Business Process Time-Triggered Transactions


Some of the statistics collected and tracked in Release 9.1 for time-triggered
transactions, monitors, and integration and application servers may change with
the next release of Sterling Selling and Fulfillment FoundationApplication.

All Business Process Time-Triggered Transactions have a CollectPendingJobs


criteria parameter. If this parameter is set to N, the agent does not collect
information about the pending jobs pertaining to this monitor. This pending job
information is used for monitoring the monitor in the System Management
ConsolePlatform System Management and Administration Guide.

By default, CollectPendingJobs is set to Y. It can be helpful to set it to N if one


particular time-triggered transaction is performing a significant amount of
getPendingJobs queries, and the overhead cost is too high.

Asynchronous Request Processor


This transaction completes any API request or service request in offline mode. It
picks up the API messages or service messages from the YFS_ASYNC_REQ table
and invokes the corresponding API or service. The messages can be inserted into
the YFS_ASYNC_REQ table using the createAsyncRequest API. Some of the
business transactions in the Sterling Warehouse Management System also insert the
messages into the YFS_ASYNC_REQ table.

Chapter 22. Time-Triggered Transaction Reference 363


Attributes

Following are the attributes for this time-triggered transaction:


Table 113. Asynchronous Request Processor Attributes
Attribute Value
Base Transaction ID ASYNC_REQ_PROCESSOR
Base Process Type General
Abstract Transaction No

Criteria Parameters

Following are the criteria parameters for this transaction:


Table 114. Asynchronous Request Processor Parameters
Parameter Description
Action Required. Triggers the transaction. If left blank, it defaults to
Get, the only valid value.
Number of Records To Optional. Number of records to retrieve and process at one
Buffer time. If left blank or specified as 0 (zero), it defaults to 5000.
Lead Days Number of days before the present date the agent will purge
the records. If left blank or specified as 0 (zero), it defaults to
30.
Maximum Error Count Maximum number of times the record is processed if an
exception is thrown. Once the number of unsuccessful
attempts equals this number, that record is not processed
further by the agent. If left blank or specified as 0 (zero), it
defaults to 20.
Reprocess Interval In Time in minutes after which the transaction will be
Minutes reprocessed - after it has been processed and has thrown an
exception.
ColonyID Required in a multischema deployment where the
YFS_ASYNC_REQ table may exist in multiple schemas. Runs
the agent for the colony.

Statistics Tracked

None

Pending Job Count

None

364 Sterling Selling and Fulfillment Foundation: Application Platform Configuration Guide
Events Raised

The following events are raised by this time-triggered transaction:


Table 115. Events Raised by the Asynchronous Request Processor
Template
Transaction/Event Key Data Data Published* Support?
HAS_EXCEPTIONS None YCP_ASYNC_REQ_ Yes
PROCESSOR.HAS_
EXCEPTIONS.html
*These files are located in the following directory:

<INSTALL_DIR>/xapidocs/api_javadocs/XSD/HTML

Case Insensitive Data Loader


The Case Insensitive Data Loader agent migrates data from columns marked
CaseInsensitiveSearch to shadow columns. The agent uses the transaction criteria
to identify the records that need to be updated and then converts the original
column values to lowercase values in the shadow columns. For more information
about enabling case insensitive searches, refer to the Sterling Selling and Fulfillment
Foundation: Extending the Database.

The Case Insensitive Data Loader agent is required for updating the existing data.
Once the shadow columns have been created, the Case Insensitive Data Loader
agent only needs to be run once for each table or table type. The shadow columns
are then populated in real-time by the application.

Attributes

The following are the attributes for this time-triggered transaction:


Table 116. Case Insensitive Data Loader Attributes
Attribute Value
Base Transaction ID DATA_LOADER
Base Document Type General
Base Process Type General
Abstract Transaction No
APIs Called None
User Exits Called None

Criteria Parameters

The following are the criteria parameters for this transaction:


Table 117. Case Insensitive Data Loader Criteria Parameters
Parameter Description
Action Required. Triggers the transaction. If left blank, it defaults to
Get, the only valid value.

Chapter 22. Time-Triggered Transaction Reference 365


Table 117. Case Insensitive Data Loader Criteria Parameters (continued)
Parameter Description
Number of Records To Optional. Number of records to retrieve and process at one
Buffer time.
v If left blank or the number specified is less than 10000, it
defaults to 5000.
v If the number specified is greater than 10000, then that
value is used.
CollectPendingJobs If this parameter is set to "N", the agent does not collect
information on the pending jobs for this monitor. This pending
job information is used for monitoring the monitor in the
System Management Console.
TableType Required in a multischema deployment when a table may
exist in multiple schemas.

Valid Values: CONFIGURATION, TRANSACTION, MASTER.

If set to CONFIGURATION, the agent runs for the records


associated with tables that have TableType as
CONFIGURATION.

If set to TRANSACTION, the agent runs for the records


associated with tables that have TableType as TRANSACTION.
Table Name Required. The table name for the records to be migrated to
shadow columns.
ColonyID Required in a multischema deployment where a table may
exist in multiple schemas. Runs the agent for the colony.

Statistics Tracked

None.

Pending Job Count

None.

Events Raised

None.

Configuration Options for Accessing Catalog Index Files


You can configure catalog index builds in one of the following two ways,
depending on your business requirements:
v Build the index on a shared, central disk that is accessible from all servers.
v Advantages:
– Centralized control of shared index
– No file transfer issues because the index is not copied across multiple servers
v Limitation: :
– Shared disk could become a single point of failure (if no redundancy is
involved)
– Volume of reads and writes from shared disk might slow performance,
depending on the setup

366 Sterling Selling and Fulfillment Foundation: Application Platform Configuration Guide
v Build and push a copy of the index to multiple servers via file transfer.
Automate this file transfer process to occur on completion of an index build, but
do not automatically activate the index. When all servers have acknowledged
the completion of the file transfer, call the manageSearchIndexTrigger API to
activate the index.
v Advantage:
– No central point of failure
v Limitation: :
– Possible overhead to building and pushing index files across servers

If you choose this method of building the index in one location and reading it
from another, refer to the Sterling Selling and Fulfillment Foundation: Properties Guide
for information about enabling different properties for individual processes. For
more information about building and searching catalog indexes, see the Sterling
Selling and Fulfillment Foundation: Catalog Management Concepts Guide.

Change Data Export Agent


The Change Data Export Agent is used to export the database changes into XML
files, which are then zipped and placed in a specified folder. The agent runs for a
specific enterprise, however, if an enterprise code is not provided, the agent runs
on all the enterprises of the colony. The zipped XML file is placed in a specified
folder from where it is picked up by the Change Data Import agent for publishing
the changes on the target environment.

Attributes
Table 118. Change Data Export Agent Attributes
Attribute Value
Base Transaction ID CHANGE_DATA_EXPORT
Base Process Type General

Criteria Parameters
Table 119. Change Data Export Agent Criteria Parameters
Parameter Name Description
Action Required. This parameter triggers the
transaction. The default value is "Get".
Number of Records To Buffer The number of records to retrieve and
process by the agent is set in this attribute.
The default value is "50".
Enterprise Code The enterprise for which the agent is run. If
it is not specified, the agent is run on all the
enterprises of the colony.
Change Project ID Not applicable.
Service To Invoke The Service that is invoked by the agent.
The default value is "ChangeDataPublisher",
which writes changes to an XML file.
Export Directory The folder path where the XML files are
written and zipped.

Chapter 22. Time-Triggered Transaction Reference 367


Table 119. Change Data Export Agent Criteria Parameters (continued)
Parameter Name Description
Zip Retry Interval The time interval for which the agent should
wait before zipping the XML files of a
default project if all the files could not be
exported. Set the value to "0" if files need
not be zipped or if asynchronous service is
used.
Locking Entities Per File Number of unique combination of entity
keys that are used for locking an entity.

Events Raised
Table 120. Events Raised by Change Data Export Agent
Key Template
Transaction/Event Data Data Published Support
PUBLISHED None YSC_CHANGE_DATA_EXPORT.PUBLISHED.xml* No

*These files are located in the following directory <INSTALL_DIR>\SC-Platform\


documentation\devXML

Statistics Tracked

None

Change Data Import Agent


The Change Data Import Agent is used to import the files exported by the Change
Data Export Agent. The agent picks up the zipped XML files placed in a specified
folder in the agent criteria, extracts the files, and applies the changes to the
database. An EndOfZip file is created when the agent extracts the XML files but is
present in the folder only when an error is encountered during import. The
EndOfZip file contains the names of the XML files that were included in the
original zip file, as well as the original zip file name. The name of the EndOfZip
file is always in the format, EndOfZip <name of last XML file extracted>. For
example, if the zip file contains 000001_12345678.xml and 000002_12345789.xml, the
EndOfZip will be EndOfZip_000002_12345789.xml since it is extracted last.

If the zip file has multiple folders for different table types, such as MASTER and
CONFIGURATION, and the MASTER folder is processed last, the EndOfZip file
will be present in the MASTER folder, if an error is encountered during processing.

Note: If an entity is directly modified in the target environment, the changes are
overridden by the source database updates for the same entity, when the change
data import agent is run.

Attention: During import, the agent may take up to 30 minutes to finish


processing the XML files.

Attributes

368 Sterling Selling and Fulfillment Foundation: Application Platform Configuration Guide
Table 121. Change Data Import Agent Attributes
Attribute Value
Base Transaction ID CHANGE_DATA_IMPORT
Base Process Type General

Criteria Parameters
Table 122. Change Data Import Agent Parameters
Parameter Name Description
Action Required. This parameter triggers the
transaction. The default value is "Get".
Number of Records To Buffer The number of records to retrieve and
process by the agent is set in this attribute.
The default value is "5000".
Import Directory The import folder where the zipped XML
files are stored for the agent to process.

Events Raised
Table 123. Events Raised by Change Data Import Agent
Key Template
Transaction/Event Data Data Published Support
ON_SUCCESS None YSC_CHANGE_DATA_IMPORT.ON_SUCCESS.xml* No
ON_FAILURE None YSC_CHANGE_DATA_IMPORT.ON_FAILURE.xml* No

*These files are located in the following directory <INSTALL_DIR>\SC-Platform\


documentation\devXML

Statistics Tracked

None

Change Load Status


This transaction is equivalent to the changeLoadStatus() API. For detailed
information about this transaction, see the Sterling Selling and Fulfillment Foundation:
Javadocs.

To be configured as part of your load processing pipeline, this transaction can be


used whenever an automatic change in the status of a load is required. This
automatic change could represent exporting load information to load planning
software or transmission to the load's carrier.

This transaction should be configured to work from the task queue.

Chapter 22. Time-Triggered Transaction Reference 369


Attributes

The following are the attributes for this time-triggered transaction:


Table 124. Change Load Status Attributes
Attribute Value
Base Transaction ID CHANGE_LOAD_STATUS
Base Document Type Load
Base Process Type Load Execution
Abstract Transaction Yes
APIs Called changeLoadStatus()

Criteria Parameters

The following are the criteria parameters for this transaction:


Table 125. Change Load Status Parameters
Parameter Description
Action Required. Triggers the transaction. If left blank, it defaults to
Get, the only valid value.
Number of Records To Optional. Number of records to retrieve and process at one
Buffer time. If left blank or specified as 0 (zero), it defaults to 5000.
ColonyID Required in a multischema deployment where a table may
exist in multiple schemas. Runs the agent for the colony.

Statistics Tracked
The following statistics are tracked for this transaction:
Table 126. Change Load Status Statistics
Statistic Name Description
NumLoadsChanged Number of loads whose status was changed.

Pending Job Count

For this transaction the pending job count is the number of records available to be
processed by the transaction with the AVAILABLE_DATE value less than or equal
to (<=) the CurrentDate value in the YFS_Task_Q table.

Events Raised

This transaction raises events as specified under the changeLoadStatus() API in the
Sterling Selling and Fulfillment Foundation: Javadocs.

Change Shipment Status


This transaction is equivalent to the changeShipmentStatus() API. For detailed
information about this transaction, see the Sterling Selling and Fulfillment Foundation:
Javadocs.

370 Sterling Selling and Fulfillment Foundation: Application Platform Configuration Guide
To be configured as part of your shipment processing pipeline, this transaction can
be used whenever an automatic change in the status of a shipment is required. For
example, this automatic change could represent exporting shipment information to
a warehouse management system or to transmit an Advance Shipping Notice to
the buyer.

This transaction should be configured to work from the task queue.

Attributes

The following are the attributes for this time-triggered transaction:


Table 127. Change Shipment Status Attributes
Attribute Value
Base Transaction ID CHANGE_SHIPMENT_STATUS
Base Document Type Order
Base Process Type Order Delivery
Abstract Transaction Yes
APIs Called None

Criteria Parameters

The following are the criteria parameters for this transaction:


Table 128. Change Shipment Status Parameters
Parameter Description
Action Required. Triggers the transaction. If left blank, it defaults to
Get, the only valid value.
Number of Records To Optional. Number of records to retrieve and process at one
Buffer time. If left blank or specified as 0 (zero), it defaults to 5000.
ColonyID Required in a multischema deployment where a table may
exist in multiple schemas. Runs the agent for the colony.

Statistics Tracked

The following statistics are tracked for this transaction:


Table 129. Create Chained Order Statistics
Statistic Name Description
NumShipmentsChanged Number of shipments whose status was changed.

Pending Job Count

For this transaction the pending job count is the number of records available to be
processed by the transaction with the AVAILABLE_DATE value less than or equal
to (<=) the current date value in the YFS_Task_Q table.

Events Raised

This transaction raises events as specified under the changeShipmentStatus() API


in the Sterling Selling and Fulfillment Foundation: Javadocs.

Chapter 22. Time-Triggered Transaction Reference 371


Close Delivery Plan
To boost system performance, this transaction serves as a temporary purge until
the Delivery Plan Purge deletes delivery plan-related data (see “Delivery Plan
Purge” on page 444).

This transaction picks all delivery plans that do not have any of their loads or
shipments still open and marks the deliveryplan_closed_flag='Y'. This flag
indicates no further operations are possible on the plan.

This transaction corresponds to the base transaction close delivery plan


(CLOSE_DELIVERY_PLAN) in the load pipeline.

Any enterprise using the Console must schedule purge jobs.

Attributes
The following are the attributes for this time-triggered transaction:
Table 130. Close Delivery Plan Attributes
Attribute Value
Base Transaction ID CLOSE_DELIVERY_PLAN
Base Document Type Load
Base Process Type Load Execution
Abstract Transaction No
APIs Called None

Criteria Parameters

The following are the criteria parameters for this transaction:


Table 131. Close Delivery Plan Criteria Parameters
Parameter Description
Action Required. Triggers the transaction. If left blank, it defaults to
Get, the only valid value.
Number of Records To Optional. Number of records to retrieve and process at one
Buffer time. If left blank or specified as 0 (zero), it defaults to 5000.
ColonyID Required in a multischema deployment where a table may
exist in multiple schemas. Runs the agent for the colony.

Statistics Tracked

The following statistics are tracked for this transaction:


Table 132. Close Delivery Plan Statistics
Statistic Name Description
NumDeliveryPlansClosed Number of delivery plans closed.

372 Sterling Selling and Fulfillment Foundation: Application Platform Configuration Guide
Pending Job Count

For this transaction the pending job count is the number of records available to be
processed by the transaction with the AVAILABLE_DATE value less than or equal
to (<=) the current date value in the YFS_Task_Q table.

Events Raised

The following events are raised by this time-triggered transaction:


Table 133. Events Raised by Close Delivery Plan Transaction
Template
Transaction/Event Key Data Data Published Support?
ON_SUCCESS delivery_plan_ YDM_CLOSE_DELIVERY Yes
dbd.txt _PLAN.ON_
SUCCESS.xml

However, note that the template name would read


<TransactionId>.ON_SUCCESS.xml.

Close Load
To boost system performance, this transaction serves as a temporary purge until
the Load Purge deletes load-related data (see “Load Purge” on page 458).

This transaction corresponds to the base transaction Close Load (CLOSE_LOAD) in


the load pipeline.

If you use the Load processing pipeline, you must schedule this transaction. Only
closed loads are picked up by the purge transaction. Therefore, it is required that
this transaction be made part of the pipeline and scheduled to run at the end of
the day.

This transaction should be made part of the pipeline. In addition, it should be


configured to work from the task queue.

Attributes

The following are the attributes for this time-triggered transaction:


Table 134. Close Load Attributes
Attribute Value
Base Transaction ID CLOSE_LOAD
Base Document Type Load
Base Process Type Load Execution
Abstract Transaction No
APIs Called None

Chapter 22. Time-Triggered Transaction Reference 373


Criteria Parameters

The following are the criteria parameters for this transaction:


Table 135. Close Load Parameters
Parameter Description
Action Required. Triggers the transaction. If left blank, it defaults to
Get, the only valid value.
Number of Records To Optional. Number of records to retrieve and process at one
Buffer time. If left blank or specified as 0 (zero), it defaults to 5000.
Next Task Queue Interval Optional. Specifies in hours how long a failed task should be
suspended before it is considered for reprocessing. Defaults to
5 hours.
ColonyID Required in a multischema deployment where a table may
exist in multiple schemas. Runs the agent for the colony.

Statistics Tracked

The following statistics are tracked for this transaction:


Table 136. Close Load Statistics
Statistic Name Description
NumLoadsClosed Number of loads closed.

Pending Job Count

For this transaction the pending job count is the number of open delivery plans,
which are not associated to any open loads and open shipments.

Events Raised

The following events are raised by this time-triggered transaction:


Table 137. Events Raised by the Close Load Transaction
Template
Transaction/Event Data Published Support?
ON_SUCCESS YDM_CLOSE_LOAD_PLAN.ON_ Yes
SUCCESS.xml

However, note that the template name would read


<TransactionId>.ON_SUCCESS.xml.

Close Manifest
This time-triggered transaction sets the manifest's MANIFEST_CLOSED_FLAG flag
to ‘Y' and updates the manifest status to CLOSED. This time-triggered transaction
confirms all the shipments that are pending confirmation, and closes the manifest.

Note: If the Close Manifest Agent is triggered without any criteria, it closes all the
candidate manifests across all ShipNodes.

374 Sterling Selling and Fulfillment Foundation: Application Platform Configuration Guide
The yfs.closemanifest.online property in the yfs.properties_ysc_ext.in file is
used to set this time-triggered transaction to work in online or offline mode.
v Online mode: In the online mode, the close manifest transaction runs as usual,
confirming all shipments in the manifest and then closing the manifest.
v Offline mode: In the offline mode, the close manifest transaction triggers an
agent and changes the manifest status to ‘Closure Requested'. When the agent
runs, it confirms either each shipment of the manifest, or closes the manifest, in
an execution call.

The mode of operation (online or offline) is decided on the basis of the value
specified for the yfs.closemanifest.online property in the
yfs.properties_ycs_ext.in file. To override this property, add an entry for it in
the <INSTALL_DIR>/properties/customer_overrides.properties file. For additional
information about overriding properties using the customer_overrides.properties
file, see the Sterling Selling and Fulfillment Foundation: Properties Guide.

The default out-of-the-box shipped property causes the Close Manifest transaction
to run in online mode.

In instances where the Close Manifest transaction is run in offline mode, ensure
that all Agent Criteria defined for the transaction are configured properly.

Attributes

The following are the attributes for this time-triggered transaction:


Table 138. Close Manifest Attributes
Attribute Value
Base Transaction ID CLOSE_MANIFEST
Base Document Type General
Base Process Type Manifesting
Abstract Transaction No
APIs Called confirmShipment()

Criteria Parameters

The following are the criteria parameters for this transaction:


Table 139. Close Manifest Criteria Parameters
Parameter Description
Action Required. Triggers the transaction. If left blank, it defaults to
Get, the only valid value.
Number of Records To Optional. Number of records to retrieve and process at one
Buffer time. If left blank or specified as 0 (zero), it defaults to 5000.
AgentCriteriaGroup Optional. Used to classify nodes. This value can be accepted
by Sterling Warehouse Management System time-triggered
transactions that only perform their tasks on the nodes with a
matching node transactional velocity value.

Valid values are: LOW, HIGH, and any additional values


defined by the Hub from Application Platform > System
Administration > Agent Criteria Groups.

Chapter 22. Time-Triggered Transaction Reference 375


Table 139. Close Manifest Criteria Parameters (continued)
Parameter Description
ShipNode Optional. Ship node for which the Close Manifest needs to be
run. If not passed, then all ship nodes are monitored.
ColonyID Required in a multischema deployment where a table may
exist in multiple schemas. Runs the agent for the colony.

Statistics Tracked

The following are statistics are tracked for this transaction:


Table 140. Close Manifest Statistics
Statistic Name Description
NumShipmentsConfirmed Number of shipments confirmed.
NumManifestsClosed Number of manifests closed.
NumManifestsErrored Number of manifests errored.
NumShipmentsErrored Number of shipments errored.

Pending Job Count

For this transaction the pending job count is the sum of open manifests and
shipments belonging to manifests (with MANIFEST_STATUS='1200').

Events Raised

The following events are raised by this time-triggered transaction:


Table 141. Events Raised by the Close Manifest Transaction
Template
Transaction/Event Key Data Data Published Support?
ON_SUCCESS manifest_dbd.txt YDM_CLOSE_MANIFEST Yes
.ON_SUCCESS.xml

Close Order
This time-triggered transaction sets the order's ORDER_CLOSED flag to ‘Y' and
raises the ON_SUCCESS event. These actions are only performed when the entire
ORDER_QTY for all the order lines reaches the configured pickup status. If an
order has ORDER_CLOSED set to ‘Y', it is not picked up for monitoring.

The Close Order agent must be configured along with the Purge transaction in the
pipeline.

Many of this transaction's elements and attributes are template-driven. Refer to the
XML for element level details.

The Close Order agent must be run before running the Monitor agent in order to
avoid alerts getting raised for cancelled orders.

376 Sterling Selling and Fulfillment Foundation: Application Platform Configuration Guide
Attributes

The following are the attributes for this time-triggered transaction:


Table 142. Close Order Attributes
Attribute Value
Base Transaction ID CLOSE_ORDER
Base Document Type Order
Base Process Type Order Fulfillment
Abstract Transaction No
APIs Called None

Criteria Parameters

The following are the criteria parameters for this transaction:


Table 143. Close Order Criteria Parameters
Parameter Description
Action Required. Triggers the transaction. If left blank, it defaults to
Get, the only valid value.
Number of Records To Optional. Number of records to retrieve and process at one
Buffer time. If left blank or specified as 0 (zero), it defaults to 5000.
Next Task Queue Interval Optional. Specifies in hours how long a failed task should be
suspended before it is considered for reprocessing. Defaults to
5 hours.
ColonyID Required in a multischema deployment where a table may
exist in multiple schemas. Runs the agent for the colony.

Statistics Tracked

The following statistics are tracked for this transaction:


Table 144. Close Order Statistics
Statistic Name Description
NumOrdersProcessed Number of orders processed.
NumOrdersClosed Number of orders closed.

Pending Job Count

For this transaction the pending job count is the number of records available to be
processed by the transaction with the AVAILABLE_DATE value less than or equal
to (<=) the current date value in the YFS_Task_Q table, if tasks on hold are not
ready to be processed.

Chapter 22. Time-Triggered Transaction Reference 377


Events Raised

The following events are raised by this time-triggered transaction:


Table 145. Events Raised by the Close Order Transaction
Transaction/Event Data Published Template Support?
ON_SUCCESS YFS_CLOSE_ORDER.ON_ Yes
SUCCESS.xml

Close Receipts
This time-triggered transaction closes receipts using the receiving rule specified.

Attributes

The following are the attributes for this time-triggered transaction:


Table 146. Close Receipts Attributes
Attribute Value
Base Transaction ID RECEIPT_COMPLETE
Base Document Type Order
Base Process Type Receipt (Purchase Order Receipt, Return Receipt, Transfer
Order Receipt, Receipt)
Abstract Transaction No
APIs Called None
User Exits Called None

Criteria Parameters

The following are the criteria parameters for this transaction:


Table 147. Close Receipts Criteria Parameters
Parameter Description
Action Triggers the transaction. If left blank, it defaults to Get, the
only valid value.
Number of Records To Number of records to retrieve and process at one time. If left
Buffer blank or specified as 0 (zero), it defaults to 5000.
EnterpriseCode Enterprise for which the Close Receipts needs to be run. If not
passed, then all enterprises are monitored.
Node Mandatory. Node for which the Close Receipts needs to be
run.
AgentCriteriaGroup Used to classify nodes. This value can be accepted by Sterling
Warehouse Management System time-triggered transactions
that only perform their tasks on the nodes with a matching
node transactional velocity value.

Valid values are: LOW, HIGH, and any additional values


defined by the Hub from Application Platform > System
Administration > Agent Criteria Groups.
ColonyID Required in a multischema deployment where a table may
exist in multiple schemas. Runs the agent for the colony.

378 Sterling Selling and Fulfillment Foundation: Application Platform Configuration Guide
Statistics Tracked

The following statistics are tracked for this transaction:


Table 148. Close Receipts Statistics
Statistic Name Description
NumReceiptsClosed Number of receipts closed.

Pending Job Count

For this transaction the pending job count is the number of Receipts that can be
closed (with OPEN_RECEIPT_FLAG='Y').

Events Raised

The following events are raised by this time-triggered transaction:


Table 149. Events Raised by the Close Receipts Transaction
Template
Transaction/Event Key Data Data Published Support?
ON_SUCCESS receipt_dbd.txt YFS_RECEIPT_COMPLETE Yes
.ON_SUCCESS.xml

When multiple inbound shipments are received into the same location, and the
inventory received is not license plated, an error message, "There is no inventory
for put away at the SourceLocation" displays. The solution to this problem lies in
one of these steps:
v Manually create move requests for receipts that you already received. For more
information about creating move requests, refer to the Sterling Selling and
Fulfillment Foundation: Warehouse Management System User Guide.
v For receipts that are expected to be received, ensure that the inventory is license
plated and that you don't receive inbound shipments and inventory for put
away into the same location.

Close Shipment
To boost system performance, this transaction serves as a temporary purge until
the Shipment Purge deletes all shipment-related data (see “Shipment Purge” on
page 495).

This transaction picks all shipments eligible to be closed, based on the pipeline
configuration for pickup for transaction CLOSE_SHIPMENT, and marks the
shipment_closed_flag='Y'. This flag indicates no further operations are possible on
the shipment. There is no status change involved. This transaction can be
configured in the pipeline so that it picks up either Shipped or Delivered status.

This transaction corresponds to the base transaction close shipment


(CLOSE_SHIPMENT) in the shipment pipeline.

This transaction should be made part of the pipeline. In addition, it should be


configured to work from the task queue.

Chapter 22. Time-Triggered Transaction Reference 379


Attributes

The following are the attributes for this time-triggered transaction:


Table 150. Close Shipment Attributes
Attribute Value
Base Transaction ID CLOSE_SHIPMENT
Base Document Type Order
Base Process Type Order Delivery
Abstract Transaction No
APIs Called None

Criteria Parameters

The following are the criteria parameters for this transaction:


Table 151. Close Shipment Criteria Parameters
Parameter Description
Action Required. Triggers the transaction. If left blank, it defaults to
Get, the only valid value.
Number of Records To Optional. Number of records to retrieve and process at one
Buffer time. If left blank or specified as 0 (zero), it defaults to 5000.
Next Task Queue Interval Optional. Specifies in hours how long a failed task should be
suspended before it is considered for reprocessing. Defaults to
5 hours.
ColonyID Required in a multischema deployment where a table may
exist in multiple schemas. Runs the agent for the colony.

Statistics Tracked

The following are statistics are tracked for this transaction:


Table 152. Close Shipment Statistics
Statistic Name Description
NumShipmentsClosed Number of shipments closed.

Pending Job Count

For this transaction the pending job count is the number of records available to be
processed by the transaction with the AVAILABLE_DATE value less than or equal
to (<=) the current date value in the YFS_Task_Q table.

380 Sterling Selling and Fulfillment Foundation: Application Platform Configuration Guide
Events Raised

The following events are raised by this time-triggered transaction:


Table 153. Events Raised by the Close Shipment Transaction
Template
Transaction/Event Key Data Data Published Support?
ON_SUCCESS shipment_dbd.txt YDM_CLOSE_SHIPMENT. Yes
ON_SUCCESS.xml

Collect Shipment Statistics


Collect Shipment Statistics is a time-triggered transaction which can be invoked to
process the shipments, and generate information required for the Daily Shipment
Report.

Attributes

The following are the attributes for this time-triggered transaction:


Table 154. Collect Shipment Statistics Attributes
Attribute Value
Transaction Name Collect Shipment Statistics
Transaction ID COLLECT_STATISTICS
Base Document Type Order
Base Process Type Order Delivery
Abstract Transaction No
APIs Called None
User Exits Called None

Criteria Parameters

The following are the criteria parameters for this transaction:


Table 155. Collect Shipment Statistics Criteria Parameters
Parameter Description
Action Required. Triggers the transaction. If left blank, it defaults to
Get, the only valid value.
Number of Records To Optional. Number of records to retrieve and process at one
Buffer time. If left blank or specified as 0 (zero), it defaults to 5000.
Node Required. The warehouse management ship node for which
records are being processed.
AgentCriteriaGroup Optional. Used to classify nodes. This value can be accepted
by Sterling Warehouse Management System time-triggered
transactions that only perform their tasks on the nodes with a
matching node transactional velocity value.

Valid values are: LOW, HIGH, and any additional values


defined by the Hub from Application Platform > System
Administration > Agent Criteria Groups.

Chapter 22. Time-Triggered Transaction Reference 381


Table 155. Collect Shipment Statistics Criteria Parameters (continued)
Parameter Description
ColonyID Required in a multischema deployment where a table may
exist in multiple schemas. Runs the agent for the colony.

Statistics Tracked

The following statistics are tracked for this transaction:


Table 156. Statistics for Collect Shipment Statistics
Statistic Name Description
NumDaysStatisticsCollected Number of days for which shipment statistics have
been collected.

Pending Job Count

For this transaction the pending job count is the number of days for which
shipment statistics needs to be collected. The number of days is calculated as the
difference (in days) between the current date and the last date when shipment
statistics was collected.

Events Raised

The following events are raised by this time-triggered transaction:


Table 157. Events Raised by the Collect Shipment Statistics Transaction
Template
Transaction/Event Data Published Support?
ON_SUCCESS YDM_COLLECT_STATISTICS.ON_ No
SUCCESS.xml

Consolidate Additional Inventory


The Consolidate Additional Inventory time-triggered transaction consolidates
supply and demand from the YFS_INVENTORY_SUPPLY_ADDNL and
YFS_INVENTORY_DEMAND_ADDNL tables. Consolidation is performed by
summing up the quantities of additional supply and demand in the
YFS_INVENTORY_SUPPLY and YFS_INVENTORY_DEMAND tables.

If no matching supply or demand is found, a new supply or demand is created


with the sum quantity of the changes in the YFS_INVENTORY_SUPPLY_ADDNL
and YFS_INVENTORY_DEMAND_ADDNL tables. After the changes are applied,
the records in the YFS_INVENTORY_SUPPLY_ADDNL and
YFS_INVENTORY_DEMAND_ADDNL tables that were used in the consolidation
process, are deleted.

382 Sterling Selling and Fulfillment Foundation: Application Platform Configuration Guide
Attributes

The following are the attributes for this time-triggered transaction:


Table 158. Consolidate Additional Inventory Attributes
Attribute Value
Base Transaction ID CONSOLIDATE_ADDNL_INV
Base Document Type General
Base Process Type General
Abstract Transaction No
APIs Called None

Criteria Parameters

The following are the parameters for this transaction:


Table 159. Consolidate Additional Inventory Criteria Parameters
Parameter Description
Action Required. Triggers the transaction. If left blank, it defaults to
Get, the only valid value.
Number of Records To Optional. Number of inventory item records (whose
Buffer additional supplies and demands are consolidated_ to retrieve
and process at one time. If left blank or specified as 0 (zero),
it defaults to 5000.
ColonyID Required in a multischema deployment where the
YFS_INVENTORY_SUPPLY_ADDNL and
YFS_INVENTORY_DEMAND_ADDNL tables may exist in
multiple schemas. Runs the agent for the colony.

Statistics Tracked

The following statistics are tracked for this transaction:


Table 160. Consolidate Additional Inventory Statistics
Statistic Name Description
NumInventorySupplyAddnlsProcessed Number of additional inventory supply
records processed in the consolidation.
NumInventoryDemandAddnlsProcessed Number of additional inventory
demand records processed in the
consolidation.
NumInventoryDemandDtlsProcessed Number of inventory demand details
records processed in the consolidation.

Pending Job Count

For this transaction the pending job count is the number of distinct inventory items
in the YFS_INVENTORY_SUPPLY_ADDNL and
YFS_INVENTORY_DEMAND_ADDNL tables, multiplied by two.

Chapter 22. Time-Triggered Transaction Reference 383


Events Raised

None.

Consolidate To Shipment
This is a task queue based transaction in the order pipeline that corresponds to
base transaction CONSOLIDATE_TO_SHIPMENT. This transaction finds a
shipment into which a given order release can be included. If it finds an existing
shipment, it calls changeShipment() API. Otherwise, it calls the createShipment()
API.

To find the existing shipments it matches ShipNode, ShipTo Address,


SellerOrganizationCode, Carrier, DocumentType and so forth, of the Order Release
with that of existing shipments. List of attributes it matches is actually based on
Document Template for Document Type of the Order.

This transaction is applicable only to the shipments in one of the following


Statuses:
v Shipment Created
v ESP Check Required
v On ESP Hold
v Released from ESP Hold
v Released For Routing
v Awaiting Routing
v Shipment Routing
v Sent To Node

To successfully consolidate an Order Release to an existing shipment, the Add Line


and related modification types on shipment in its current status should be allowed.

This transaction is a part of the Order Fulfillment pipeline. In addition, it should


be configured to work from the task queue.

Order releases with GIFT_FLAG set to Y are never consolidated with any other
release.

For more information, see the details provided under the createShipment(),
changeShipment(), and releaseOrder() APIs in the Sterling Selling and Fulfillment
Foundation: Javadocs.

Attributes

The following are the attributes for this time-triggered transaction:


Table 161. Consolidate to Shipment Attributes
Attribute Value
Base Transaction ID CONSOLIDATE_TO_SHIPMENT
Base Document Type Order
Base Process Type Order Fulfillment
Abstract Transaction No
APIs Called createShipment() and changeShipment()

384 Sterling Selling and Fulfillment Foundation: Application Platform Configuration Guide
Table 161. Consolidate to Shipment Attributes (continued)
Attribute Value
User Exits v It calls beforeConsolidateToShipment in
com.yantra.ydm.japi.ue.
v YDMBeforeConsolidateToShipment for each release before
it begins processing.
v After it finds the shipments, it calls
determineShipmentToConsolidateWith in
com.yantra.ydm.japi.ue.

YDMDetermineShipmentToConsolidateWith.

For more information, see the Sterling Selling and Fulfillment


Foundation: Javadocs.

Criteria Parameters

The following are the criteria parameters for this transaction:


Table 162. Consolidate to Shipment Criteria Parameters
Parameter Description
Action Required. Triggers the transaction. If left blank, it defaults to
Get, the only valid value.
Number of Records To Optional. Number of records to retrieve and process at one
Buffer time. If left blank or specified as 0 (zero), it defaults to 5000.
Next Task Queue Interval Optional. Specifies in hours how long a failed task should be
suspended before it is considered for reprocessing. Defaults to
5 hours.
ColonyID Required in a multischema deployment where a table may
exist in multiple schemas. Runs the agent for the colony.

Statistics Tracked

The following statistics are tracked for this transaction:


Table 163. Consolidate to Shipment Statistics
Statistic Name Description
NumOrderReleasesConsolidated Number of order releases consolidated.

Pending Job Count

For this transaction the pending job count is the number of records available to be
processed by the transaction with the AVAILABLE_DATE value less than or equal
to (<=) the current date value in the YFS_Task_Q table.

Chapter 22. Time-Triggered Transaction Reference 385


Events Raised

The following events are raised by this time-triggered transaction:


Table 164. Events Raised by the Consolidate to Shipment Transaction
Template
Transaction/Event Key Data Data Published Support?
ON_SUCCESS shipment_dbd.txt YDM_CONSOLIDATE_TO Yes
_SHIPMENT.ON_
SUCCESS.xml

This transaction also raises events as specified under the createShipment() and
changeShipment() APIs in the Sterling Selling and Fulfillment Foundation: Javadocs.

However, note that the template name would read


<TransactionId>.ON_SUCCESS.xml.

Create Catalog Index


The Create Catalog Index transaction builds the Apache Lucene index file that is
used by catalog search. This index file enhances search performance by storing
denormalized item data that has been extracted from the Sterling Selling and
Fulfillment Foundation database or from an external source.

The Create Catalog Index transaction can be configured to perform the following
tasks:
v Run either a scheduled index build or user-initiated index build
v Build either a full or incremental index file
v Activate the index file

The Index Building Process

The Create Catalog Index transaction provides an agent for index building. Index
building is a multi-thread process in which the index building agent extracts item
and item-related information from the active selling catalog in the Sterling Selling
and Fulfillment Foundation database. If the corresponding XML configuration file
has been extended, the agent may extract this information from an external source.

The agent writes this information to multiple files, which identify the item data
that should be included in the final index. After the agent finishes writing the files,
it merges them into the final index file.

The multi-thread process provides the advantage of parallel processing. Large


amounts of database data are segmented and processed simultaneously, which is
faster and more scalable than sequentially processing one long file.

When writing information to multiple files, the index building agent performs the
following tasks for each item before looping to the next item:
v Queries the Sterling Selling and Fulfillment Foundation database or an external
source for data about the item.
v Uses information from the XML configuration file and extension file to
determine the data that be retrieved from the query.

386 Sterling Selling and Fulfillment Foundation: Application Platform Configuration Guide
v Retrieves relevant data from the Sterling Selling and Fulfillment Foundation
database.
v Creates a Lucene document for the item.

After the transaction creates a Lucene document for each item, the transaction
writes the documents to the index file based on the organization and the
organization's locales.

Configuration Options for Accessing Catalog Index Files

You can configure catalog index builds in one of the following two ways,
depending on your business requirements:
v Build the index on a shared, central disk that is accessible from all servers.
– Advantages:
- Centralized control of shared index
- No file transfer issues because the index is not copied across multiple
servers
– Limitation:
- Shared disk could become a single point of failure (if no redundancy is
involved)
- Volume of reads and writes from shared disk might slow performance,
depending on the setup
v Build and push a copy of the index to multiple servers via file transfer.
Automate this file transfer process to occur on completion of an index build, but
do not automatically activate the index. When all servers have acknowledged
the completion of the file transfer, call the manageSearchIndexTrigger API to
activate the index.
– Advantage:
- No central point of failure
– Limitation:
- Possible overhead to building an pushing index files across servers
If you choose this method of building the index in one location and reading
it from another, refer to the Sterling Selling and Fulfillment Foundation:
Properties Guide for information about enabling different properties for
individual processes.

For more information about building and searching catalog indexes, see the Sterling
Selling and Fulfillment Foundation: Catalog Management Concepts Guide.

Attributes

The following table displays the attributes for the Create Catalog Index transaction.
Table 165. Create Catalog Index Attributes
Attribute Value
Base Transaction ID Create_Catalog_Index
Base Document Type General
Base Process Type General
Abstract Transaction No
APIs Called None

Chapter 22. Time-Triggered Transaction Reference 387


Table 165. Create Catalog Index Attributes (continued)
Attribute Value
User Exits Called YCMParseAssetUE

YCMGetAdditionalCatalogIndexInformationUE

Criteria Parameters

The following table displays the criteria parameters for the Create Catalog Index
transaction.
Table 166. Create Catalog Index Criteria Parameters
Parameter Description
Organization Code Required. The organization code of the catalog organization or
subcatalog organization that maintains the search index.
Number of Messages Required. Number of messages to use when building the
index file.

Sterling Selling and Fulfillment Foundation processes only one


message per thread. For example, if Number of Messages is
set to 10 and Threads is set to 3, Sterling Selling and
Fulfillment Foundation processes only 3 messages at a time.
For more information about fine-tuning system performance,
see the Sterling Selling and Fulfillment Foundation: Performance
Management Guide.
Incremental Build Y or N.

Y to rebuild the existing index file. If you specify Y, Sterling


Selling and Fulfillment Foundation rebuilds the index based
on the last successful index build. The MaxModifyTS column
in the YFS_ITEM table determines whether or not an item's
attributes have changed. If any external attributes of an item
have changed, update the MaxModifyTS column by calling the
manageItem API on the item.

N to build a full index file.

This parameter is ignored for user-initiated index builds.


However, if scheduled builds are configured, ensure that you
specify whether you want a full or incremental index build.
Category Domain Optional. The catalog from which the index is built. The active
selling catalog of the catalog organization or subcatalog
organization is the default. If scheduled builds are configured,
ensure that you specify a catalog.
Auto Activate Y or N. Optional.

Y to activate the index after building the index file.

The default is N.

388 Sterling Selling and Fulfillment Foundation: Application Platform Configuration Guide
Table 166. Create Catalog Index Criteria Parameters (continued)
Parameter Description
Auto Insert Search Index Y or N. Optional.
Trigger Y to enable scheduled builds of the catalog index file. The
agent refers to information stored in the
YFS_SEARCH_INDEX_TRIGGER table to determine when to
run the scheduled index build. Specify the type of index build,
whether full or incremental, in the agent criteria.

N to enable user-initiated builds of the catalog index file. The


agent continuously queries the
YFS_SEARCH_INDEX_TRIGGER table to determine whether
an index build is indicated. If a user starts an index build from
the IBM Sterling Business Center, the status setting in the table
changes to Scheduled, triggering the agent to build the index.
The user specifies the type of index build, whether full or
incremental, from the Sterling Business Center.

After a scheduled or user-initiated build runs, the user can


activate the index from the Sterling Business Center.
Alternatively, the agent can be configured to automatically
activate the index.

To allow both scheduled and user-initiated index builds,


configure the transaction to include two instances of the agent.
Configure one instance to trigger user-initiated builds and the
second instance to trigger scheduled index builds.
ColonyID Required in a multischema deployment where a table may
exist in multiple schemas. Runs the agent for the colony.

Statistics Tracked

The following table shows the statistics for the Create Catalog Index transaction.
Table 167. Create Catalog Index Statistics
Statistic Name Description
SearchIndicesBuilt Number of search indices that have been built.

Pending Job Count

None.

Events Raised

The following events are raised by this time-triggered transaction:


Table 168. Events Raised by the Create Catalog Index Transaction
Template
Transaction/Event Key Data Data Published Support?
ON_SUCCESS Not Published CATALOG_INDEX_BUILD.ON Yes
_SUCCESS.xml

Chapter 22. Time-Triggered Transaction Reference 389


Create Chained Order
This transaction creates one or more chained orders from an order whose
OrderHeaderKey is stored in the task queue object. Chainable lines of the order
can also be added to existing chained orders, instead of creating new chained
orders with these lines. The existing chained orders must be identified by the
determineChainedOrderForConsolidation user exit. If the user exit is not
implemented, or if the user exit returns a blank document, one or more new
chained orders are created.

For more information about the creation of chained orders, see the information
provided under the createChainedOrder() API and the
YFSDetermineChainedOrderForConsolidation user exit in the Sterling Selling and
Fulfillment Foundation: Javadocs.

This transaction should be invoked after order scheduling.

Attributes

The following are the attributes for this time-triggered transaction:


Table 169. Create Chained Order Attributes
Attribute Value
Base Transaction ID CHAINED_ORDER_CREATE
Base Document Type Order
Base Process Type Order Fulfillment
Abstract Transaction Yes
APIs Called createChainedOrder()

Criteria Parameters

The following are the criteria parameters for this transaction:


Table 170. Create Chained Order Criteria Parameters
Parameter Description
Action Required. Triggers the transaction. If left blank, it defaults to
Get, the only valid value.
Number of Records To Optional. Number of records to retrieve and process at one
Buffer time. If left blank or specified as 0 (zero), it defaults to 5000.
Next Task Queue Interval Optional. Specifies in hours how long a failed task should be
suspended before it is considered for reprocessing. Defaults to
5 hours.
ColonyID Required in a multischema deployment where a table may
exist in multiple schemas. Runs the agent for the colony.

390 Sterling Selling and Fulfillment Foundation: Application Platform Configuration Guide
Statistics Tracked

The following statistics are tracked for this transaction:


Table 171. Create Chained Order Statistics
Statistic Name Description
NumOrdersProcessed Number of orders processed for creating chained
order.
NumOrdersCreated Number of chained orders created.

If there are 2 orders being processed and the first order creates a chained order, the
DetermineChainedOrderForConsolidation user exit causes the lines of the 2nd
order to be added to the first order. The number of chained orders created is
counted as 2.

Pending Job Count

For this transaction the pending job count is the number of records available to be
processed by the transaction with the AVAILABLE_DATE value less than or equal
to (<=) the current date value in the YFS_Task_Q table.

Events Raised

This transaction raises events as specified under the createChainedOrder() API in


the Sterling Selling and Fulfillment Foundation: Javadocs.

Create Derived Order


This transaction creates one or more derived orders from an order whose
OrderHeaderKey is stored in the task queue object. For existing derived orders,
you can add derivable lines or create new derived orders with these lines. The
existing derived orders must be identified by the
determineDerivedOrderForConsolidation user exit. If the user exit is not
implemented or if the user exit returns a null document, new derived orders are
created. For more information about the creation of derived orders, see the details
provided under the createDerivedOrder() API and
YFSDetermineDerivedOrderForConsolidation user exit in the Sterling Selling and
Fulfillment Foundation: Javadocs.

Attributes

The following are the attributes for this time-triggered transaction:


Table 172. Create Derived Order Attributes
Attribute Value
Base Transaction ID DERIVED_ORDER_CREATE
Base Document Type Order
Base Process Type Order Fulfillment
Abstract Transaction Yes
APIs Called createDerivedOrder()

Chapter 22. Time-Triggered Transaction Reference 391


The TransactionKey posted in the task queue object must be an instance of the
Abstract Transaction DERIVED_ORDER_CREATE for the ProcessType associated
with the Order. Otherwise, an exception is thrown.

Criteria Parameters

The following are the criteria parameters for this transaction:


Table 173. Create Derived Order Criteria Parameters
Parameter Description
Action Required. Triggers the transaction. If left blank, it defaults to
Get, the only valid value.
Number of Records To Optional. Number of records to retrieve and process at one
Buffer time. If left blank or specified as 0 (zero), it defaults to 5000.
Next Task Queue Interval Optional. Specifies in hours how long a failed task should be
suspended before it is considered for reprocessing. Defaults to
5 hours.
ColonyID Required in a multischema deployment where a table may
exist in multiple schemas. Runs the agent for the colony.

Statistics Tracked

The following statistics are tracked for this transaction:


Table 174. Create Derived Order Statistics
Statistic Name Description
NumOrdersProcessed Number of orders processed.
NumOrdersCreated Number of derived orders created.

If there are 2 orders being processed and the first order creates a derived order, the
DetermineChainedOrderForConsolidation user exit causes the lines of the 2nd
order to be added to the first order. The number of derived orders created is
counted as 2.

Pending Job Count

For this transaction the pending job count is the number of records available to be
processed by the transaction with the AVAILABLE_DATE value less than or equal
to (<=) the current date value in the YFS_Task_Q table.

Events Raised

This transaction raises events as specified under the createDerivedOrder() API in


the Sterling Selling and Fulfillment Foundation: Javadocs.

Create Order Invoice


This transaction creates one or more invoices from an order whose
OrderHeaderKey is stored in a task queue object. The createOrderInvoice() API is
called for the OrderHeaderKey.

392 Sterling Selling and Fulfillment Foundation: Application Platform Configuration Guide
Configure this transaction in the pipeline only after all processing that can impact
quantity or price has been completed. Post invoice creation, the line quantity
cannot be reduced below the invoiced quantity.

Both the Create Order Invoice and Create Shipment Invoice transactions can create
invoices for an Order. When configuring your pipeline, ensure that only one of
these two transactions is configured to create invoices for a particular order line.
For more information, see “Create Shipment Invoice” on page 394.

Attributes

The following are the attributes for this time-triggered transaction:


Table 175. Create Order Invoice Attributes
Attribute Value
Base Transaction ID CREATE_ORDER_INVOICE
Base Document Type Order
Base Process Type Order Fulfillment
Abstract Transaction Yes
APIs Called createOrderInvoice()

Criteria Parameters

The following are the criteria parameters for this transaction:


Table 176. Create Order Invoice Criteria Parameters
Parameter Description
Action Required. Triggers the transaction. If left blank, it defaults to
Get, the only valid value.
Number of Records To Optional. Number of records to retrieve and process at one
Buffer time. If left blank or specified as 0 (zero), it defaults to 5000.
ColonyID Required in a multischema deployment where a table may
exist in multiple schemas. Runs the agent for the colony.

Statistics Tracked

The following statistics are tracked for this transaction:


Table 177. Create Order Invoice Statistics
Statistic Name Description
NumOrderInvoicesCreated Number of order invoices created.

Pending Job Count

For this transaction the pending job count is the number of records available to be
processed by the transaction with the AVAILABLE_DATE value less than or equal
to (<=) the current date value in the YFS_Task_Q table.

Chapter 22. Time-Triggered Transaction Reference 393


Events Raised

This transaction raises events as specified under the createOrderInvoice() API in


the Sterling Selling and Fulfillment Foundation: Javadocs.

Create Shipment Invoice


Invoicing is mandatory if an order requires payment processing. Invoicing occurs if
the following conditions are met:
v Invoicing is enabled at the document parameter level.
v The Seller requires payment processing.

This transaction creates one or more invoices for the shipment whose ShipmentKey
is stored in the task queue object. The createShipmentInvoice() API is called for
the ShipmentHeaderKey.

This transaction should be configured in the shipment pipeline only after the
shipment has reached a shipped status.

Both the Create Order Invoice and Create Shipment Invoice can create invoices for
an order. When configuring your pipeline, ensure that only one of these two
transactions is configured to create invoices for a particular order line. See “Create
Order Invoice” on page 392.

Attributes

The following are the attributes for this time-triggered transaction:


Table 178. Create Shipment Invoice Attributes
Attribute Value
Base Transaction ID CREATE_SHIPMENT_INVOICE
Base Document Type Order
Base Process Type Order Delivery
Abstract Transaction Yes
APIs Called createShipmentInvoice()

Criteria Parameters

The following are the criteria parameters for this transaction:


Table 179. Create Shipment Invoice Criteria Parameters
Parameter Description
Action Required. Triggers the transaction. If left blank, it defaults to
Get, the only valid value.
Number of Records To Optional. Number of records to retrieve and process at one
Buffer time. If left blank or specified as 0 (zero), it defaults to 5000.
ColonyID Required in a multischema deployment where a table may
exist in multiple schemas. Runs the agent for the colony.

394 Sterling Selling and Fulfillment Foundation: Application Platform Configuration Guide
Statistics Tracked

The following statistics are tracked for this transaction:


Table 180. Create Shipment Invoice Statistics
Statistic Name Description
NumShipmentInvoicesCreated Number of shipment invoices created.

Pending Job Count

For this transaction the pending job count is the number of records available to be
processed by the transaction with the AVAILABLE_DATE value less than or equal
to (<=) the current date value in the YFS_Task_Q table.

Events Raised

This transaction raises events as specified under the createShipmentInvoice() API


in the Sterling Selling and Fulfillment Foundation: Javadocs.

ESP Evaluator
The ESP Evaluator time-triggered transaction verifies whether a shipment meets
certain economic shipping parameters (ESP). ESP can be configured either for
buyer or enterprise, with the freight terms on the shipment determining which one
is used.

If the configuration is defined to hold shipment for ESP, the shipment when
created is held for ESP (with status On ESP Hold). This task queue based
time-triggered transaction evaluates the shipment for ESP, and passes it on to the
next step in the shipment pipeline if the criteria (weight and volume limits, plus
maximum days of hold up) are met. The shipment status is now set to Released
from ESP hold, and routing processing begins.

Attributes

The following are the attributes for this time-triggered transaction:


Table 181. ESP Evaluator Attributes
Attribute Value
Base Transaction ID ESP_EVALUATOR.0001
Base Document Type Order
Base Process Type Outbound Shipment
Abstract Transaction No
APIs Called None
User Exits Called getNodeMinimumNotificationTime

Chapter 22. Time-Triggered Transaction Reference 395


Criteria Parameters

The following are the criteria parameters for this transaction:


Table 182. ESP Evaluator Criteria Parameters
Parameter Description
Action Required. Triggers the transaction. If left blank, it defaults to
Get, the only valid value.
EnterpriseCode Optional. Enterprise for which the ESP Evaluator needs to be
run. If not passed, then all enterprises are monitored.
Number of Records to Optional. Number of records to retrieve and process at one
Buffer time. If left blank or specified as 0 (zero), it defaults to 5000.
Next Task Queue Interval Optional. Specifies in hours how long a failed task should be
suspended before it is considered for reprocessing. Defaults to
5 hours.
Node Required. The warehouse management ship node for which
records are being processed.
AgentCriteriaGroup Optional. Used to classify nodes. This value can be accepted
by Sterling Warehouse Management System time-triggered
transactions that only perform their tasks on the nodes with a
matching node transactional velocity value.

Valid values are: LOW, HIGH, and any additional values


defined by the Hub from Application Platform > System
Administration > Agent Criteria Groups.
ColonyID Required in a multischema deployment where a table may
exist in multiple schemas. Runs the agent for the colony.

Statistics Tracked

None.

Pending Job Count

For this transaction the pending job count is the number of records available to be
processed by the transaction with the AVAILABLE_DATE value less than or equal
to (<=) the current date value in the YFS_Task_Q table.

Events Raised

The following events are raised by this time-triggered transaction:


Table 183. Events Raised by ESP Evaluator Transaction
Template
Transaction/Event Key Data Data Published Support?
ON_SUCCESS shipment_dbd.txt ESP_EVALUATOR.ON_ Yes
SUCCESS.xml

396 Sterling Selling and Fulfillment Foundation: Application Platform Configuration Guide
Item Based Allocation
The Item Based Allocation transaction allocates unpromised and promised
demands of existing orders to more suitable supplies based upon inventory items
and nodes which have been triggered for the Item Based Allocation process in the
YFS_IBA_TRIGGER table.

The Item Based Allocation agent obtains and processes all Item Based Allocation
triggers from the YFS_IBA_TRIGGER table that meet the following conditions:
v IBA_RUN_REQUIRED = "Y"
v LAST_IBA_PROCESSED_TS was 'x' hours before current time, where 'x' is from
the ‘Item Based Allocation Agent Execution Interval (in hours)' rule in the
Installation rules. For more information about installation rules, refer to the
Sterling Selling and Fulfillment Foundation: Application Platform Configuration Guide.
This rule is used to indicate the interval that the Item Based Allocation agent
should not reprocess the triggers in the YFS_IBA_TRIGGER table, which were
processed earlier. This prevents the IBA agent from over-processing the item and
node combination in the given time interval to avoid any high loads on the
system.
v PROCESSING_BY_AGENT="N" or PROCESS_OVER_BY_TS is before the current
timestamp. The PROCESSING_BY_AGENT field is used to prevent the picking
up of the IBA trigger which is being processed by another instance of the agent.

If InventoryOrganizationCode is specified in the agent criteria, only the IBA trigger


with inventory items of that inventory organization is retrieved.

For each triggered item and node combination, the agent finds all of the applicable
order lines or order line reservations that contain the item and node and tries to
move their unpromised and promised demands to more suitable available supplies
based on user-configured IBA selection rules or FIFO (First-In-First-Out) IBA
selection rules.

Sterling Selling and Fulfillment Foundation creates new positive order line
reservations with the matched supply's first ship date and negative order line
reservations for the existing demand ship date. Once all orders are processed, they
are placed on hold to be rescheduled if changes are detected in the order line
reservations.

The following configuration is required for the Item Based Allocation process:
v The Use Item Based Allocation rule needs to be enabled.
v Item and node need to have Item Based Allocation Allowed enabled.
v A hold type is required to be set up for the change order line reservations
modification type so that the order can be placed on hold for rescheduling. For
more information, refer to the Sterling Selling and Fulfillment Foundation: Javadocs.

The ‘When a line is backordered, backorder against the highest priority ship node'
rule should be checked in order to reallocate backordered demand. For more
information, see the Fulfillment Rules section in the Sterling Selling and Fulfillment
Foundation: Distributed Order Management Configuration Guide.

Before processing the Item Based Allocation logic, the Item Based Allocation agent
updates the following fields on the Item Based Allocation trigger:
v PROCESSING_BY_AGENT = “Y”. This indicates that an instance of the agent is
currently processing this trigger.

Chapter 22. Time-Triggered Transaction Reference 397


v PROCESS_OVER_BY_TS = current time + 1 hr. This indicates the expected time
that the agent should finish with processing this IBA trigger. One hour is the
fixed window and cannot be changed. Sterling Selling and Fulfillment
Foundation treats the PROCESSING_BY_AGENT flag as “N” regardless of the
actual value when current timestamp is after this timestamp.
v IBA_RUN_REQUIRED = ”N”. This resets the IBA_RUN_REQUIRED flag back to
“N”.

Obtaining a List of Demands Based on Applicable Order Release


Statuses and Order Line Reservations to be Allocated

A list of demands is derived from applicable order release statuses and order line
reservations, which have the item and node in the IBA trigger. The following types
of demands are retrieved:
v Demands of chained orders
v Demands of orders with chained order already created
v Demands of orders with procurement node but chained order creation is not yet
created
v Demands of orders without procurement node
v Demands from order line reservations

The demand quantity is derived based on the order release status quantity with
the status from the Status Inventory Type configuration that has a demand type,
which considers the supply type with ‘Use Consider Demand Type for Item Based
Allocation' enabled. For more information, refer to the Sterling Selling and
Fulfillment Foundation: Global Inventory Visibility Configuration Guide.

Obtaining a List of Available Supplies for Allocation

Sterling Selling and Fulfillment Foundation obtains the available supply based on
the availability of the item at the node by ignoring unpromised and promised
demands. If the inventory organization maintains its inventory externally, the
external availability can be read by the YFSGetExternalInventoryUE user exit. Only
the availability of supplies that consider the ‘Demand Type Look for Availability
during Item Based Allocation' are used in the allocation logic. For more
information, refer to the Sterling Selling and Fulfillment Foundation: Global Inventory
Visibility Configuration Guide.

Allocated demands should be matched with the same supplies as "Demand to look
for during release".

Matching Demands Against Supplies in FIFO (First-In-First-Out)


Order

Sterling Selling and Fulfillment Foundation sorts the list of available supplies in
the order of the first shippable date (ETA), and matches the obtained list of
demands using the top-down logic (unlike the normal matching logic for obtaining
availability, where matches are based on the closest ETA). Demands are allocated
in the following orders:
v Demands of chained orders - first based on user-configured sequencing rules,
and then in ascending order of order creation date. (These types of demands are
matched based on the closest ETA to avoid any changes in the chained orders).

398 Sterling Selling and Fulfillment Foundation: Application Platform Configuration Guide
v Demands of orders with a chained order already created - first based on
user-configured sequencing rules, then in ascending order of product availability
date. (These types of demands are matched based on the closest ETA to avoid
any changes in the orders).
v Demands of orders for which procurement node and chained order creation is
imminent (within the advanced notification time window) - first based on
user-configured sequencing rules, then in order of order creation date.
v Demands of orders without a procurement node and within the release window
(advanced notification time window) - first based on user-configured sequencing
rules, then in order of order creation date.
v Demands from order line reservations on the order lines in the order of
requested reservation date, and left-over demands (outside of the advanced
notification time window) of orders with or without a procurement node, first
based on user-configured sequencing rules and then in the order of order
creation date.
v Demands from inventory reservations in the order of ship date.

Notice that different types of demands are given different priorities based on their
significance. The demands of chained orders or orders related to chained orders
are treated with a higher priority than the demands of normal orders. Furthermore,
the demands with a ship date within the advanced notification time window also
have a higher priority than the demands with a date outside of the advanced
notification time window.

Updating Order Reservations for the Matched Demands

After matching the available supply and demand in user-configured sequencing


and then in FIFO order, the system builds up a list of order line reservation
changes and inventory demand changes (corresponding to the order line
reservation changes) and summarize them to optimize the number of order
reservation updates and inventory updates. Negative order line reservations are
added for the matched demands. Positive order reservations are added for the
matched demands with the product availability date set to the matched supplies'
first ship date.

After the Item Based Allocation agent completes its tasks for an Item Based
Allocation trigger, it updates the fields of the trigger with the following values:
v IBA_REQUIRED = "N"
v LAST_IBA_PROCESSED_TS = current timestamp.
v PROCESS_OVER_BY_TS = current timestamp.
v PROCESSING_BY_AGENT = ”N”

The Item Based Allocation agent should be used in conjunction with the
rescheduling process as the rescheduling process reschedules the affected orders by
utilizing the order line reservations created by the Item Based Allocation process.

Attributes

The following are the attributes for this time-triggered transaction:


Table 184. Item Based Allocation Attributes
Attribute Value
Base Transaction ID ITEM_BASED_ALLOCATION

Chapter 22. Time-Triggered Transaction Reference 399


Table 184. Item Based Allocation Attributes (continued)
Attribute Value
Base Document Type General
Base Process Type General
Abstract Transaction No
APIs Called changeOrder – for updating the order line reservations created
as part of the Item Based Allocation process.
User Exits Called None

Criteria Parameters

The following are the criteria parameters for this transaction:


Table 185. Item Based Allocation Criteria Parameters
Parameter Description
Action Required. Triggers the transaction. If left blank, it defaults to
Get, the only valid value.
Number of Records To Optional. Number of records to retrieve and process at one
Buffer time. If left blank or specified as 0 (zero), it defaults to 5000.
InventoryOrganization The inventory organization code of the inventory items which
Code are processed by the Item Based Allocation agent. If provided,
only the IBA triggers with the inventory item that belongs to
this inventory organization are processed.
ColonyID Required in a multischema deployment where the
YFS_IBA_TRIGGER table may exist in multiple schemas. Runs
the agent for the colony.

Statistics Tracked

The following statistics are tracked for this transaction:


Table 186. Item Based Allocation Statistics
Statistic Name Description
NumOrdersProcessed Number of orders processed by the Item Based
Allocation agent.
NumOrdersRequiredReschedule Number of orders required rescheduling as the
result of Item Based Allocation process.

Pending Job Count

None.

Events Raised

This transaction raises events as specified under the changeOrder API in the
Sterling Selling and Fulfillment Foundation: Javadocs.

Mark Load as Trailer Loaded


This is a time-triggered transaction which works on “Load pipeline”.

400 Sterling Selling and Fulfillment Foundation: Application Platform Configuration Guide
This time-triggered transaction gets records from the Task Q. This transaction is
used to mark the load as trailer loaded when all containers for the load are on the
trailer.

Attributes

The following are the attributes for this time-triggered transaction:


Table 187. Mark Load As Trailer Loaded Attributes
Attribute Value
Base Transaction ID MARK_AS_TRAILER_LOADED
Base Document Type Load
Base Process Type Load Execution
Abstract Transaction No
APIs Called None
User Exits Called None

Criteria Parameters

The following are the criteria parameters for this transaction:


Table 188. Mark Load As Trailer Loaded Criteria Parameters
Parameter Description
Action Required. Triggers the transaction. If left blank, it defaults to
Get, the only valid value.
Number of Records To Optional. Number of records to retrieve and process at one
Buffer time. If left blank or specified as 0 (zero), it defaults to 5000.
ReprocessInterval Optional. Reprocess Interval is the time taken to reprocess the
load.
ColonyID Required in a multischema deployment where a table may
exist in multiple schemas. Runs the agent for the colony.

Statistics Tracked

The following statistics are tracked for this transaction:


Table 189. Mark Load As Trailer Loaded Statistics
Statistic Name Description
NumLoadsChanged Number of trailer loads changed.

Pending Job Count

For this transaction the pending job count is the number of records available to be
processed by the transaction with the AVAILABLE_DATE value less than or equal
to (<=) the current date value in the YFS_Task_Q table.

Events Raised

None.

Chapter 22. Time-Triggered Transaction Reference 401


Match Inventory
Match Inventory processes all pending records in the
YFS_INVENTORY_SHIPMENT table. Pending records have a smaller number in
POSTED_QUANTITY than in QUANTITY.

Each pending record is matched against the receipt records in


YFS_INVENTORY_RECEIPT table by applying the inventory cost determination
logic. The unit cost at which the sales and receipt data are matched is also posted
in YFS_INVENTORY_MATCH table.

Use this transaction if any of the configured ship nodes maintain inventory cost.

Attributes

The following are the attributes for this time-triggered transaction:


Table 190. Match Inventory Attributes
Attribute Value
Base Transaction ID INVENTORY_MATCH
Base Document Type General
Base Process Type General
Abstract Transaction No
APIs Called None

Criteria Parameters

The following are the criteria parameters for this transaction:


Table 191. Match Inventory Criteria Parameters
Parameter Description
Action Required. Triggers the transaction. If left blank, it
defaults to Get, the only valid value.
Number of Records To Buffer Optional. Number of records to retrieve and process at
one time. If left blank or specified as 0 (zero), it
defaults to 5000.
InventoryOrganizationCode Optional. Valid inventory owner organization.
Organization to process in this run. If not passed, all
inventory organizations are processed.
CutOffDate Optional. If passed, records are matched up to this
date. Defaults to all unmatched records in Database.
ColonyID Required in a multischema deployment where the
YFS_INVENTORY_SHIPMENT,
YFS_INVENTORY_RECEIPT, and the
YFS_INVENTORY_MATCH tables may exist in
multiple schemas. Runs the agent for the colony.

402 Sterling Selling and Fulfillment Foundation: Application Platform Configuration Guide
Statistics Tracked

The following statistics are tracked for this transaction:


Table 192. Match Inventory Statistics
Statistic Name Description
NumInventoryShipmentsProcessed Number of inventory shipments processed.
NumInventoryMatchesInserted Number of inventory matches inserted.

Pending Job Count

For this transaction the pending job count is the number of distinct inventory items
that exist in the YFS_INVENTORY_SHIPMENT table where the QUANTITY value
is not equal to the POSTED_QUANTITY value.

Events Raised
None.

Payment Collection
This transaction requests credit validation for orders that are pending authorization
or charging.

Use this transaction for creating authorization and charge requests.

This transaction works in combination with the Payment Execution transaction.


Although this transaction can run independent of that transaction, authorization
and collection occurs only after the Payment Execution dependencies are met. For
more details, see “Payment Execution” on page 405.

Attributes

The following are the attributes for this time-triggered transaction:


Table 193. Payment Collection Attributes for Sales Orders
Attribute Value
Base Transaction ID PAYMENT_COLLECTION
Base Document Type Order
Base Process Type Order Fulfillment
Abstract Transaction No
APIs Called requestCollection()

Table 194. Payment Collection Attributes for Return Orders


Attribute Value
Base Transaction ID PAYMENT_COLLECTION.0003
Base Document Type Order
Base Process Type Reverse Logistics
Abstract Transaction No
APIs Called requestCollection()

Chapter 22. Time-Triggered Transaction Reference 403


Criteria Parameters

The following are the criteria parameters for this transaction:


Table 195. Payment Collection Criteria Parameters
Parameter Description
Action Required. Triggers the transaction. If left blank, it defaults to
Get, the only valid value.
Number of Records To Optional. Number of records to retrieve and process at one
Buffer time. If left blank or specified as 0 (zero), it defaults to 5000.
EnterpriseCode Optional. The enterprise for which the transaction needs to be
run. If left blank, orders for all enterprises are processed. If
specified, only orders for that enterprise are processed.
ColonyID Required in a multischema deployment where a table may
exist in multiple schemas. Runs the agent for the colony.
HoldTypeOnRollback If the HoldTypeOnRollback criteria is populated and the
requestCollection agent throws an exception, for example,
from the getFundsAvailable user exit, HoldTypeOnRollback
will be used to put the order on hold. If using the old order
hold functionality, this will be used as the hold reason. If the
hold type does not exist, an exception is thrown.

If the HoldTypeOnRollback criteria is not populated, the order


will not be put on hold if an exception is thrown.

Statistics Tracked

The following statistics are tracked for this transaction:


Table 196. Payment Collection Statistics
Statistic Name Description
NumOrdersProcessed Number of orders processed.
NumChargeReqsCreated Number of charge requests created.
NumAuthorizationReqsCreated Number of authorization requests created.

Pending Job Count

For this transaction the pending job count is the number of orders in the
appropriate payment statuses with the value of the
AUTHORIZATION_EXPIRATION_DATE is less than or equal to (<=) the current
date. The appropriate payment statuses for such orders are:
v AWAIT_PAY_INFO
v AWAIT_AUTH
v REQUESTED_AUTH
v REQUEST_CHARGE
v AUTHORIZED, INVOICED
v PAID
v RELEASE_HOLD
v FAILED_AUTH

404 Sterling Selling and Fulfillment Foundation: Application Platform Configuration Guide
v FAILED_CHARGE
v VERIFY
v FAILED

Events Raised

The following events are raised by this time-triggered transaction:


Table 197. Events Raised by the Payment Collection Transaction
Template
Transaction/Event Key Data Data Published Support?
INCOMPLETE_PAYMENT modifyOrder YFS_PAYMENT_ Yes
_INFORMATION _dbd.txt COLLECTON.INCOMPLETE
_PAYMENT
_INFORMATION.xml
PAYMENT_STATUS YFS_PAYMENT YFS_PAYMENT_ Yes
_COLLECTION COLLECTION.
.PAYMENT PAYMENT_STATUS.xml
_STATUS_
dtd.txt
REQUEST_PAYMENT_ YFS_PAYMENT_ Yes
STATUS COLLECTION.REQUEST
_PAYMENT_STATUS.
xml
ON_LIABILITY_ modifyOrder YFS_PAYMENT_ Yes
TRANSFER _dbd.txt COLLECTION.ON_
LIABILITY_TRANSFER.xml
ON_INVOICE_ order_dbd/txt YFS_CREATE_ORDER_ Yes
COLLECTION INVOICE.ON_
INVOICE_
COLLECTION.xml

Payment Execution
This transaction processes all requests that are pending authorization and charging.

Use this time-triggered transaction for processing all authorization and charge
requests.

This transaction requires interfacing with a product that provides financial services.

Attributes

The following are the attributes for this time-triggered transaction:


Table 198. Payment Execution Attributes for Sales Orders
Attribute Value
Base Transaction ID PAYMENT_EXECUTION
Base Document Type Order
Base Process Type Order Fulfillment
Abstract Transaction No
APIs Called executeCollection()

Chapter 22. Time-Triggered Transaction Reference 405


Table 198. Payment Execution Attributes for Sales Orders (continued)
Attribute Value
User Exits Called collectionCreditCard, collectionOthers,
collectionCustomerAcct

Table 199. Payment Execution Attributes for Return Orders


Attribute Value
Base Transaction ID PAYMENT_EXECUTION.0003
Base Document Type Order
Base Process Type Reverse Logistics
Abstract Transaction No
APIs Called executeCollection()
User Exits Called collectionCreditCard, collectionOthers,
collectionCustomerAcct

Criteria Parameters

The following are the criteria parameters for this transaction:


Table 200. Payment Execution Criteria Parameters
Parameter Description
Action Required. Triggers the transaction. If left blank, it defaults to
Get, the only valid value.
Number of Records To Optional. Number of records to retrieve and process at one
Buffer time. If left blank or specified as 0 (zero), it defaults to 5000.
ChargeType Type of credit card process. Valid values are:
v AUTHORIZATION - Validates the credit card account
v CHARGE - Applies the charge to the credit card
ColonyID Required in a multischema deployment where a table may
exist in multiple schemas. Runs the agent for the colony.

Statistics Tracked

The following statistics are tracked for this transaction:


Table 201. Payment Execution Statistics
Statistic Name Description
NumAuthTransProcessed Number of authorization transaction
processed.
NumAuthTransSuccessfullyProcessed Number of successful returns from user exit
for authorization transaction processed.
NumChargeTransProcessed Number of charge transaction processed.
NumChargeTransSuccessfullyProcessed Number of successful returns from user exit
for charge transaction processed.
NumCollectionValidations Number of successful returns from the
invoked validate collection user exits.
NumCreditCardCollections Number of credit card collections.

406 Sterling Selling and Fulfillment Foundation: Application Platform Configuration Guide
Table 201. Payment Execution Statistics (continued)
Statistic Name Description
NumCustomerAccountCollections Number of successful returns from the
customer account collection user exits.
NumOtherCollections Number of successful returns from the other
collection user exits.

Pending Job Count

For this transaction the pending job count is the number of open charge and
authorization transactions.

Events Raised

The following events are raised by this time-triggered transaction:


Table 202. Events Raised by Payment Execution Transaction
Template
Transaction/Event Key Data Data Published Support?
CHARGE_FAILED modifyOrder PAYMENT_EXECUTION_ No
dbd.txt CHARGE_FAILED_dbd.txt

This transaction raises events as specified under the executeCollection() API in


the Sterling Selling and Fulfillment Foundation: Javadocs.

Post Inventory Match


This transaction processes all open records in YFS_INVENTORY_MATCH table
and posts the records to a financial system. An open record in the
YFS_INVENTORY_MATCH table has the status of 01. After posting, the status is
changed to 02.

Use this transaction if any of the configured ship nodes maintain inventory cost.

Attributes

The following are the attributes for this time-triggered transaction:


Table 203. Post Inventory Match Attributes
Attribute Value
Base Transaction ID POST_INVENTORY_MATCH
Base Document Type General
Base Process Type General
Abstract Transaction No
APIs Called None

Chapter 22. Time-Triggered Transaction Reference 407


Criteria Parameters

The following are the criteria parameters for this transaction:


Table 204. Post Inventory Match Criteria Parameters
Parameter Description
Action Required. Triggers the transaction. If left blank, it defaults to
Get, the only valid value.
Number of Records To Optional. Number of records to retrieve and process at one
Buffer time. If left blank or specified as 0 (zero), it defaults to 5000.
ColonyID Required in a multischema deployment where the
YFS_INVENTORY_MATCH table may exist in multiple
schemas. Runs the agent for the colony.

Statistics Tracked

The following statistics are tracked for this transaction:


Table 205. Post Inventory Match Statistics
Statistic Name Description
NumInventoryMatchPosted Number of inventory match records posted.

Pending Job Count

For this transaction the pending job count is the number of inventory matches with
an open status.

Events Raised

The following events are raised by this time-triggered transaction:


Table 206. Events Raised by the Post Inventory Match Transaction
Template
Transaction/Event Key Data Data Published Support?
POST_INVENTORY_MATCH POST_ YFS_postInventory No
INVENTORY_ Match_output.xml
MATCH_dbd.txt

Process Order Hold Type


You can create a time-triggered transaction, derived from the
PROCESS_ORDER_HOLD_TYPE abstract transaction. It can be configured as the
processing transaction for one or more hold types. If an order is associated with a
hold type that has a transaction configured as the processing transaction, a record
is created in the YFS_TASK_Q table for processing that transaction.

When the processing transaction is triggered, it checks the hold types that it can
process based on the hold type configuration. If no hold types can be processed,
the YFS_TASK_Q record is deleted. If some hold types can be processed, the
processOrderHoldType user exit is invoked with the list of hold types to be
processed. The processOrderHoldType user exit returns the list of hold types that
can be removed from the order.

408 Sterling Selling and Fulfillment Foundation: Application Platform Configuration Guide
The transaction then modifies the order and updates the order hold type list based
on the output returned by the processOrderHoldType user exit. If now no hold
types can be processed, the YFS_TASK_Q record is deleted. If some hold types can
still be processed, YFS_TASK_Q is updated with the next available date.

You can also call the processOrderHoldType user exit to add new hold types or
change the status of a hold type that is already applied to an order. For more
information about the processOrderHoldType user exit, see the Sterling Selling and
Fulfillment Foundation: Javadocs.

Attributes

The following are the attributes for this time-triggered transaction:


Table 207. Process Order Hold Type Attributes
Attribute Value
Base Transaction ID PROCESS_ORDER_HOLD_TYPE
Base Document Type Order
Base Process Type Order Fulfillment
Abstract Transaction Yes
APIs Called changeOrder

Criteria Parameters

The following are the criteria parameters for this transaction:


Table 208. Process Order Hold Type Parameters
Parameter Description
Action Required. Triggers the transaction. If left blank, it defaults to
Get, the only valid value.
Number of Records To Optional. Number of records to retrieve and process at one
Buffer time. If left blank or specified as 0 (zero), it defaults to 5000.
Next Task Queue Interval Optional. Specifies in hours how long a failed task should be
suspended before it is considered for reprocessing. Defaults to
5 hours.
ColonyID Required in a multischema deployment where the
YFS_TASK_Q table may exist in multiple schemas. Runs the
agent for the colony.

Statistics Tracked

None.

Pending Job Count


None

Chapter 22. Time-Triggered Transaction Reference 409


Events Raised

The following events are raised by this time-triggered transaction:


Table 209. Events Raised by Process Order Hold Type Transaction
Template
Transaction/Event Raised when... Key Data Data Published Support?
ON_SUCCESS On success modifyOrder_ YFS_ORDER_ Yes *
dbd.txt CHANGE.ON_
SUCCESS.xml
ON_HOLD_TYPE The status of a modifyOrder_ YFS_ON_ Yes
_STATUS_ hold type is dbd.txt HOLD_TYPE_
CHANGE changed. STATUS_
CHANGE.xml
ON_ORDER_ The status of a modifyOrder_ YFS_ON_ Yes
LINE_HOLD_ hold type is dbd.txt ORDER_LINE
TYPE_STATUS_ changed. _HOLD_TYPE
CHANGE _STATUS_
CHANGE.xml
* Note: Some of the elements and attributes are not template-driven. Refer to the xml for
element level details.

Process Work Order Hold Type


This time-triggered transaction is identical to the Process Order Hold Type
transaction, but it is used for work orders instead.

Attributes

The following are the attributes for this time-triggered transaction:


Table 210. Process Work Order Hold Type Attributes
Attribute Value
Base Transaction ID PROCESS_WO_ORDER_HOLD_TYPE
Base Document Type Work Order
Base Process Type VAS Process
Abstract Transaction Yes
APIs Called modifyWorkOrder

Criteria Parameters

The following are the criteria parameters for this transaction:


Table 211. Process Work Order Hold Type Parameters
Parameter Description
Action Required. Triggers the transaction. If left blank, it defaults to
Get, the only valid value.
Number of Records To Optional. Number of records to retrieve and process at one
Buffer time. If left blank or specified as 0 (zero), it defaults to 5000.

410 Sterling Selling and Fulfillment Foundation: Application Platform Configuration Guide
Table 211. Process Work Order Hold Type Parameters (continued)
Parameter Description
Next Task Queue Interval Optional. Specifies in hours how long a failed task should be
suspended before it is considered for reprocessing. Defaults to
5 hours.
ColonyID Required in a multischema deployment where a table may
exist in multiple schemas. Runs the agent for the colony.

Statistics Tracked

None.

Pending Job Count

None

Events Raised

The following events are raised by this time-triggered transaction:


Table 212. Events Raised by Process Work Order Hold Type Transaction
Template
Transaction/Event Raised when... Key Data Data Published Support?
ON_SUCCESS On success workOrder_ VAS_MODIFY_ Yes *
dbd.txt WORK_ORDER
.ON_SUCCESS.
xml
ON_HOLD_TYPE_ The status of a workOrder_ VAS_ON_HOLD Yes
STATUS_ hold type is |dbd.txt _TYPE_STATUS
CHANGE changed. _CHANGE.xml
* Note: Some of the elements and attributes are not template driven. Refer to the xml for
elements level details.

Publish Negotiation Results


This transaction publishes the negotiated terms to the order.

Use this transaction in environments where an order must go through a


negotiation phase.

This transaction needs to be run after negotiation is completed.

Attributes

The following are the attributes for this time-triggered transaction:


Table 213. Publish Negotiation Results Attributes
Attribute Value
Base Transaction ID PUBLISH_ORD_NEGOTIATION
Base Document Type Order
Base Process Type Order Negotiation

Chapter 22. Time-Triggered Transaction Reference 411


Table 213. Publish Negotiation Results Attributes (continued)
Attribute Value
Abstract Transaction No
APIs Called None

Criteria Parameters

The following are the criteria parameters for this transaction:


Table 214. Publish Negotiation Results Criteria Parameters
Parameter Description
Action Required. Triggers the transaction. If left blank, it defaults to
Get, the only valid value.
Number of Records To Optional. Number of records to retrieve and process at one
Buffer time. If left blank or specified as 0 (zero), it defaults to 5000.
Next Task Queue Interval Optional. Specifies in hours how long a failed task should be
suspended before it is considered for reprocessing. Defaults to
5 hours.
ColonyID Required in a multischema deployment where a table may
exist in multiple schemas. Runs the agent for the colony.

Statistics Tracked

The following statistics are tracked for this transaction:


Table 215. Publish Negotiation Results Statistics
Statistic Name Description
NumNegotiationsProcessed Number of negotiations processed.
NumNegotiationsPublished Number of negotiations published.

Pending Job Count

For this transaction the pending job count is the number of records available to be
processed by the transaction with the AVAILABLE_DATE value less than or equal
to (<=) the current date value in the YFS_Task_Q table.

Events Raised

The following events are raised by this time-triggered transaction:


Table 216. Events Raised by Publish Negotiation Results Transaction
Template
Base Transaction Raised when... Key Data Data Published Support?
PUBLISH_ORD On success Negotiation_dbd YCP_get Yes *
_NEGOTIATION/ .txt Negotiation
ON_SUCCESS Details_output.
xml

412 Sterling Selling and Fulfillment Foundation: Application Platform Configuration Guide
Table 216. Events Raised by Publish Negotiation Results Transaction (continued)
Template
Base Transaction Raised when... Key Data Data Published Support?
RECEIVE_ORD On success, when Number of receiveOrder No
_NEGOTIATION/ DocumentType is concurrent time- Negotiation_dbd.
ON_SUCCESS 0001, EntityType triggered txt
is ORDER. transactions
running.
* Note: Template used for this event is the same template used by the
getNegotiationDetails() API to form the output XML.

Release
This transaction releases orders to specific ship nodes, making sure that the
scheduled ship nodes have enough inventory to process the order.

This transaction should be invoked after the scheduling process.

For more details, see the information provided under the releaseOrder() API in
the Sterling Selling and Fulfillment Foundation: Javadocs.

If you run the combined ‘Schedule and Release' agent, do not also run the
individual Schedule or the individual Release agents.

Attributes

The following are the attributes for this time-triggered transaction:


Table 217. Release Attributes
Attribute Value
Base Transaction ID RELEASE
Base Document Type Order
Base Process Type Order Fulfillment
APIs Called releaseOrder()

Criteria Parameters

The following are the criteria parameters for this transaction:


Table 218. Release Criteria Parameters
Parameter Description
Action Required. Triggers the transaction. If left blank, it defaults to
Get, the only valid value.
Number of Records To Optional. Number of records to retrieve and process at one
Buffer time. If left blank or specified as 0 (zero), it defaults to 5000.
IgnoreReleaseDate Optional. Determines whether the schedule process should
ignore line release date criteria. Valid values are:
v Y - Releases line quantities regardless of release date criteria
v N - Default value. Releases line quantities only after release
date criteria have been met.

Chapter 22. Time-Triggered Transaction Reference 413


Table 218. Release Criteria Parameters (continued)
Parameter Description
CheckInventory Optional. Determine whether inventory should be checked.
Valid values are:
v Y - Default value. Inventory needs to be checked.
v N - Inventory does not need to be checked.
Next Task Queue Interval Optional. Specifies in hours how long a failed task should be
suspended before it is considered for reprocessing. Defaults to
5 hours.
ColonyID Required in a multischema deployment where a table may
exist in multiple schemas. Runs the agent for the colony.

Statistics Tracked

The following statistics are tracked for this transaction:


Table 219. Release Criteria Statistics
Statistic Name Description
NumFutureDateFailures Number of orders did not attempt to release
because of future date failures.
NumOrdersAttempted Number of orders attempted to release.
NumOrdersCannotBeProcessed Number of orders did not attempt to release
Failures because of cannot be processed failures.
NumOrdersProcessed Number of orders processed.
NumOrdersReleased Number of orders released.
NumOrdersBackordered Number of orders backordered.
NumOrderLinesReleased Number of order lines released.
NumOrderLinesBackordered Number of order lines backordered.
NumReleasesCreated Number of order releases created.
NumOrdersCannotBeProcessed Number of orders that were not released due to
Failures process failure.

If the release process results in splitting of an order line, NumOrderLinesReleased,


NumOrderLinesBackordered, and NumOfReleasesCreated may result in more than
one count.

Pending Job Count

For this transaction the pending job count is the number of records available to be
processed by the transaction with the AVAILABLE_DATE value less than or equal
to (<=) the current date value in the YFS_Task_Q table, if tasks on hold are not
ready to be processed.

Events Raised

This transaction raises events as specified under the releaseOrder() API in the
Sterling Selling and Fulfillment Foundation: Javadocs.

414 Sterling Selling and Fulfillment Foundation: Application Platform Configuration Guide
Route Shipment
This time-triggered transaction is used to route shipments and belongs to the
Outbound Shipment pipeline. It assigns the Carrier and Carrier Service codes for
the shipment based on the Routing Guide configured.

The Route Shipment transaction either includes shipments in an existing load or


creates a new load and includes the shipments in it.

Shipments can be consolidated to a load, only if the following conditions are met:
v Expected Ship Date - The expected ship date of the shipments must be less than
or equal to the must ship before date of the load.
v Expected Load Departure Date - The expected load departure date must be less
than or equal to the must ship before date of the shipments in the load.
The must ship before date is a date computed for the load, based on all
shipments present in the load. For example, if a load has three shipments with
their must ship before dates as 12.22.2005, 12.12.2005, and 12.19.2005 respectively,
then the must ship before date of the load is computed as 12.12.2005, as it is the
earliest of the three dates.

Attributes

The following are the attributes for this time-triggered transaction:


Table 220. Route Shipment
Attribute Value
Base Transaction ID ROUTE_SHIPMENT.0001
Base Document Type Order
Base Process Type ORDER_DELIVERY
Abstract Transaction No
APIs Called None
User Exits Called com.yantra.ydm.japi.ue.YDMOverrideDetermineRoutingUE
com.yantra.ydm.japi.ue.YDMBeforeDetermineRoutingUE

Criteria Parameters
The following are the criteria parameters for this transaction:
Table 221. Route Shipment Criteria Parameters
Parameter Description
Action Required. Triggers the transaction. If left blank, it defaults to
Get, the only valid value.
Number of Records To Optional. Number of records to retrieve and process at one
Buffer time. If left blank or specified as 0 (zero), it defaults to 5000.
Next Task Queue Interval Optional. Specifies in hours how long a failed task should be
suspended before it is considered for reprocessing. Defaults to
5 hours.
ColonyID Required in a multischema deployment where
YFS_SHIPMENT table may exist in multiple schemas. Runs
the agent for the colony.

Chapter 22. Time-Triggered Transaction Reference 415


Table 221. Route Shipment Criteria Parameters (continued)
Parameter Description
CollectPendingJobs If this parameter is set to N, the agent does not collect
information on the pending jobs for this monitor. This pending
job information is used for monitoring the monitor in the
System Management Console.

Statistics Tracked

The following statistics are tracked for this transaction:


Table 222. Route Shipment Statistics
Statistic Name Description
NumRouted Number of shipments routed.

Pending Job Count

For this transaction the pending job count is the number of records representing
the unheld orders that are available to be processed by the transaction with the
AVAILABLE_DATE value less than or equal to (<=) the current date value in the
YFS_Task_Q table.

Events Raised

The following events are raised by this time-triggered transaction:


Table 223. Events Raised by the Route Shipment Transaction
Template
Transaction/Event Key Data Data Published Support?
ON_SUCCESS shipment_dbd.txt YDM_ROUTE_SHIPMENT Yes
.ON_SUCCESS.xml
ON_FAILURE shipment_dbd.txt YDM_ROUTE_SHIPMENT Yes
.ON_FAILURE.xml

However, note that the template name would read


<TransactionId>.ON_SUCCESS.xml.

Schedule
This transaction schedules orders to specific ship nodes making sure that the
scheduled ship nodes have enough inventory to process the order.

Run this transaction after order creation.

Do not run the individual Schedule or Release agents when running the combined
"Schedule and Release" agent.

416 Sterling Selling and Fulfillment Foundation: Application Platform Configuration Guide
Attributes

The following are the attributes for this time-triggered transaction:


Table 224. Schedule Attributes
Attribute Value
Base Transaction ID SCHEDULE
Base Document Type Order
Base Process Type Order Fulfillment
APIs Called scheduleOrder()

Criteria Parameters

The following are the criteria parameters for this transaction:


Table 225. Schedule Criteria Parameters
Parameter Description
Action Required. Triggers the transaction. If left blank, it defaults to
Get, the only valid value.
Number of Records To Optional. Number of records to retrieve and process at one
Buffer time. If left blank or specified as 0 (zero), it defaults to 5000.
MaximumRecords Determines the maximum number of possible solutions that
the Schedule Agent can find. This parameter may improve the
best solution found, but it also impacts the performance of this
agent.

If left blank or specified as 0 (zero), it defaults to 5.


OptimizationType Optional. Determines the optimization rules to apply to the
scheduling process. Valid values are:
v 01 - Optimize on date (Default)
v 02 - Optimize on ship node priority
v 03 - Optimize on number of shipments
OrderFilter Optional. Determines the types of orders to filter. Possible
values are:
v A - All orders (Default)
v B - Backorders only
v N - New orders only
ScheduleAndRelease Optional. Notify the schedule process to release all releasable
line quantities. Valid values are:
v Y - Releases successfully scheduled line quantities.
v N - Default value. Only schedules line quantities.

Enabling this parameter does not validate hold types


configured for the release transaction.
IgnoreReleaseDate Optional. Determines whether the schedule process should
ignore line release date criteria. Valid values are:
v Y - Releases line quantities regardless of release date criteria.
v N - Releases lines quantities only after release date criteria
have been met. Default.

Chapter 22. Time-Triggered Transaction Reference 417


Table 225. Schedule Criteria Parameters (continued)
Parameter Description
Next Task Queue Interval Not used. This agent updates a failed task so that it is
suspended for the back order retry interval setup in the
appropriately scheduled rule.
ColonyID Required in a multischema deployment where a table may
exist in multiple schemas. Runs the agent for the colony.

Statistics Tracked

The following statistics are tracked for this transaction:


Table 226. Schedule Statistics
Statistic Name Description
NumFutureDateFailures Number of orders that Sterling Selling and
Fulfillment Foundation did not attempt to schedule
because of future date failures.

Failures can be caused by any of the following:


v If the OrderFilter is “B” (Backorders Only) and
there are no backordered or unscheduled lines.
v If the OrderFilter is “N” (New orders Only) and
there are some backordered or unscheduled lines.
v If order has order lines within only backordered
or unscheduled status and the status modify
timestamp is after the current time - the back
order wait period specified in the scheduling
rule.
NumOrdersAttempted Number of orders attempted to schedule. This
statistic does not include the values for
NumFutureDateFailures and
NumOrdersCannotBeProcessedFailures statistics.
NumOrderLinesReleased Number of order lines that have been released.
NumOrdersCannotBeProcessed Number of orders that Sterling Selling and
Failures Fulfillment Foundation did not attempt to schedule
because of cannot be processed failures.

Failures can be caused by any of the following:


v The result of the
YFSCheckOrderBeforeProcessingUE user exit
returns as false.
v The Order has the HoldFlag attribute set to ‘Y'.
v The Order has the SaleVoided attribute set to ‘Y'.
v The Order does not have PaymentStatus as
AUTHORIZED, INVOICED, PAID, nor
NOT_APPLICABLE.
NumOrdersCreated Number of orders created. This also includes the
number of procurement orders created.
NumOrderLinesCreated Number of order lines created.
NumOrdersProcessed Number of orders processed.

418 Sterling Selling and Fulfillment Foundation: Application Platform Configuration Guide
Table 226. Schedule Statistics (continued)
Statistic Name Description
NumOrdersScheduled Number of orders that have at least one line that
was scheduled.

This includes scheduled lines in any status except


BACKORDER.
NumOrdersProcOrdersCreated Number of procurement orders created.
NumWorkOrdersCreated Number of work orders created.
NumOrdersBackordered Number of orders backordered.
NumOrderLinesScheduled Number of order lines scheduled.
NumOrderLinesBackordered Number of order lines backordered.
NumReleasesCreated Number of order releases created.

Pending Job Count

For this transaction the pending job count is the number of records representing
the unheld orders that are available to be processed by the transaction with the
AVAILABLE_DATE value less than or equal to (<=) the current date value in the
YFS_Task_Q table, if tasks on hold are not ready to be processed.

Events Raised

This transaction raises events as specified under the scheduleOrder() API in the
Sterling Selling and Fulfillment Foundation: Javadocs.

Providing Oracle Hints

You can provide Oracle Hints to increase the performance of the scheduleOrder
agent. The two hints that can be provided for each criteria ID of the scheduleOrder
agent are the Outer Hint and the Inner Hint. The Outer Hint is always used for the
YFS_TASK_Q table. The Inner Hint is used for the YFS_ORDER_HEADER table
only if the earlier hold functionality is used; otherwise, the Inner Hint is used for
the YFS_ORDER_RELEASE_STATUS table.

Insert the following entries in the yfs.properties file in order to enable Oracle
Hints:
1. Edit the <INSTALL_DIR>/properties/yfs.properties file.
2. Insert yfs.<agent_criteria_id>.getjobs.hint.outer=/*+ parallel(YFS_TASK_Q
8) full(yfs_task_q) */
Insert yfs.<agent_criteria_id>.getjobs.hint.inner=/*+ NL_SJ */

Send Invoice
This transaction publishes invoice data that can be directed to an external accounts
receivable system.

In environments that require an interface with accounts receivable systems, this


transaction needs to be scheduled. This transaction raises an event for an invoice
based on the following configuration at the following times in the order lifecycle:

Chapter 22. Time-Triggered Transaction Reference 419


v Publish invoice at shipment creation - This implies that your accounts payable
system takes care of payment collection. Invoices can be published as soon as
they are created.
v Publish invoice after payment collection - This implies that the Console take care
of the payment collection. When payment is in the AT_COLLECT status and the
payment is not from an external system, an invoice is published only if the
entire payment amount is collected. If the payment is in the AT_CREATE status
or the payment is from an external system, the invoice is published
unconditionally.

Many of this transaction's elements and attributes are template driven. Refer to the
XML for element level details.

Attributes

The following are the attributes for this time-triggered transaction:


Table 227. Send Invoice Attributes
Attribute Value
Base Transaction ID SEND_INVOICE
Base Document Type Order
Base Process Type Order Fulfillment
Abstract Transaction No
APIs Called getOrderInvoiceDetails()

Criteria Parameters

The following are the criteria parameters for this transaction:


Table 228. Send Invoice Criteria Parameters
Parameter Description
Action Required. Triggers the transaction. If left blank, it defaults to
Get, the only valid value.
Number of Records To Optional. Number of records to retrieve and process at one
Buffer time. If left blank or specified as 0 (zero), it defaults to 5000.
ColonyID Required in a multischema deployment where a table may
exist in multiple schemas. Runs the agent for the colony.

Statistics Tracked

The following statistics are tracked for this transaction:


Table 229. Send Invoice Statistics
Statistic Name Description
NumInvoicesSent Number of invoices sent.

Pending Job Count

For this transaction the pending job count is the number of order invoices in
created (“00”) status.

420 Sterling Selling and Fulfillment Foundation: Application Platform Configuration Guide
Events Raised

The following events are raised by this time-triggered transaction:


Table 230. Events Raised by the Send Invoice Transaction
Template
Transaction/Event Key Data Data Published Support?
PUBLISH_INVOICE_ modifyOrder_dbd. YFS_getOrderInvoice Yes
DETAIL txt and Details_output.xml
sendInvoice_dbd
.txt

Additional events may be raised by the getOrderInvoiceDetails() API. For


detailed information about the events, see the details provided under this API in
the Sterling Selling and Fulfillment Foundation: Javadocs.

Send Item Changes


In integrated environments, this transaction publishes item data changes that are
directed to an external system.

When item changes occur in Sterling Selling and Fulfillment Foundation, they need
to be communicated to the external system.

The business process may require the synchronization of items all at once in a
batch. For example, at the end of each business day, the sendItemChanges agent
can be configured to synchronize items based on the synchronization logic. This
transaction retrieves all items that are not logical kit or dynamic physical kit items
and whose SyncTS is null or MaxModifyTS is greater than the SyncTS.

The MaxModifyTS of an item is updated with the current timestamp whenever an


item is modified. The transaction then retrieves detailed information about those
items and raises the ON_SUCCESS event. This event should be configured to
invoke the Send Item Changes action.

For more information about how this integration is implemented, see the Sterling
Selling and Fulfillment Foundation: Integration Guide.

Attributes

The following are the attributes for this time-triggered transaction:


Table 231. Send Item Changes Attributes
Attribute Value
Base Transaction ID SEND_ITEM_CHANGES
Base Document Type None
Base Process Type General
Abstract Transaction No
APIs Called None

Chapter 22. Time-Triggered Transaction Reference 421


Criteria Parameters

The following are the criteria parameters for this transaction:


Table 232. Send Item Changes Criteria Parameters
Parameter Description
Action Required. Triggers the transaction. If left blank, it defaults to
Get, the only valid value.
Number of Records To Optional. Number of records to retrieve and process at one
Buffer time. If left blank or specified as 0 (zero), it defaults to 5000.
Organization Code Optional. The organization from which items are
synchronized. This field is blank by default.
ColonyID Required in a multischema deployment where a table may
exist in multiple schemas. Runs the agent for the colony.

Statistics Tracked

None.

Pending Job Count

For this transaction the pending job count is the number of items requiring
synchronization. This is determined for product items that are not logical kit or
dynamic physical kit items and whose SyncTS is null or MaxModifyTS is greater
than the SyncTS.

Events Raised

The following events are raised by this time-triggered transaction:


Table 233. Events Raised by the Send Item Changes Transaction
Template
Transaction/Event Key Data Data Published Support?
ON_SUCCESS None YCM_SEND_ITEM_ Yes
CHANGES_ON_
SUCCESS.XML

Send Customer Changes


In integrated environments, this transaction publishes customer data changes that
are directed to an external system.

When customer changes occur in Sterling Selling and Fulfillment Foundation, they
need to be communicated to the external system.

The business process may require the synchronization of customers all at once in a
batch. For example, at the end of each business day, the sendItemChanges agent
can be configured to synchronize items based on the synchronization logic. This
transaction retrieves all customers that are consumers, have a user ID present, and
are required to synchronize. This transaction can also be used to complete the
initial synchronization of users between the two systems. For example, if an

422 Sterling Selling and Fulfillment Foundation: Application Platform Configuration Guide
external system is already in place, and Sterling Selling and Fulfillment Foundation
is then added, the SendCustomerChanges agent synchronizes the users from the
external system.

The sendCustomerChanges agent also serves as a backup mechanism. If a


customer synchronization event fails, the agent automatically retries the
synchronization after a specified amount of time.

The MaxModifyTS of an customer is updated with the current timestamp


whenever an customer is modified, whenever syncTS is less than MaxModifyTS, or
when syncTS is null. The transaction then retrieves detailed information about
those customers and raises the ON_SUCCESS event. This event should be
configured to invoke the Send Customer Changes action.

For more information about how this integration is implemented, see the Sterling
Selling and Fulfillment Foundation: Integration Guide.

Attributes
The following are the attributes for this time-triggered transaction:
Table 234. Send Customer Changes Attributes
Attribute Value
Base Transaction ID SEND_CUSTOMER_CHANGES
Base Document Type None
Base Process Type General
Abstract Transaction No
APIs Called None

Criteria Parameters

The following are the criteria parameters for this transaction:


Table 235. Send Customer Changes Criteria Parameters
Parameter Description
Action Required. Triggers the transaction. If left blank, it defaults to
Get, the only valid value.
Number of Records To Optional. Number of records to retrieve and process at one
Buffer time. If left blank or specified as 0 (zero), it defaults to 5000.
Organization Code Optional. The organization from which customers are
synchronized. This field is blank by default.
ColonyID Required in a multischema deployment where a table may
exist in multiple schemas. Runs the agent for the colony.

Statistics Tracked

None.

Pending Job Count

For this transaction the pending job count is the number of customers requiring
synchronization. This is determined for customers that are consumers, have a user

Chapter 22. Time-Triggered Transaction Reference 423


ID present, and are required to synchronize.

Events Raised

The following events are raised by this time-triggered transaction:


Table 236. Events Raised by the Send Customer Changes Transaction
Template
Transaction/Event Key Data Data Published Support?
SEND_CUSTOMER_ None YSC_SEND_CUSTOMER Yes
CHANGES.ON_SUCCESS _CHANGES.ON_
SUCCESS.XML

Send Order
This transaction tries to raise the ON_SUCCESS event for an order whose
OrderHeaderKey is stored in the task queue object. The event is raised only if all
of the order lines of the order reach particular status(es) completely. That is, the
entire ORDERED_QTY of each line must be in the particular status(es). In addition
to raising the event, the line statuses are also changed to the drop statuses,
corresponding to the pickup statuses. The SendOrder transaction, derived from the
abstract transaction SEND_ORDER, should have the event, pickup, and drop
statuses configured. For more information, see the details provided under the
sendOrder() API in the Sterling Selling and Fulfillment Foundation: Javadocs.

If an order needs to be communicated to a third party, use this transaction.

The TransactionKey posted in the task object must be an instance of the Abstract
Transaction SEND_ORDER for the ProcessType associated with the Order.
Otherwise, an exception is thrown.

Attributes

The following are the attributes for this time-triggered transaction:


Table 237. Send Order Attributes
Attribute Value
Base Transaction ID SEND_ORDER
Base Document Type Order
Base Process Type Order Fulfillment
Abstract Transaction Yes
APIs Called sendOrder()

Criteria Parameters

The following are the criteria parameters for this transaction:


Table 238. Send Order Criteria Parameters
Parameter Description
Action Required. Triggers the transaction. If left blank, it defaults to
Get, the only valid value.

424 Sterling Selling and Fulfillment Foundation: Application Platform Configuration Guide
Table 238. Send Order Criteria Parameters (continued)
Parameter Description
Number of Records To Optional. Number of records to retrieve and process at one
Buffer time. If left blank or specified as 0 (zero), it defaults to 5000.
Next Task Queue Interval Optional. Specifies in hours how long a failed task should be
suspended before it is considered for reprocessing. Defaults to
5 hours.
ColonyID Required in a multischema deployment where a table may
exist in multiple schemas. Runs the agent for the colony.

Statistics Tracked

None.

Pending Job Count


For this transaction the pending job count is the number of records available to be
processed by the transaction with the AVAILABLE_DATE value less than or equal
to (<=) the current date value in the YFS_Task_Q table.

Events Raised

This transaction raises events as specified under the sendOrder() API in the
Sterling Selling and Fulfillment Foundation: Javadocs.

Send Release
The Send Release Agent dispatches releases to ship nodes.

Attributes

The following are the attributes for this time-triggered transaction:


Table 239. Send Release Attributes
Attribute Value
Transaction Name Send Release
Transaction ID SHIP_ADVICE
Base Process Type Order Fulfillment
Abstract Transaction No
APIs Called com.yantra.yfs.agent.YFSWMSShipAdviceAgent

Criteria Parameters

The following are the criteria parameters for this transaction:


Table 240. Send Release Criteria Parameters
Parameter Description
Action Required. Triggers the transaction. If left blank, it defaults to
Get, the only valid value.

Chapter 22. Time-Triggered Transaction Reference 425


Table 240. Send Release Criteria Parameters (continued)
Parameter Description
Number of Records To Optional. Number of records to retrieve and process at one
Buffer time. If left blank or specified as 0 (zero), it defaults to 5000.
Next Task Queue Interval Optional. Specifies in hours how long a failed task should be
suspended before it is considered for reprocessing. Defaults to
5 hours.
ColonyID Required in a multischema deployment where a table may
exist in multiple schemas. Runs the agent for the colony.

Statistics Tracked

The following statistics are tracked for this transaction:


Table 241. Send Release Statistics
Statistic Name Description
NumReleasesProcessed Number of order releases processed.
NumReleasesSent Number of order releases sent.

Pending Job Count

For this transaction the pending job count is the number of records available to be
processed by the transaction with the AVAILABLE_DATE value less than or equal
to (<=) the current date value in the YFS_Task_Q table.

Events Raised

The following events are raised by this time-triggered transaction:


Table 242. Events Raised by the Send Release Transaction
Transaction/Event Data Published
PUBLISH_SHIP_ADVICE YFS_publishShipAdvice_output.xml

Start Order Negotiation


This transaction creates the negotiations for orders that are configured to go
through the negotiation process.

Use this transaction in environments where an Order needs to go through a


Negotiation phase before it is released.

Attributes

The following are the attributes for this time-triggered transaction:


Table 243. Start Order Negotiation Attributes
Attribute Value
Base Transaction ID START_ORD_NEGOTIATION
Base Document Type Order
Base Process Type Order Fulfillment

426 Sterling Selling and Fulfillment Foundation: Application Platform Configuration Guide
Table 243. Start Order Negotiation Attributes (continued)
Attribute Value
Abstract Transaction No
APIs Called createNegotiation()
User Exits Called YCPBeforeCreateNegotiationUE, YCPGetNegotiationNoUE

Criteria Parameters

The following are the criteria parameters for this transaction:


Table 244. Start Order Negotiation Criteria Parameters
Parameter Description
Action Required. Triggers the transaction. If left blank, it defaults to
Get, the only valid value.
Number of Records To Optional. Number of records to retrieve and process at one
Buffer time. If left blank or specified as 0 (zero), it defaults to 5000.
Next Task Queue Interval Optional. Specifies in hours how long a failed task should be
suspended before it is considered for reprocessing. Defaults to
5 hours.
Node Required. The warehouse management ship node for which
records are being processed.
ColonyID Required in a multischema deployment where a table may
exist in multiple schemas. Runs the agent for the colony.

Statistics Tracked

The following statistics are tracked for this transaction:


Table 245. Start Order Negotiation Statistics
Statistic Name Description
NumOrdersProcessed Number of orders processed.
NumNegotiationsCreated Number of negotiations created.

Pending Job Count

For this transaction the pending job count is the number of records available to be
processed by the transaction with the AVAILABLE_DATE value less than or equal
to (<=) the current date value in the YFS_Task_Q table.

Events Raised

This transaction raises events as specified under the createNegotiation() API in


the Sterling Selling and Fulfillment Foundation: Javadocs.

Synchronize Colony Map


The Colony Map Synchronizer agent inserts or updates colony mappings of
organizations and users in the PLT_COLONY_MAP table. When you run the agent

Chapter 22. Time-Triggered Transaction Reference 427


for the first time, it populates this table, which is a necessary step in upgrading to
multischema mode after installing or upgrading Sterling Selling and Fulfillment
Foundation.

For more information about upgrading to multischema mode, see the .

Attributes

The following are attributes for this time-triggered transaction:


Table 246. Colony Map Synchronizer Attributes
Attribute Value
Base Transaction ID COLONY_MAP_SYNC
Base Process Type General
Abstract Transaction No

Criteria Parameters

The following are the criteria parameters for this transaction:


Table 247. Colony Map Synchronizer Criteria Parameters
Parameter Description
Action Required. Triggers the transaction. If left blank, it defaults to
Get, the only valid value.
Number of Records to Optional. Number of records to retrieve and process at one
Buffer time. If left blank or specified as 0 (zero), it defaults to 5000.
ColonyID The colony to be synchronized.

Initially, you must run the agent on the DEFAULT colony


provided by the Sterling Selling and Fulfillment Foundation
installation so that it populates the PLT_COLONY_MAP table.
After this, you can run the agent on another ColonyID.
InsertDefaultMappings If set to Y, users for which the colony cannot be determined
will be mapped to the colony for which the Colony Map
Synchronizer agent is run.

Statistics Tracked

None.

Pending Job Count

None.

Events Raised

None.

Tables Purged

None.

428 Sterling Selling and Fulfillment Foundation: Application Platform Configuration Guide
Update Best Match Region
The Update Best Match Region transaction manages the
YFS_REGION_BEST_MATCH table, which is used by Data Warehouse Analytics to
report best match region data. The best match region is defined by the following
five address attributes in person info records:
v ADDRESS_LINE6
v CITY
v STATE
v SHORT_ZIP_CODE
v COUNTRY

The agent for the Update Best Match Region transaction runs in two modes that
allow you to set up and update the YFS_REGION_BEST_MATCH table.

Attributes

The following are the attributes for this time-triggered transaction:


Table 248. Update Best Match Region Attributes
Attribute Value
Base Transaction ID UPDATE_BEST_MATCH_REGION
Base Document Type General
Base Process Type General
Abstract Transaction No
APIs Called None
User Exits Called YSCGetShortZipCode UE

Criteria Parameters

The following are the criteria parameters for this transaction:


Table 249. Update Best Match Region Criteria Parameters
Parameter Description
Action Required. Triggers the transaction. If left blank, it defaults to
Get, the only valid value.
Number of Records To Optional. Number of records to retrieve and process at one
Buffer time. If UpdateOnly = N, only distinct records are returned
per agent call. If left blank, it defaults to 1000.

Chapter 22. Time-Triggered Transaction Reference 429


Table 249. Update Best Match Region Criteria Parameters (continued)
Parameter Description
TableType Required in a multischema deployment when YFS_Person_Info
table may exist in multiple schemas.

Valid Values: CONFIGURATION, TRANSACTION, MASTER.

If set to CONFIGURATION, the agent runs for the


YFS_Person_Info records associated with tables that have
TableType as CONFIGURATION; for example,
YFS_Organization, YFS_Ship_Node, and so forth.

If set to TRANSACTION, the agent runs for the


YFS_Person_Info records associated with tables that have
TableType as TRANSACTION; for example,
YFS_Order_Header, YFS_Shipment, and so forth.

Note that the agent would run for all TableTypes that exist in
the same schema as the one passed. For example, if set to
TRANSACTION, the agent would also run for
YFS_Person_Info records associated with tables that have
TableType as MASTER, since they reside in the same schema.
ColonyID Required in a multi schema deployment where the
YFS_PERSON_INFO table may exist in multiple schemas.
Runs the agent for the colony.
UpdateOnly Mode in which to run. Valid values are:
v N - Default value. Adds records from the
YFS_PERSON_INFO table to the
YFS_REGION_BEST_MATCH table and populates the
region key in the YFS_BEST_MATCH table. To perform the
initial setup of Best Match Region for Analytics, set
UpdateOnly to N.
v Y - Update mode. Updates region keys based on addresses
in YFS_REGION_BEST_MATCH. After performing the initial
setup of Best Match Region for Analytics, set this value to Y
to specify update mode.
LastPersonInfoKey Optional. If UpdateOnly is set to N, LastPersonInfoKey
determines the first person info record to populate. If no key is
specified, the value defaults to Null.
LastRegionBest Optional. If UpdateOnly is set to Y, LastRegionBestMatchKey
MatchKey determines the first region best match key to update. If no key
is specified, the value defaults to Null.

Statistics Tracked

None.

Pending Job Count

None.

Events Raised

None.

430 Sterling Selling and Fulfillment Foundation: Application Platform Configuration Guide
Tables Purged

None.

PopulateOwnershipTransferSummary
This method updates the YFS_OWNERSHIP_TRANSFER_SUMMARY table.

This transaction updates the YFS_OWNERSHIP_TRANSFER_SUMMARY table by


checking the records in YFS_INV_OWN_TRANSFER_RCD table.

It also updates the IS_STATISTICS_UPDATED to 'Y' in


YFS_INV_OWN_TRANSFER_RCD table after the record has been used by the
transaction.

Attributes
Following are the attributes for this time-triggered transaction:
Table 250. YFSPopulateOwnershipTransfer Attributes
Attribute Value
Base Transaction ID POPULATE_OWN_TRANS_SUMM
Base Document Type General
Base Process Type General
Abstract Transaction No
APIs Called None

Criteria Parameters

Following are the criteria parameters for this transaction:


Table 251. YFSPopulateOwnershipTransfer Criteria Parameters
Parameter Description
Action Required. Triggers the transaction. If left blank, it defaults to
Get, which is the only valid value.
Number of Records To Optional. Number of records to retrieve and process at one
Buffer time. If left blank or specified as 0 (zero), it defaults to 5000.
ColonyID Required in a multi schema deployment where the
YFS_OWNERSHIP_TRANSFER_SUMMARY and
YFS_INV_OWN_TRANSFER_RCD tables may exist in multiple
schemas. Runs the agent for the colony.

Statistics Tracked

None

Pending Job Count

None

Events Raised

Chapter 22. Time-Triggered Transaction Reference 431


None

Time-Triggered Purge Transactions


There are several transactions that you can use to purge your database tables at
specific time intervals.

Purge transactions determine when a table should be purged by determining the


current date and subtracting the retention days specified by the purge. If the
timestamp on the table is less than or equal to (current day - retention days) the
table is purged.

In some cases, a purge may look at another field other than the table's timestamp.
These are pointed out in the documentation.

When an entity is being purged, the related or dependent information that is


present in other tables should be taken into consideration for purging along with
it. For example, if a with live shipments is being purged, any cross reference to
that order is not accurate in the Order Shipment Console.

Some of the statistics collected and tracked in Release 9.1 for time-triggered
transactions, monitors, and integration and application servers may change with
the next release of Sterling Selling and Fulfillment FoundationSterling Application
Platform.

All Time-Triggered Purge Transactions have a CollectPendingJobs criteria


parameter. If this parameter is set to N, the agent does not collect information on
the pending jobs for that time-triggered transaction. This pending job information
is used for monitoring the monitor in the System Management ConsolePlatform
System Management and Administration Guide.

By default, CollectPendingJobs is set to Y. It can be helpful to set it to N if one


particular time-triggered transaction is performing a significant amount of
getPendingJobs queries, and the overhead cost is too high.

Purge Strategy
The following recommendations should be taken into consideration when planning
a purge strategy for each purge transaction:
v Test purges by setting Live to ’N’.
v Turn on logging to test what is purged.
v Set up purge traces in the System Management Console and analyze the
information.

Configuring Purge Transaction Log Files


About this task

You can configure purges to write log files to a directory you specify. Each time
you run a particular purge, new data is appended to this file. If no file exists, one
is created.

To specify a purge log file directory:

432 Sterling Selling and Fulfillment Foundation: Application Platform Configuration Guide
Procedure
1. Configure the yfs.purge.path property in the <INSTALL_DIR>/properties/
customer_overrides.properties file. For example, on UNIX you might specify
the log files to be written to the /app/yfs/logs/purges directory.
For additional information about overriding properties using the
customer_overrides.properties file, see the Sterling Selling and Fulfillment
Foundation: Properties Guide.
2. Run the <INSTALL_DIR>/bin/setupfiles.sh script on UNIX, or the
<INSTALL_DIR>/bin/setupfiles.cmd script on Windows.

Available Purges
This section contains details of all purge transactions in alphabetical order.

Access Token Purge


This purge removes access tokens from the system. If all of the following
conditions are met, the PLT_ACCESS_TOKEN table is picked up for purge:
v The access token is expired or is in inactive state.
v The last modified date is earlier than or equal to the current date minus the
purge criteria's retention days.

Attributes

The following are the attributes for this time-triggered transaction:


Table 252. Access Token Purge Attributes
Attribute Value
Base Transaction ID ACCESSTOKPRG
Base Document Type General
Base Process Type General
Abstract Transaction No
APIs Called None
User Exits Called None

Criteria Parameters

The following are the criteria parameters for this transaction:


Table 253. Access Token Purge Criteria Parameters
Parameter Description
Action Required. Triggers the transaction. If left blank, it defaults to
Get, the only valid value.
CollectPendingJobs If this parameter is set to N, the agent does not collect
information on the pending jobs for this monitor. This pending
job information is used for monitoring the monitor in the
System Management.
Number of Records To Optional. Number of records to retrieve and process at one
Buffer time. If left blank or specified as 0 (zero), it defaults to 5000.

Chapter 22. Time-Triggered Transaction Reference 433


Table 253. Access Token Purge Criteria Parameters (continued)
Parameter Description
Live Optional. Mode in which to run. Valid values are:
v Y - Default value. Moves qualifying records from the
regular tables listed under Tables Purged to the
corresponding history tables.
v N - Test mode. Determines the rows that are moved to
history tables without actually moving them.
PurgeCode Required. Cannot be modified. Used for internal calculations,
such as determining retention days. Corresponds with the
PurgeCode used in Business Rules Purge Criteria.

Statistics Tracked

The following statistics are tracked for this transaction:


Table 254. Access Token Purge Statistics
Statistic Name Description
NumAccessTokenPurged Number of access token records purged.

Pending Job Count

For this transaction the pending job count is the number of records that can be
purged from the PLT_ACCESS_TOKEN table.

Events Raised

None.

Tables Purged

PLT_ACCESS_TOKEN

Inbox Purge
This purge removes alert data from the system. This reduces the load on frequently
accessed tables. The alert should be marked as CLOSED.

Any enterprise that uses the Application Console must schedule purge
transactions.

You can use purge codes pseudo-logic to analyze purges. If the following
conditions are met, an alert is picked up for purge:
v The alert should be in "Closed" status.
v An inactive alert should have the resolution date earlier than or equal to the
current date minus the purge criteria's retention days.
v If the alert is in "Open" status, the number of expiration days should be greater
than 0, and the modified timestamp should be less than the current date minus
the number of expiration days.

434 Sterling Selling and Fulfillment Foundation: Application Platform Configuration Guide
Attributes

The following are the attributes for this time-triggered transaction:


Table 255. Alert Console Purge Attributes
Attribute Value
Base Transaction ID INBOXPRG
Base Document Type General
Base Process Type General
Abstract Transaction No
APIs Called None
User Exits Called YFSBeforePurgeUE

Criteria Parameters

The following are the criteria parameters for this transaction:


Table 256. Alert Console Purge Criteria Parameters
Criteria Parameters Description
Action Required. Triggers the transaction. If left blank, it defaults to
Get, the only valid value.
CollectPendingJobs If this parameter is set to N, the agent does not collect
information on the pending jobs for this monitor. This
pending job information is used for monitoring the monitor
in the System Management.
Number of Records To Optional. Number of records to retrieve and process at one
Buffer time. If left blank or specified as 0 (zero), it defaults to 5000.
EnterpriseCode Optional. The organization for which the Alert Purge needs to
be run. If not passed, then all enterprises are monitored.
ExceptionsWithBlank Optional. If the parameter is set to Y, the agent purges only
EnterpriseOnly those exceptions that has blank enterprise code. In this case,
the value set for the EnterpriseCode criteria parameter is
ignored.
Live Optional. Mode in which to run. Valid values are:
v Y - Default value. Moves qualifying records from the
regular tables listed under Tables Purged to the
corresponding history tables.
v N - Test mode. Determines the rows that are moved to
history tables without actually moving them.
PurgeCode Required. Cannot be modified. Used for internal calculations,
such as determining retention days. Corresponds with the
PurgeCode used in Business Rules Purge Criteria.
ColonyID Required in a multi schema deployment where a table may
exist in multiple schemas. Runs the agent for the colony.

Chapter 22. Time-Triggered Transaction Reference 435


Statistics Tracked

The following statistics are tracked for this transaction:


Table 257. Alert Console Purge Statistics
Statistic Name Description
NumInboxPurged Number of inbox records purged.

Pending Job Count

For this transaction the pending job count is the number of records that can be
purged from the YFS_INBOX table.

Events Raised

None.

Tables Purged

YFS_INBOX

YFS_INBOX_NOTES

YFS_INBOX_AUDIT

YFS_INBOX_REFERENCES

Capacity Purge
This purge removes capacity data from the system. This reduces the load on
frequently accessed tables.

Any enterprise using the Console must schedule purge transactions.

You can use purge codes pseudo-logic to analyze purges. If the following
conditions are met, a capacity data gets picked up for purge:
v All resource pool standard capacity periods with effective to date earlier than or
equal to the current date minus the purge criteria's retention days.
v All resource pool overridden capacity with the capacity date earlier than or
equal to the current date minus the purge criteria's retention days.
v All resource pool capacity consumption with consumption date less than or
equal to the current date minus the purge criteria's retention days.
v All resource pool capacity consumption details where appointment date is
earlier than the system date minus the purge criteria's retention days (or
ManualReservationPurgeLeadDays for manually created reservations).
v All resource pool capacity consumption details where expiration date has passed
and reservation Id is not blank.

436 Sterling Selling and Fulfillment Foundation: Application Platform Configuration Guide
Attributes

The following are the attributes for this time-triggered transaction:


Table 258. Capacity Purge Attributes
Attribute Value
Base Transaction ID CAPACITYPRG
Base Document Type General
Base Process Type General
Abstract Transaction No
APIs Called None
User Exits Called YFSBeforePurgeUE

Criteria Parameters

The following are the criteria parameters for this transaction:


Table 259. Capacity Purge Criteria Parameters
Parameter Description
Action Required. Triggers the transaction. If left blank, it defaults to
Get, the only valid value.
Number of Records To Optional. Number of records to retrieve and process at one
Buffer time. If left blank or specified as 0 (zero), it defaults to 5000.
Live Optional. Mode in which to run. Valid values are:
v Y - Default value. Moves qualifying records from the
regular tables listed under Tables Purged to the
corresponding history tables.
v N - Test mode. Determines the rows that are moved to
history tables without actually moving them.
PurgeCode Required. Cannot be modified. Used for internal calculations,
such as determining retention days. Corresponds with the
PurgeCode used in Business Rules Purge Criteria.
ColonyID Required in a multi schema deployment where a table may
exist in multiple schemas. Runs the agent for the colony.

Statistics Tracked

The following statistics are tracked for this transaction:


Table 260. Capacity Purge Statistics
Statistic Name Description
NumStdCapacityPeriodsPurged Number of standard capacity periods purged.
NumCapacityOverridesPurged Number of capacity overrides purged.
NumCapacityConsumptionsPurged Number of capacity consumptions purged.

Pending Job Count

For this transaction the pending job count is the total number of records that can
be purged from the YFS_RES_POOL_STD_CAPCTY_PERD,

Chapter 22. Time-Triggered Transaction Reference 437


YFS_RES_POOL_CAPCTY_OVERRIDE, YFS_RES_POOL_CONSMPTN_DTLS and
YFS_RES_POOL_CAPCTY_CONSMPTN tables.

Events Raised

None.

Tables Purged

The YFS_RES_POOL_STD_CAPCTY_PERD table is purged when


EFFECTIVE_TO_DATE <= (CurrentDate - LeadDays)

The YFS_RES_POOL_CAPCTY_OVERRIDE table is purged when


CAPACITY_DATE <= (CurrentDate - LeadDays)

The YFS_RES_POOL_CAPCTY_CONSMPTN table is purged when


CONSUMPTION_DATE <= (CurrentDate - LeadDays), or if a manual reservation
is taken, when CONSUMPTION_DATE <= (CurrentDate - Manual Reservation
Retention Days). When this table is purged, YFS_RES_POOL_CONSMPTN_DTLS is
also purged.

The YFS_RES_POOL_CONSMPTN_DTLS table is purged when


RESERVATION_EXPIRATION_DATE <= (CurrentDate - LeadDays)

Draft Order History Purge


This purge deletes data from history tables after a specified interval, which in turn,
reduces the load on frequently accessed tables.

You can use purge codes' pseudo-logic to analyze the purges. If the following
condition is met, a draft order is picked up for history purge:
v The last modified date of the draft order exceeds the retention day period.

All the enterprise using the Console must schedule purge transactions.

For more information about Additional Purge Criteria Based on Line Type, see the
Sterling Selling and Fulfillment Foundation: Distributed Order Management
Configuration Guide.

Note: The draft order must be purged and moved to the history tables before you
purge the draft order history tables. See “Draft Order Purge” on page 441.

Sterling Selling and Fulfillment Foundation does not provide a transaction for draft
order history purges. If you are defining a transaction that purges draft order
history tables, refer to the following Criteria Parameters section for information
about the transaction criteria.

If you do not want to define your own transaction to purge draft order history
tables, you can use the Order Purge transaction and specify
DRAFTORDERHISTPRG for the PurgeCode. To configure the Order Purge
transaction for draft order history table purges, refer to “Order Purge” on page 469
for more information.

438 Sterling Selling and Fulfillment Foundation: Application Platform Configuration Guide
Criteria Parameters

The following are the criteria parameters for defining a draft order history
transaction:
Table 261. Draft Order History Purge Criteria Parameters
Parameter Description
Action Required. Triggers the transaction. If left blank, it defaults to
Get, the only valid value.
Number of Records To Optional. Number of records to retrieve and process at one
Buffer time. If left blank or specified as 0 (zero), it defaults to 5000.
EnterpriseCode Required. Enterprise for which the Draft Order History Purge
has to be run. If not passed, all the enterprises are monitored.
Live Optional. Mode in which to run. Valid values are:
v Y - Default value. Removes qualifying records from the
history tables that are listed in Tables Purged.
v N - Test mode. Determines the rows that are removed
without actually removing them.
PurgeCode Required. Set to DRAFTORDERHISTPRG. Used for internal
calculations, such as determining retention days. Corresponds
to the PurgeCode used in Business Rules Purge Criteria.
ColonyID Required in a multi schema deployment where a table may
exist in multiple schemas. Runs the agent for the colony.

Statistics Tracked

None.

Events Raised

None.

Tables Purged

YFS_ANSWER_SET_TRAN_H

YFS_ANSWER_TRAN_H

YFS_CHARGE_TRAN_DIST_H

YFS_CHARGE_TRANSACTION_H

YFS_CREDIT_CARD_TRANSACTION_H

YFS_ENTITY_ADDRESS_H

YFS_HEADER_CHARGES_H

YFS_INSTRUCTION_DETAIL_H

YFS_INVOICE_COLLECTION_H

YFS_LINE_CHARGES_H

Chapter 22. Time-Triggered Transaction Reference 439


YFS_NOTES_H

YFS_ORDER_AUDIT_DETAIL_H

YFS_ORDER_AUDIT_H

YFS_ORDER_AUDIT_LEVEL_H

YFS_ORDER_DATE_H

YFS_ORDER_HEADER_H

YFS_ORDER_HOLD_TYPE_H

YFS_ORDER_HOLD_TYPE_LOG_H

YFS_ORDER_INVOICE_DETAIL_H

YFS_ORDER_INVOICE_H

YFS_ORDER_KIT_LINE_H

YFS_ORDER_KIT_LINE_SCHEDULE_H

YFS_ORDER_LINE_H

YFS_ORDER_LINE_OPTION_H

YFS_ORDER_LINE_REQ_TAG_H

YFS_ORDER_LINE_SCHEDULE_H

YFS_ORDER_PROD_SER_ASSOC_H

YFS_ORDER_RELEASE_H

YFS_ORDER_RELEASE_STATUS_H

YFS_ORDER_SER_PROD_ITEM_H

YFS_PAYMENT_H

YFS_PROMOTION_AWARD_H

YFS_PROMOTION_H

YFS_RECEIVING_DISCREPANCY_DTL_H

YFS_RECEIVING_DISCREPANCY_H

YFS_REFERENCE_TABLE_H

YFS_TAX_BREAKUP_H

440 Sterling Selling and Fulfillment Foundation: Application Platform Configuration Guide
Draft Order Purge
This purge archives data into history tables after a specified interval, which in
turn, reduces the load on frequently accessed tables. For information about purging
draft orders from history tables, see “Draft Order History Purge” on page 438.

Sterling Selling and Fulfillment Foundation does not provide a transaction for draft
order purges. If you are defining a transaction that purges draft orders, refer to the
following Criteria Parameters section for details about the transaction criteria.

If you do not want to define your own transaction to purge draft orders, you can
use the Order Purge transaction and specify DRAFTORDERPRG for the
PurgeCode. To configure the Order Purge transaction for draft order purges, refer
to “Order Purge” on page 469 for more information.

All the enterprise using the Console must schedule purge transactions.

Draft orders are picked up by the agent for validation when the following
conditions are met:
v Draft order flag is set to Y.
v Modifyts is set for the retention date.

After the draft orders are picked up, each draft order is validated for purging
based on the following conditions:
v No eligible order release status records (records with a status larger than zero)
exist for the order.
v All the open child orders (derived, chained, return, exchange, or refund
fulfillment) for the order are already purged.

If a draft order meets the set of conditions for validation listed earlier, the agent
continues to verify the draft orders against the following criteria:
v Contains the Draft Created (1000) status, and all the extended Draft Created
statuses.
v Does not have an order release status record that does not meet the retention
days.
v The order's last modification should be before the lead time (in days) setup.
v In the case when an exchange order is part of a return order, the exchange order
should be purged from history tables before the return order is purged.
v In the case of an order line reservation, the draft order cannot be purged.
v If the Draft Order Payment Processing flag is set to N, the draft orders are
purged.
v If the Draft Order Payment Processing flag is set to Y and a charge exists on a
draft order, the draft order is not purged. However, authorizations are not
considered when validating draft orders for purge.
v For order lines, except service order lines:
– If the Seller inventory update is required, the Status Inventory Type has the
Update Seller Supply option turned on, and the Seller Supply Type is
Onhand, or blank. (The Seller Supply Type can also be a custom seller supply
type, with the Onhand Supply check box enabled.)
– If the Seller Demand Type is blank.
– If the Buyer inventory update is required, and the Buyer Supply Type is
Onhand, or blank.

Chapter 22. Time-Triggered Transaction Reference 441


Criteria Parameters

The following are the criteria parameters for defining a draft order purge
transaction:
Table 262. Draft Order Purge Criteria Parameters
Parameter Description
Action Required. Triggers the transaction. If left blank, it defaults to
Get, the only valid value.
Number of Records To Optional. Number of records to retrieve and process at one
Buffer time. If left blank or specified as 0 (zero), it defaults to 5000.
Next Task Queue Interval Optional. Specifies (in hours) how long a failed task should be
suspended before it is considered for reprocessing. Defaults to
5 hours.
EnterpriseCode Required. Enterprise for which the Draft Order Purge has to
be run. If not passed, all the enterprises are monitored.

When the EnterpriseCode is blank, the purge criteria


configured for the DEFAULT enterprise is used, and not the
purge criteria configured for the draft order's enterprise.
Live Optional. Mode in which to run. Valid values are:
v Y - Default value. Moves qualifying records from the
regular tables listed under Tables Purged, to the
corresponding history tables.
v N - Test mode. Determines the rows that are moved to
history tables without actually moving them.
PurgeCode Required. Set to DRAFTORDERPRG. Used for internal
calculations, such as determining retention days. Corresponds
to the PurgeCode used in Business Rules Purge Criteria.
ColonyID Required in a multi schema deployment where a table may
exist in multiple schemas. Runs the agent for the colony.

Statistics Tracked

None.

Events Raised

None.

Tables Purged

YFS_ACTIVITY_DEMAND

YFS_ANSWER_SET_TRAN

YFS_ANSWER_TRAN

YFS_CHARGE_TRANSACTION

YFS_CHARGE_TRAN_DIST

YFS_CREDIT_CARD_TRANSACTION

442 Sterling Selling and Fulfillment Foundation: Application Platform Configuration Guide
YFS_ENTITY_ADDRESS

YFS_HEADER_CHARGES

YFS_INSTRUCTION_DETAIL

YFS_INVOICE_COLLECTION

YFS_LINE_CHARGES

YFS_MONITOR_ALERT

YFS_NOTES

YFS_ORDER_AUDIT

YFS_ORDER_AUDIT_DETAIL

YFS_ORDER_AUDIT_LEVEL

YFS_ORDER_HEADER

YFS_ORDER_HOLD_TYPE

YFS_ORDER_HOLD_TYPE_LOG

YFS_ORDER_INVOICE

YFS_ORDER_INVOICE_DETAIL

YFS_ORDER_KIT_LINE

YFS_ORDER_KIT_LINE_SCHEDULE

YFS_ORDER_LINE

YFS_ORDER_LINE_OPTION

YFS_ORDER_LINE_REQ_TAG

YFS_ORDER_LINE_RESERVATION

YFS_ORDER_LINE_SCHEDULE

YFS_ORDER_LINE_SRC_CNTRL

YFS_ORDER_PROD_SER_ASSOC

YFS_ORDER_RELEASE

YFS_ORDER_RELEASE_STATUS

YFS_ORDER_SER_PROD_ITEM

YFS_ORDER_DATE

Chapter 22. Time-Triggered Transaction Reference 443


YFS_PAYMENT

YFS_PMNT_TRANS_ERROR

YFS_PROMOTION

YFS_PROMOTION_AWARD

YFS_RECEIVING_DISCREPANCY

YFS_RECEIVING_DISCREPANCY_DTL

YFS_REFERENCE_TABLE

YFS_TAX_BREAKUP

Delivery Plan Purge


This purge deletes delivery plans after they have completed their typical life-cycle.
All the loads and shipments that are associated with the delivery plans should
have been purged before running this purge agent.

It purges all the delivery plans that have been marked as ‘Closed' for a period
greater than the retention days specified in the criteria parameters and those that
do not have any shipments or loads. The order should have been moved to history
before the lead time (in days) setup.

Any enterprise using the Console must schedule purge transactions.

You can use purge codes pseudo-logic to analyze purges. If the following
conditions are met, a delivery plan is picked up for purge:
v The delivery plan should be in the "Closed" status.
v The delivery plan should not be associated with any load or shipment.
v All orders associated with the delivery plan should be purged.
v The last modification performed on the delivery plan should fall before the lead
time (in days) setup.

Attributes

The following are the attributes for this time-triggered transaction:


Table 263. Delivery Plan Purge Attributes
Attribute Value
Base Transaction ID DELIVERYPLANPRG
Base Document Type Load
Base Process Type Load Execution
Abstract Transaction No
APIs Called None
User Exits Called YFSBeforePurgeUE

444 Sterling Selling and Fulfillment Foundation: Application Platform Configuration Guide
Criteria Parameters

The following are the criteria parameters for this transaction:


Table 264. Delivery Plan Purge Criteria Parameters
Parameter Description
Action Required. Triggers the transaction. If left blank, it defaults to
Get, the only valid value.
Number of Records To Optional. Number of records to retrieve and process at one
Buffer time. If left blank or specified as 0 (zero), it defaults to 5000.
EnterpriseCode Optional. Enterprise for which the Delivery Plan Purge needs
to be run. If not passed, then all enterprises are monitored.
Live Optional. Mode in which to run. Valid values are:
v Y - Default value. Moves qualifying records from the
regular tables listed under Tables Purged to the
corresponding history tables.
v N - Test mode. Determines the rows that are moved to
history tables without actually moving them.
PurgeCode Required. Cannot be modified. Used for internal calculations,
such as determining retention days. Corresponds with the
PurgeCode used in Business Rules Purge Criteria.
BatchDelete Required. The method by which all records are deleted from
the table. Valid values are:
v Y - Default value. Records are deleted in batches.
v N - Records are deleted one by one.
ColonyID Required in a multi schema deployment where the
YFS_DELIVERY_PLAN table may exist in multiple schemas.
Runs the agent for the colony.

Statistics Tracked

The following statistics are tracked for this transaction:


Table 265. Delivery Plan Purge Statistics
Statistic Name Description
NumDeliveryPlansPurged Number of delivery plans purged.

Pending Job Count

For this transaction the pending job count is the number of records that can be
purged from the YFS_DELIVERY_PLAN table.

7 Events Raised

None.

Tables Purged

YFS_DELIVERY_PLAN

Chapter 22. Time-Triggered Transaction Reference 445


Export Table Purge
This purge removes export table data from the system. This reduces the load on
frequently accessed tables.

You can use purge codes pseudo-logic to analyze purges. If the following
conditions are met, the YFS_EXPORT table is picked up for purge:
v YFS_EXPORT records should be marked as processed (Status = 10).
v The last modified time should fall before the lead time (in days) setup.
This purge reads only the rules defined by the hub. Enterprise overridden rules
are not considered. This purge should be single threaded when you run it in
batch delete mode(BatchDelete=Y).

Any enterprise using the Application Console must schedule purge transactions.

Attributes

The following are the attributes for this time-triggered transaction:


Table 266. Export Table Purge Attributes
Attribute Value
Base Transaction ID EXPORTTBLPRG
Base Document Type General
Base Process Type General
Abstract Transaction No
APIs Called None
User Exits Called YFSBeforePurgeUE

Criteria Parameters

The following are the criteria parameters for this transaction:


Table 267. Export Table Purge Criteria Parameters
Parameter Description
Action Required. Triggers the transaction. If left blank, it defaults to
Get, the only valid value.
Number of Records To Optional. Number of records to retrieve and process at one
Buffer time. If left blank or specified as 0 (zero), it defaults to 5000.
Live Optional. Mode in which to run. Valid values are:
v Y - Default value. Moves qualifying records from the
regular tables listed under Tables Purged to the
corresponding history tables.
v N - Test mode. Determines the rows that are moved to
history tables without actually moving them.
BatchDelete Required. The method by which all records are deleted from
the table. Valid values are:
v Y - Records are deleted in batches.
v N - Default value. Records are deleted one by one.
PurgeCode Required. Cannot be modified. Used for internal calculations,
such as determining retention days. Corresponds with the
PurgeCode used in Business Rules Purge Criteria.

446 Sterling Selling and Fulfillment Foundation: Application Platform Configuration Guide
Table 267. Export Table Purge Criteria Parameters (continued)
Parameter Description
CollectPendingJobs If this parameter is set to "N", the agent does not collect
information on the pending jobs for this monitor. This
pending job information is used for monitoring the monitor
in the System Management ConsoleSystem Management.
ColonyID Required in a multi schema deployment where the
YFS_EXPORT table may exist in multiple schemas. Runs the
agent for the colony.

Statistics Tracked

The following statistics are tracked for this transaction:


Table 268. Export Table Purge Statistics
Statistic Name Description
NumExportsPurged Number of exports purged.

Pending Job Count

For this transaction the pending job count is the number of records that can be
purged from the YFS_Export table.

Events Raised

None.

Tables Purged

YFS_EXPORT

Import Table Purge


This purge removes import table data from the system. This reduces the load on
frequently accessed tables.

You can use purge codes pseudo-logic to analyze purges. If the following
conditions are met, the YFS_IMPORT table is picked up for purge:
v YFS_IMPORT records should be marked as processed (Status = "10").
v The "last modified time" should fall before the lead time (in days) setup.
This purge reads only the rules defined by the hub. Enterprise overridden rules
are not considered. This purge should be single threaded when you run it in
batch delete mode(BatchDelete=Y).

Any enterprise using the Console must schedule purge transactions.

Chapter 22. Time-Triggered Transaction Reference 447


Attributes

The following are the attributes for this time-triggered transaction:


Table 269. Import Table Purge Attributes
Attribute Value
Base Transaction ID IMPORTTBLPRG
Base Document Type General
Base Process Type General
Abstract Transaction No
APIs Called None
User Exits Called YFSBeforePurgeUE

Criteria Parameters

The following are the criteria parameters for this transaction:


Table 270. Import Table Purge Criteria Parameters
Parameter Description
Action Required. Triggers the transaction. If left blank, it defaults to
Get, the only valid value.
Number of Records To Optional. Number of records to retrieve and process at one
Buffer time. If left blank or specified as 0 (zero), it defaults to 5000.
Live Optional. Mode in which to run. Valid values are:
v Y - Default value. Moves qualifying records from the
regular tables listed under Tables Purged to the
corresponding history tables.
v N - Test mode. Determines the rows that are moved to
history tables without actually moving them.
BatchDelete Required. The method by which all records are deleted from
the table. Valid values are:
v Y - Records are deleted in batches.
v N - Default value. Records are deleted one by one.
PurgeCode Required. Cannot be modified. Used for internal calculations,
such as determining retention days. Corresponds with the
PurgeCode used in Business Rules Purge Criteria.
CollectPendingJobs If this parameter is set to "N", the agent does not collect
information on the pending jobs for this monitor. This
pending job information is used for monitoring the monitor
in the System Management Console[Application System
Management Console].
ColonyID Required in a multi schema deployment where the
YFS_IMPORT table may exist in multiple schemas. Runs the
agent for the colony.

448 Sterling Selling and Fulfillment Foundation: Application Platform Configuration Guide
Statistics Tracked

The following statistics are tracked for this transaction:


Table 271. Import Table Purge Statistics
Statistic Name Description
NumImportsPurged Number of import tables purged.

Pending Job Count

For this transaction the pending job count is the number of records that can be
purged from the YFS_Import table.

Events Raised

None.

Tables Purged

YFS_IMPORT

Inventory Audit Purge


This purge removes inventory audit data from the system. This reduces the load
on frequently accessed tables.

Any enterprise using the Console must schedule purge transactions.

All inventory audits of the provided organization with modify timestamp earlier
than the current date minus the purge criteria's retention days can be configured to
be picked up by the Inventory Audit Purge.

You can use purge codes pseudo-logic to analyze purges. If the following condition
is met, an inventory audit record is picked up for purge:
v The inventory audit record's last modification is earlier than the current
timestamp minus the retention days.
Number of threads for this purge's agent criteria details must be set to 1. For
more information about agent criteria, see the Sterling Selling and Fulfillment
Foundation: Application Platform Configuration Guide.
The Inventory Audit purge does not purge any records under 60 days old, even
if configured to do so.

The following are the attributes for this time-triggered transaction:


Table 272. Inventory Audit Purge Attributes
Attribute Value
Base Transaction ID INVENTORYAUDITPRG
Base Document Type General
Base Process Type General
Abstract Transaction No
APIs Called None
User Exits Called YFSBeforePurgeUE

Chapter 22. Time-Triggered Transaction Reference 449


Criteria Parameters

The following are the criteria parameters for this transaction:


Table 273. Inventory Audit Purge Criteria Parameters
Parameter Description
Action Required. Triggers the transaction. If left blank, it defaults to
Get, the only valid value.
Number of Records To Optional. Number of records to retrieve and process at one
Buffer time. If left blank or specified as 0 (zero), it defaults to 5000.
EnterpriseCode Optional. The inventory organization for which the Inventory
Audit Purge needs to be run. If not passed, then all enterprises
are monitored.
Live Optional. Mode in which to run. Valid values are:
v Y - Default value. Moves qualifying records from the
regular tables listed under Table Purged to the
corresponding history tables.
v N - Test mode. Determines the rows that are moved to
history tables without actually moving them.
PurgeCode Required. Cannot be modified. Used for internal calculations,
such as determining retention days. Corresponds with the
PurgeCode used in Business Rules Purge Criteria.
ColonyID Required in a multi schema deployment where a table may
exist in multiple schemas. Runs the agent for the colony.

Statistics Tracked

The following statistics are tracked for this transaction:


Table 274. Inventory Audit Statistics
Statistic Name Description
NumInventoryAuditsPurged Number of inventory audits purged.

Pending Job Count

For this transaction the pending job count is the number of records that can be
purged from the YFS_Inventory_Audit table.

Events Raised

None.

Table Purged

YFS_INVENTORY_AUDIT

Inventory Purge
This purge removes inventory data from the system. This reduces the load on
frequently accessed tables. This purge does not take retention days into account
when purging.

You can use purge codes pseudo-logic to analyze purges.

450 Sterling Selling and Fulfillment Foundation: Application Platform Configuration Guide
For YFS_INVENTORY_SUPPLY, if the following conditions are met, an inventory
supply is picked up for purge:
v Supply record has the same availability type as the node. For example, TRACK
or INFINITE.
v Supply record has 0 quantity.
v Supply record does not contain the supply type “INFO”.

For YFS_INVENTORY_DEMAND, if the following conditions are met, an


inventory demand is picked up for purge:
v Demand record has 0 quantity or lesser.
v Demand record does not have demand details as well as matching demand
record in YFS_INVENTORY_DEMAND_ADDNL tables.

For YFS_INVENTORY_TAG, it is purged if the INVENTORY_TAG_KEY is not


used by any of the existing supply and demand.

For YFS_INVENTORY_RESERVATION, an inventory reservation is picked up for


purge if it meets the following conditions:
v Inventory reservation record has 0 quantity or ship date is earlier than the
system date minus the purge criteria's retention days.

For YFS_INVENTORY_NODE_CONTROL, it is purged if the


INV_PIC_INCORRECT_TILL_DATE is earlier than the current time stamp minus
the purge criteria's retention days.

For YFS_IBA_TRIGGER, it is purged if IBA_REQUIRED = 'N',


IBA_RUN_REQUIRED = 'N', and LAST_IBA_PROCESSED_TS is earlier than the
current time stamp minus the purge criteria's retention days.

Any enterprise using the Console must schedule purge transactions.

Attributes

The following are the attributes for this time-triggered transaction:


Table 275. Inventory Purge Attributes
Attribute Value
Base Transaction ID INVENTORYPRG
Base Document Type General
Base Process Type General
Abstract Transaction No
APIs Called None
User Exits Called YFSBeforePurgeUE

Chapter 22. Time-Triggered Transaction Reference 451


Criteria Parameters

The following are the criteria parameters for this transaction:


Table 276. Inventory Purge Criteria Parameters
Parameter Description
Action Required. Triggers the transaction. If left blank, it defaults to
Get, the only valid value.
Number of Records To Optional. Number of records to retrieve and process at one
Buffer time. If left blank or specified as 0 (zero), it defaults to 5000.
EnterpriseCode The inventory organization for which the Inventory Purge
needs to be run.
Live Optional. Mode in which to run. Valid values are:
v Y - Default value. Moves qualifying records from the
regular tables listed under Tables Purged to the
corresponding history tables.
v N - Test mode. Determines the rows that are moved to
history tables without actually moving them.
PurgeCode Required. Cannot be modified. Used for internal calculations,
such as determining retention days. Corresponds with the
PurgeCode used in Business Rules Purge Criteria.
ColonyID Required in a multi schema deployment where a table may
exist in multiple schemas. Runs the agent for the colony.

Statistics Tracked

The following statistics are tracked for this transaction:


Table 277. Inventory Purge Statistics
Statistic Name Description
NumInventoryDemandsPurged Number of inventory demands purged.
NumInventoryNodeControlsPurged Number of inventory node controls purged.
NumInventoryReservationsPurged Number of inventory reservations purged.
NumInventoryTagsPurged Number of inventory tags purged.
NumItemBasedAllocationTriggers Number of item based allocation triggers purged.
Purged

Pending Job Count

For this transaction, the pending job count is the total number of records that can
be purged from the YFS_Inventory_Supply, YFS_Inventory_Demand,
YFS_Inventory_Tag, YFS_Inventory_Reservation, YFS_IBA_Trigger, and
YFS_Inventory_Node_Control tables.

Events Raised

None.

452 Sterling Selling and Fulfillment Foundation: Application Platform Configuration Guide
Tables Purged

YFS_IBA_TRIGGER

YFS_INVENTORY_DEMAND

YFS_INVENTORY_TAG

YFS_INVENTORY_RESERVATION

YFS_INVENTORY_SUPPLY

YFS_INVENTORY_NODE_CONTROL

Inventory Supply Temp Purge


The Inventory Supply Temp purge agent cleans up the contents in the temporary
inventory tables generated by the process of synchronizing the Sterling Selling and
Fulfillment Foundation inventory picture with the actual inventory picture at the
nodes.

The node inventory picture is stored during the loading process into the
YFS_INVENTORY_SUPPLY_TEMP table. Once the synchronization phase is
complete and the YFS_INVENTORY_SUPPLY table has been updated, the
YFS_INVENTORY_SUPPLY_TEMP table needs to be purged, which is done
through this agent.

For more information about configuring the synchronization with node inventory,
see the Sterling Selling and Fulfillment Foundation: Global Inventory Visibility
Configuration Guide.

The Inventory Supply Temp purge agent is used to purge all records in the
YFS_INVENTORY_SUPPLY_TEMP table whose modify timestamp is less then
current time minus the purge criteria's retention days for a group of
YantraMessageGroupID.

Attributes

The following are the attributes for this time-triggered transaction:


Table 278. Inventory Supply Temp Purge Attributes
Attribute Value
Base Transaction ID SUPPLYTEMPPRG
Base Document Type General
Base Process Type General
Abstract Transaction No
APIs Called None
User Exits Called None

Chapter 22. Time-Triggered Transaction Reference 453


Criteria Parameters

The following are the criteria parameters for this transaction:


Table 279. Inventory Supply Temp Purge Criteria Parameters
Parameter Description
Action Required. Triggers the transaction. If left blank, it defaults to
Get, the only valid value.
Number of Records To Optional. Number of records to retrieve and process at one
Buffer time. If left blank or specified as 0 (zero), it defaults to 5000.
Live Optional. Mode in which to run. Valid values are:
v Y - Default value. Moves qualifying records from the
regular tables listed under Tables Purged to the
corresponding history tables.
v N - Test mode. Determines the rows that are moved to
history tables without actually moving them.
EnterpriseCode Optional. The inventory organization for which the Inventory
Supply Temp Purge needs to be run. If not passed, then all
enterprises are monitored.
PurgeCode Required. Cannot be modified. Used for internal calculations,
such as determining retention days. Corresponds with the
PurgeCode used in Business Rules Purge Criteria.
ColonyID Required in a multi schema deployment where the
YFS_INVENTORY_SUPPLY_TEMP table may exist in multiple
schemas. Runs the agent for the colony.

Statistics Tracked

The following statistics are tracked for this transaction:


Table 280. Inventory Supply Temp Purge Statistics
Statistic Name Description
NumInventorySupplyTempsPurged Number of entries in the
YFS_INVENTORY_SUPPLY_TEMP table purged.

Pending Job Count

Number of unique YantraMessageGroupIDs from


YFS_INVENTORY_SUPPLY_TEMP table whose maximum modify timestamp is
less than current timestamp minus purge criteria's lead day.

Events Raised

None.

Tables Purged

YFS_INVENTORY_SUPPLY_TEMP

454 Sterling Selling and Fulfillment Foundation: Application Platform Configuration Guide
Item Audit Purge
This purge removes the YFS_AUDIT table data from the system, which reduces the
load on frequently accessed tables. It purges records in the YFS_AUDIT and the
YFS_AUDIT_HEADER tables that meet the following conditions:
v YFS_AUDIT records that have ‘modifyts' greater than the retention days
specified and the records have the table name as 'YFS_ITEM'.
v The last modified time is before the lead time (in days) setup.

When the enterprise modifies records in the YFS_ITEM table through the
Applications Manager, the YFS_ITEM is audited and the audit records are inserted
in the YFS_AUDIT table. In order to clean up the audit records, this purge
transaction can be used.

Any enterprise using the Console must schedule purge transactions accordingly.

Attributes

The following are the attributes for this time-triggered transaction:


Table 281. Item Audit Purge Attributes
Attribute Value
Base Transaction ID YFS_ITEM_AUDIT_PURGE
Base Document Type General
Base Process Type General
Abstract Transaction No
APIs Called None
User Exits Called YFSBeforePurgeUE

Criteria Parameters

The following are the criteria parameters for this transaction:


Table 282. Item Audit Purge Criteria Parameters
Parameter Description
Action Required. Triggers the transaction. If left blank, the value
defaults to Get, the only valid value.
Number of Records To Optional. Number of records to retrieve and process at one
Buffer time. If left blank or specified as 0 (zero), this value defaults
to 5000.
Live Optional. Mode in which to run. Valid values are:
v Y - Default value. Production mode. Deletes records from
the regular tables.
v N - Test mode.
PurgeCode Required. Cannot be modified. Used for internal calculations,
such as determining retention days. Corresponds with the
PurgeCode used in Business Rules Purge Criteria.
ColonyID Required in a multi schema deployment where the
YFS_AUDIT and YFS_AUDIT_HEADER tables may exist in
multiple schemas. Runs the agent for the colony.

Chapter 22. Time-Triggered Transaction Reference 455


Statistics Tracked

The following statistics are tracked for this transaction:


Table 283. Item Audit Purge Statistics
Statistic Name Description
NumItemAuditRecords Number of item audit records purged.
Purged

Pending Job Count

For this transaction, the pending job count is the number of records that can be
purged from the YFS_AUDIT table that match the criteria values.

Events Raised

None.

Tables Purged

YFS_AUDIT, YFS_AUDIT_HEADER

Load History Purge


This purge deletes the load data from history tables after it completes its typical
lifecycle. This reduces the load on frequently accessed tables.

Any enterprise using the Console must schedule purge transactions.

You can use purge codes pseudo-logic to analyze purges. If the last modification
made to the load is before the lead time (in days) is met, a load is picked up for
purge.

Before you run this transaction, ensure to purge loads and move them to history
tables. For more information about purging loads, see “Load Purge” on page 458.

Attributes

The following are the attributes for this time-triggered transaction:


Table 284. Load History Purge Attributes
Attribute Value
Base Transaction ID LOADHISTPRG
Base Document Type Load
Base Process Type Load Execution
Abstract Transaction No
APIs Called None
User Exits Called YFSBeforePurgeUE

456 Sterling Selling and Fulfillment Foundation: Application Platform Configuration Guide
Criteria Parameters

The following are the criteria parameters for this transaction:


Table 285. Load History Purge Criteria Parameters
Parameter Description
Action Required. Triggers the transaction. If left blank, it defaults to
Get, the only valid value.
Number of Records To Optional. Number of records to retrieve and process at one
Buffer time. If left blank or specified as 0 (zero), it defaults to 5000.
EnterpriseCode Optional. Enterprise for which the Load Purge needs to be
run. If not passed, all enterprises are monitored.
Live Optional. Mode in which to run. Valid values are:
v Y - Default value. Moves qualifying records from the
regular tables listed under Tables Purged to the
corresponding history tables.
v N - Test mode. Determines the rows that are moved to
history tables without actually moving them.
Purge Code Required. Cannot be modified. Used for internal calculations,
such as determining retention days. Corresponds with the
PurgeCode used in Business Rules Purge Criteria.
ColonyID Required in a multi schema deployment where a table may
exist in multiple schemas. Runs the agent for the colony.

Statistics Tracked

The following statistics are tracked for this transaction:


Table 286. Load History Purge Statistics
Statistic Name Description
NumLoadHistoriesPurged Number of load histories purged.
NumLoadShipment Number of load shipment histories purged.
HistoriesPurged

Pending Job Count

For this transaction, the pending job count is the number of records that can be
purged from the YFS_Load_H table.

Events Raised

None.

Tables Purged

YFS_LOAD_H

YFS_LOAD_STOP_H

YFS_LOAD_SHIPMENT_CHARGE_H

YFS_LOAD_STATUS_AUDIT_H

Chapter 22. Time-Triggered Transaction Reference 457


YFS_SHIPMENT_CONTAINER_H

YFS_CONTAINER_ACTIVITY_H

YFS_LOADED_CONTAINER_H

YFS_LOAD_SHIPMENT_H

YFS_ADDITIONAL_DATE_H

YFS_LOAD_HOLD_TYPE_H

YFS_LOAD_HOLD_TYPE_LOG_H

Load Purge
This purge removes load data from the system. It picks up all loads that have been
marked as ‘Closed' and purges them. Empty Loads (for example, loads with no
shipments) are not considered for purge. As a part of this purge, the associated
child tables are also purged.

This is not a pipeline transaction. It also does not work from the task queue.

Any enterprise using the Console must schedule purge transactions.

You can use purge codes pseudo-logic to analyze purges. If the following condition
is met, a load is picked up for purge:
v The Load's last modification should fall before the lead time (in days) setup.

Attributes

The following are the attributes for this time-triggered transaction:


Table 287. Load Purge Attributes
Attribute Value
Base Transaction ID LOADPRG
Base Document Type Load
Base Process Type Load Execution
Abstract Transaction No
APIs Called None
User Exits Called YFSBeforePurgeUE

Criteria Parameters

The following are the criteria parameters for this transaction:


Table 288. Load Purge Criteria Parameters
Parameter Description
Action Required. Triggers the transaction. If left blank, it defaults to
Get, the only valid value.
Number of Records To Optional. Number of records to retrieve and process at one
Buffer time. If left blank or specified as 0 (zero), it defaults to 5000.

458 Sterling Selling and Fulfillment Foundation: Application Platform Configuration Guide
Table 288. Load Purge Criteria Parameters (continued)
Parameter Description
EnterpriseCode Optional. Enterprise for which the Load Purge needs to be
run. If not passed, then all enterprises are monitored.
Live Optional. Mode in which to run. Valid values are:
v Y - Default value. Moves qualifying records from the
regular tables listed under Tables Purged to the
corresponding history tables.
v N - Test mode. Determines the rows that are moved to
history tables without actually moving them.
PurgeCode Required. Cannot be modified. Used for internal calculations,
such as determining retention days. Corresponds with the
PurgeCode used in Business Rules Purge Criteria.
ColonyID Required in a multi schema deployment where a table may
exist in multiple schemas. Runs the agent for the colony.

Statistics Tracked

The following statistics are tracked for this transaction:


Table 289. Load Purge Statistics
Statistic Name Description
NumLoadShipmentsPurged Number of load shipments purged.
NumLoadsPurged Number of loads purged.

Pending Job Count

For this transaction, the pending job count is the number of records that can be
purged from the YFS_Load table.

Events Raised

None.

Tables Purged

YFS_ADDITIONAL_DATE

YFS_LOAD

YFS_LOAD_HOLD_TYPE

YFS_LOAD_HOLD_TYPE_LOG

YFS_LOAD_STOP

YFS_LOAD_SHIPMENT

YFS_LOAD_SHIPMENT_CHARGES (charges that pertain to this load)

YFS_LOAD_STATUS_AUDIT

Chapter 22. Time-Triggered Transaction Reference 459


YFS_LOADED_CONTAINER

YFS_SHIPMENT_CONTAINER

YFS_CONTAINER_ACTIVITY

Negotiation History Purge


This purge deletes negotiation history data from the system. This reduces the load
on frequently accessed tables. It purges data from the order negotiation history
tables.

You can use purge codes pseudo-logic to analyze purges. If the following condition
is met, a negotiation is picked up for history purge:
v The last modified date of the negotiation exceeds the retention day period.

Any enterprise using the Console must schedule purge transactions.

Attributes

The following are the attributes for this time-triggered transaction:


Table 290. Negotiation History Purge Attributes
Attribute Value
Base Transaction ID NEGOTIATIONHISTPRG
Base Document Type Order
Base Process Type Order Negotiation
Abstract Transaction No
APIs Called None
User Exits Called YFSBeforePurgeUE

Criteria Parameters

The following are the criteria parameters for this transaction:


Table 291. Negotiation History Purge Criteria Parameters
Parameter Description
Action Required. Triggers the transaction. If left blank, it defaults to
Get, the only valid value.
Number of Records To Optional. Number of records to retrieve and process at one
Buffer time. If left blank or specified as 0 (zero), it defaults to 5000.
EnterpriseCode Optional. Enterprise for which the Negotiation History Purge
needs to be run. If not passed, then all enterprises are
monitored.
Live Optional. Mode in which to run. Valid values are:
v Y - Default value. Moves qualifying records from the
regular tables listed under Tables Purged to the
corresponding history tables.
v N - Test mode. Determines the rows that are moved to
history tables without actually moving them.

460 Sterling Selling and Fulfillment Foundation: Application Platform Configuration Guide
Table 291. Negotiation History Purge Criteria Parameters (continued)
Parameter Description
PurgeCode Required. Cannot be modified. Used for internal calculations,
such as determining retention days. Corresponds with the
PurgeCode used in Business Rules Purge Criteria.
ColonyID Required in a multi schema deployment where a table may
exist in multiple schemas. Runs the agent for the colony.

Statistics Tracked

The following statistics are tracked for this transaction:


Table 292. Negotiation History Purge Statistics
Statistic Name Description
NumNegotiationHistoriesPurged Number of negotiation histories purged.

Pending Job Count

For this transaction, the pending job count is the number of records that can be
purged from the YFS_Negotiation_Hdr_H table.

Events Raised

None.

Tables Purged

YFS_AUDIT

YFS_NEGOTIATION_HDR_H

YFS_NEGOTIATION_LINE_H

YFS_RESPONSE_H

YFS_RESPONSE_HDR_H

YFS_RESPONSE_LINE_H

YFS_RESPONSE_LINE_DTL_H

Negotiation Purge
This purge archives data into history tables after it completes its typical lifecycle.
This reduces the load on frequently accessed tables. It works from the task queue
(YFS_TASK_Q) table.

You can use purge codes pseudo-logic to analyze purges. If the following condition
is met, a negotiation is picked up for purge:
v The last modification performed on the negotiation falls before the lead time (in
days) setup.
v The negotiation is in pickable status.

Chapter 22. Time-Triggered Transaction Reference 461


Any enterprise using the Console must schedule purge transactions.

Attributes

The following are the attributes for this time-triggered transaction:


Table 293. Negotiation Purge Attributes
Attribute Value
Base Transaction ID ORD_NEGOTIATION_PURGE
Base Document Type Order
Base Process Type Order Negotiation
Abstract Transaction No
APIs Called None
User Exits Called YFSBeforePurgeUE

Criteria Parameters

The following are the criteria parameters for this transaction:


Table 294. Negotiation Purge Criteria Parameters
Parameter Description
Action Required. Triggers the transaction. If left blank, it defaults to
Get, the only valid value.
Number of Records To Optional. Number of records to retrieve and process at one
Buffer time. If left blank or specified as 0 (zero), it defaults to 5000.
EnterpriseCode Optional. Enterprise for which the Negotiation Purge needs to
be run. If not passed, then all enterprises are monitored.
Live Optional. Mode in which to run. Valid values are:
v Y - Default value. Moves qualifying records from the
regular tables listed under Tables Purged to the
corresponding history tables.
v N - Test mode. Determines the rows that are moved to
history tables without actually moving them.
PurgeCode Required. Cannot be modified. Used for internal calculations,
such as determining retention days. Corresponds with the
PurgeCode used in Business Rules Purge Criteria.
Next Task Queue Interval Optional. Specifies in hours how long a failed task should be
suspended before it is considered for reprocessing. Defaults to
5 hours.
ColonyID Required in a multi schema deployment where a table may
exist in multiple schemas. Runs the agent for the colony.

Statistics Tracked

The following statistics are tracked for this transaction:


Table 295. Negotiation Purge Statistics
Statistic Name Description
NumOrderNegotiationsPurged Number of order negotiations purged.

462 Sterling Selling and Fulfillment Foundation: Application Platform Configuration Guide
Pending Job Count

For this transaction, the pending job count is the number of records available to be
processed by the transaction with the AVAILABLE_DATE value less than or equal
to (<=) the current date value in the YFS_Task_Q table.

Events Raised

None

Tables Purged

YFS_AUDIT

YFS_NEGOTIATION_HDR

YFS_NEGOTIATION_LINE

YFS_RESPONSE

YFS_RESPONSE_HDR

YFS_RESPONSE_LINE

YFS_RESPONSE_LINE_DTL

Opportunity History Purge


This transaction deletes tasks previously archived by the Opportunity Purge. See
“Opportunity Purge” on page 465.

You can use purge codes pseudo-logic to analyze purges. If the following
conditions are met, an opportunity that is previously purged by the opportunity
purge agent is picked up for history purge:
v The last modified date of the opportunity should exceed the retention day
period.
v The quote history is purged.

Attributes

The following are the attributes for this time-triggered transaction:


Table 296. Opportunity History Purge Attributes
Attribute Value
Base Transaction ID OPPORTUNITYHISTPRG
Base Document Type Opportunity
Base Process Type Opportunity Fulfillment
Abstract Transaction No
APIs Called None
User Exits Called None

Chapter 22. Time-Triggered Transaction Reference 463


Criteria Parameters

The following are the criteria parameters for this transaction:


Table 297. Opportunity History Purge Criteria Parameters
Parameter Description
Action Required. Triggers the transaction. If left blank, it defaults to
Get, the only valid value.
PurgeCode Required. Cannot be modified. Used for internal calculations,
such as determining retention days. Corresponds with the
PurgeCode used in Business Rules Purge Criteria.
Live Optional. Mode in which to run. Defaults to N.
v Y - Default value. Removes qualifying records from the
history tables listed under Tables Purged.
v N- Test mode. Determines the rows that are removed
without actually removing them.
Number of Records To Optional. Number of records to retrieve and process at one
Buffer time. If left blank or specified as 0 (zero), it defaults to 5000.
EnterpriseCode Optional. Enterprise for which the Opportunity History Purge
needs to be run. If not passed, then all enterprises are
monitored.

When the EnterpriseCode is blank, the purge criteria


configured for the DEFAULT enterprise is used; not the purge
criteria configured for the opportunity's enterprise.
CollectPendingJobs If this parameter is set to "N", the agent does not collect
information on the pending jobs for this monitor. This pending
job information is used for monitoring the monitor in the
System Management Console.
ColonyID Required in a multi schema deployment where a table may
exist in multiple schemas. Runs the agent for the colony.

Statistics Tracked

The following statistics are tracked for this transaction:


Table 298. Opportunity History Purge Statistics
Statistic Name Description
NumOpportunityHistory Number of opportunity histories purged.
Purged

Pending Job Count

For this transaction, the pending job count is the number of records that can be
purged from the YFS_OPPORTUNITY_H table.

Events Raised

None.

Tables Purged

YFS_OPPORTUNITY_H

464 Sterling Selling and Fulfillment Foundation: Application Platform Configuration Guide
Opportunity Purge
This time-triggered transaction purges all the opportunities for a period greater
than the retention days specified in the Opportunity Purge criteria, and those
which are either in the status of cancelled or completed.

You can use purge codes pseudo-logic to analyze purges. If the following
conditions are met, an opportunity is picked up for purge:
v The last modified date of the opportunity should exceed the retention day
period.
v The quote associated with the opportunity should be purged.
v The opportunity should be in pickable status by the purge transaction.

Attributes

The following are the attributes for this time-triggered transaction:


Table 299. Opportunity Purge Attributes
Attribute Value
Base Transaction ID OPPORTUNITYPRG
Base Document Type Opportunity
Base Process Type Opportunity Fulfillment
Abstract Transaction No
APIs Called None
User Exits Called None

Criteria Parameters

The following are the criteria parameters for this transaction:


Table 300. Opportunity Purge Criteria Parameters
Parameter Description
Action Required. Triggers the transaction. If left blank, it defaults to
Get, the only valid value.
PurgeCode Required. Cannot be modified. Used for internal calculations,
such as determining retention days. Corresponds with the
PurgeCode used in Business Rules Purge Criteria.
Live Optional. Mode in which to run. Defaults to Y.
v Y - Default value. Moves qualifying records from the
regular tables listed under Tables Purged to the
corresponding history tables.
v N - Test mode. Determines the rows that are moved to
history tables without actually moving them.
Number of Records To Optional. Number of records to retrieve and process at one
Buffer time. If left blank or specified as 0 (zero), it defaults to 5000.
EnterpriseCode Optional. Enterprise for which the Opportunity Purge needs to
be run. If not passed, then all enterprises are monitored.

When the EnterpriseCode is blank, the purge criteria


configured for the DEFAULT enterprise is used; not the purge
criteria configured for the opportunity's enterprise.

Chapter 22. Time-Triggered Transaction Reference 465


Table 300. Opportunity Purge Criteria Parameters (continued)
Parameter Description
CollectPendingJobs If this parameter is set to "N", the agent does not collect
information on the pending jobs for this monitor. This pending
job information is used for monitoring the monitor in the
System Management Console.
ColonyID Required in a multi schema deployment where a table may
exist in multiple schemas. Runs the agent for the colony.

Statistics Tracked

The following statistics are tracked for this transaction:


Table 301. Opportunity Purge Statistics
Statistic Name Description
NumOpportunityPurged Number of opportunities purged.

Pending Job Count

For this transaction, the pending job count is the number of records that can be
purged from the YFS_OPPORTUNITY table.

Events Raised

None.

Tables Purged

YFS_OPPORTUNITY

Order History Purge


This purge deletes data from history tables after it completes its typical lifecycle.
This reduces the load on frequently accessed tables.

The order should have been purged and moved into the history tables before you
can run this transaction. For more information about this, see “Order Purge” on
page 469.

You can use purge codes pseudo-logic to analyze purges. If the following condition
is met, an order is picked up for history purge:
v The last modified date of the order exceeds the retention day period.

Any enterprise using the Console must schedule purge transactions.

For more information about Additional Purge Criteria Based on Line Type, see the
Sterling Selling and Fulfillment Foundation: Distributed Order Management
Configuration Guide.

466 Sterling Selling and Fulfillment Foundation: Application Platform Configuration Guide
Attributes

The following are the attributes for this time-triggered transaction:


Table 302. Order History Purge Attributes
Attribute Value
Base Transaction ID ORDERHISTPRG
Base Document Type Order
Base Process Type Order Fulfillment
Abstract Transaction No
APIs Called None
User Exits Called YFSBeforePurgeUE

Criteria Parameters

The following are the criteria parameters for this transaction:


Table 303. Order History Purge Criteria Parameters
Parameter Description
Action Required. Triggers the transaction. If left blank, it defaults to
Get, the only valid value.
Number of Records To Optional. Number of records to retrieve and process at one
Buffer time. If left blank or specified as 0 (zero), it defaults to 5000.
EnterpriseCode Optional. Enterprise for which the Order History Purge needs
to be run. If not passed, then all enterprises are monitored.
Live Optional. Mode in which to run. Valid values are:
v Y - Default value. Removes qualifying records from the
history tables listed under Tables Purged.
v N- Test mode. Determines the rows that are removed
without actually removing them.
PurgeCode Required. Cannot be modified. Used for internal calculations,
such as determining retention days. Corresponds with the
PurgeCode used in Business Rules Purge Criteria.
ColonyID Required in a multi schema deployment where a table may
exist in multiple schemas. Runs the agent for the colony.

Statistics Tracked

The following statistics are tracked for this transaction:


Table 304. Order History Purge Statistics
Statistic Name Description
NumOrderHistoriesPurged Number of order histories purged.

Pending Job Count

For this transaction, the pending job count is the number of records that can be
purged from the YFS_Order_HEADER_H table.

Chapter 22. Time-Triggered Transaction Reference 467


Events Raised

None.

Tables Purged

YFS_ANSWER_SET_TRAN_H

YFS_ANSWER_TRAN_H

YFS_CHARGE_TRAN_DIST_H

YFS_CHARGE_TRAN_REQUEST_H

YFS_CHARGE_TRAN_RQ_MAP_H

YFS_CHARGE_TRANSACTION_H

YFS_CREDIT_CARD_TRANSACTION_H

YFS_ENTITY_ADDRESS_H

YFS_HEADER_CHARGES_H

YFS_INSTRUCTION_DETAIL_H

YFS_INVOICE_COLLECTION_H

YFS_LINE_CHARGES_H

YFS_NOTES_H

YFS_ORDER_AUDIT_DETAIL_H

YFS_ORDER_AUDIT_H

YFS_ORDER_AUDIT_LEVEL_H

YFS_ORDER_DATE_H

YFS_ORDER_HEADER_H

YFS_ORDER_HOLD_TYPE_H

YFS_ORDER_HOLD_TYPE_LOG_H

YFS_ORDER_INVOICE_DETAIL_H

YFS_ORDER_INVOICE_H

YFS_ORDER_KIT_LINE_H

YFS_ORDER_KIT_LINE_SCHEDULE_H

YFS_ORDER_LINE_H

468 Sterling Selling and Fulfillment Foundation: Application Platform Configuration Guide
YFS_ORDER_LINE_OPTION_H

YFS_ORDER_LINE_REQ_TAG_H

YFS_ORDER_LINE_SCHEDULE_H

YFS_ORDER_PROD_SER_ASSOC_H

YFS_ORDER_RELEASE_H

YFS_ORDER_RELEASE_STATUS_H

YFS_ORDER_SER_PROD_ITEM_H

YFS_PAYMENT_H

YFS_PROMOTION_AWARD_H

YFS_PROMOTION_H

YFS_RECEIVING_DISCREPANCY_DTL_H

YFS_RECEIVING_DISCREPANCY_H

YFS_REFERENCE_TABLE_H

YFS_TAX_BREAKUP_H

YIC_BOM_HEADER_H

YIC_BOM_LINE_H

YIC_BOM_MESSAGE_H

YIC_BOM_PROP_H

Order Purge
This purge archives data into history tables after it completes its typical lifecycle.
To purge orders from history tables, see “Order History Purge” on page 466. This
reduces the load on frequently accessed tables. It works on a task queue. It picks
up the orders from YFS_TASK_Q table that are available for the transaction
PURGE.

If purge criteria are not met, AVAILABLE_DATE is calculated based on the modify
time stamp of the order in YFS_ORDER_HEADER table as well as the
YFS_TASK_Q table, whichever is maximum. To this value, retention days is added
to the new AVAILABLE_DATE.

This transaction depends on all lines of an order being in a status pickable by the
Purge transaction.

The following statuses are available for configuration to be picked up by Order


Purge:
v Draft Created (1000) and all extended Draft Created Statuses.

Chapter 22. Time-Triggered Transaction Reference 469


v Created (1100) and all extended Created statuses. These statuses are available
only for document types Sales Order, Purchase Order and Transfer Order.
v Released (3200) and all extended Released statuses.
v Shipped (3700) and all extended Shipped statuses.
v Completed (3700) and all extended Completed statuses. These statuses are
available only for the document type Master Order.
v Received (3900) and all extended Received statuses.
v Cancelled (9000) and all extended Cancelled statuses.
v Shorted (9020) and all extended Shorted statuses.

You can use purge codes pseudo-logic to analyze purges. If the following
conditions are met, an order is picked up for purge:
v All open child orders (derived, chained, return, exchange, procurement, or
refund fulfillment) for the order must already be purged.
v No pending transfer-out charges to another order exceeding the transfer-ins.
v No pending adjustment invoices.

An order is purged immediately if it meets the above three criteria and is


completely cancelled with payment collection complete.

For the purge agent to pick up a cancelled order, the payment status of the order
must be one of the following:
v Paid
v Not Applicable

If an order does not meet any of the above criteria, continue checking for the
criteria given below:
v No order release status record that does not meet the retention days.
v It should be in the correct status for purge. For example,
– All service requests for the order should have Shipped or extended Shipped
status.
– The payment status for the order should be Paid or Not Applicable.
– It must not have any unpurged negotiations.
v For all order lines other than service request lines:
– If the Seller inventory update is required, the Status Inventory Type has the
“Update Seller Supply” option turned on, and the Seller Supply Type is
“Onhand”, or blank. (The Seller Supply Type can also be a custom seller
supply type with the “Onhand Supply” checkbox enabled.)
– If the Seller Demand Type is blank.
– If the Buyer inventory update is required and the Buyer Supply Type is
“Onhand”, or blank.
v The order's last modification should fall before the lead time (in days) setup.
v Any enterprise using the Console must schedule purge transactions.
v The order must not have a undelivered service line.
v In the case of an exchange order for processing a return order, the exchange
order should be purged from history before the return order can be purged.

With no change to status inventory type, a in Shipped (3700) status or its extended
status is purged if the Buyer is not passed.

470 Sterling Selling and Fulfillment Foundation: Application Platform Configuration Guide
An order in Shipped status or extended Shipped status in the default pipeline is
not purged if the Buyer passed on the is tracking inventory. This prevents the
purging of the order relating to the pending supply for the Buyer tracking
inventory.

To purge such orders, the status inventory type for the Shipped or extended
Shipped status should be configured such that the Buyer Supply Type is
ONHAND for the status inventory type.

When the purge agent is run, the draft order without lines are purged to the order
history table. Once the purge history agent is run, the draft orders without lines
gets deleted permanently.

Attributes

The following are the attributes for this time-triggered transaction:


Table 305. Order Purge Attributes
Attribute Value
Base Transaction ID PURGE
Base Document Type Order
Base Process Type Order Fulfillment
Abstract Transaction No
APIs Called None
User Exits Called YFSBeforePurgeUE

Criteria Parameters

The following are the criteria parameters for this transaction:


Table 306. Order Purge Criteria Parameters
Parameter Description
Action Required. Triggers the transaction. If left blank, it defaults to
Get, the only valid value.
Number of Records To Optional. Number of records to retrieve and process at one
Buffer time. If left blank or specified as 0 (zero), it defaults to 5000.
Next Task Queue Interval Optional. Specifies in hours how long a failed task should be
suspended before it is considered for reprocessing. Defaults to
5 hours.
EnterpriseCode Optional. Enterprise for which the Order Purge needs to be
run. If not passed, then all enterprises are monitored.

When the EnterpriseCode is blank, the purge criteria


configured for the DEFAULT enterprise is used; not the purge
criteria configured for the order's enterprise.
Live Optional. Mode in which to run. Valid values are:
v Y - Default value. Moves qualifying records from the
regular tables listed under Tables Purged to the
corresponding history tables.
v N - Test mode. Determines the rows that are moved to
history tables without actually moving them.

Chapter 22. Time-Triggered Transaction Reference 471


Table 306. Order Purge Criteria Parameters (continued)
Parameter Description
PurgeCode Required. Used for internal calculations, such as determining
retention days. Corresponds with the PurgeCode used in
Business Rules Purge Criteria. You can set this parameter to
the following values:
v DRAFTORDERHISTPRG to purge draft order information
from the order history tables.
v DRAFTORDERNOLINEHISTPRG to purge draft orders
without order lines from the order history tables.
v DRAFTORDERNOLINEPRG to purge draft orders that have
no order lines.
v DRAFTORDERPRG to purge draft order information and
archive it in the order history tables.

PurgeCode cannot be set to the value


ORDER_RELEASE_STATUS_PURGE.
AdditionalPurgeCode Optional. To purge order release status records, set this
parameter to ORDER_RELEASE_STATUS_PURGE.

For more information, see “Order Release Status Purge” on


page 474.
ColonyID Required in a multi schema deployment where a table may
exist in multiple schemas. Runs the agent for the colony.

Statistics Tracked

The following statistics are tracked for this transaction:


Table 307. Order Purge Statistics
Statistic Name Description
NumOrdersProcessed Number of order processed.
NumOrdersPurged Number of orders purged.

Pending Job Count

For this transaction, the pending job count is the number of records available to be
processed by the transaction with the AVAILABLE_DATE value less than or equal
to (<=) the current date value in the YFS_Task_Q table.

Events Raised

None.

Tables Purged

YFS_ACTIVITY_DEMAND

YFS_ANSWER_SET_TRAN

YFS_ANSWER_TRAN

YFS_CHARGE_TRANSACTION

472 Sterling Selling and Fulfillment Foundation: Application Platform Configuration Guide
YFS_CHARGE_TRAN_DIST

YFS_CHARGE_TRAN_REQUEST

YFS_CHARGE_TRAN_RQ_MAP

YFS_CREDIT_CARD_TRANSACTION

YFS_ENTITY_ADDRESS

YFS_HEADER_CHARGES

YFS_INSTRUCTION_DETAIL

YFS_INVOICE_COLLECTION

YFS_LINE_CHARGES

YFS_MONITOR_ALERT

YFS_NOTES

YFS_ORDER_AUDIT

YFS_ORDER_AUDIT_DETAIL

YFS_ORDER_AUDIT_LEVEL

YFS_ORDER_HEADER

YFS_ORDER_HOLD_TYPE

YFS_ORDER_HOLD_TYPE_LOG

YFS_ORDER_INVOICE

YFS_ORDER_INVOICE_DETAIL

YFS_ORDER_KIT_LINE

YFS_ORDER_KIT_LINE_SCHEDULE

YFS_ORDER_LINE

YFS_ORDER_LINE_OPTION

YFS_ORDER_LINE_REQ_TAG

YFS_ORDER_LINE_RESERVATION

YFS_ORDER_LINE_SCHEDULE

YFS_ORDER_LINE_SRC_CNTRL

YFS_ORDER_PROD_SER_ASSOC

Chapter 22. Time-Triggered Transaction Reference 473


YFS_ORDER_RELEASE

YFS_ORDER_RELEASE_STATUS

YFS_ORDER_SER_PROD_ITEM

YFS_ORDER_DATE

YFS_PAYMENT

YFS_PMNT_TRANS_ERROR

YFS_PROMOTION

YFS_PROMOTION_AWARD

YFS_RECEIVING_DISCREPANCY

YFS_RECEIVING_DISCREPANCY_DTL

YFS_REFERENCE_TABLE

YFS_TAX_BREAKUP

YIC_BOM_HEADER

YIC_BOM_LINE

YIC_BOM_MESSAGE

YIC_BOM_PROP

Order Release Status Purge


The Order Release Status Purge agent extends the Order Purge agent's capabilities
by purging order release status records before the Order Purge agent completely
purges data to history tables.

If an order meets the criteria for purging, the order release status records with
quantities of 0 are deleted from the YFS_ORDER_RELEASE_STATUS table and are
not put into the history table.

When the Order Release Status Purge agent has completed, the task queue's
AVAILABLE_DATE is reset to the date specified by the purge criteria for Order
Purge. This enables the Order Purge agent to pick up and process an order as
necessary. Order Purge will continue to purge order release status records as usual.

If the following conditions are met, the Order Purge agent purges order release
status records:
v All conditions for Order Purge have been met. See “Order Purge” on page 469
for information about conditions for Order Purge.
v Order release records have 0 quantity.
v AdditionalPurgeCode in the Order Purge criteria is set to
ORDER_RELEASE_STATUS_PURGE.

474 Sterling Selling and Fulfillment Foundation: Application Platform Configuration Guide
v The order has been modified within the Order Purge lead days
AdditionalPurgeCode.

Criteria Parameters

The following are the criteria parameters for Order Release Status Purge:
Table 308. Order Release Status Purge Criteria Parameters
Parameter Description
Action Required. Triggers the transaction. If left blank, it defaults to
Get, the only valid value.
Number of Records To Optional. Number of records to retrieve and process at one
Buffer time. If left blank or specified as 0 (zero), it defaults to 5000.
Next Task Queue Interval Optional. Specifies in hours how long a failed task should be
suspended before it is considered for reprocessing. Defaults to
5 hours.
EnterpriseCode Optional. Enterprise for which the Order Purge needs to be
run. If not passed, then all enterprises are monitored.

When the EnterpriseCode is blank, the purge criteria


configured for the DEFAULT enterprise is used; not the purge
criteria configured for the order's enterprise.
Live Optional. Mode in which to run. Valid values are:
v Y - Default value. Moves qualifying records from the
regular tables listed under Tables Purged to the
corresponding history tables.
v N - Test mode. Determines the rows that are moved to
history tables without actually moving them.
PurgeCode Required. To extend the Order Purge agent to purge order
release status records, set to ORDERPRG. Used for internal
calculations, such as determining retention days. You must
also set AddtionalPurgeCode.
AdditionalPurgeCode Required. To purge order release status records, set this
parameter to ORDER_RELEASE_STATUS_PURGE.
ColonyID Required in a multi schema deployment where a table may
exist in multiple schemas. Runs the agent for the colony.

Statistics Tracked

None.

Pending Job Count

The pending job count is the number of records available to be processed by Order
Purge with the AVAILABLE_DATE value less than or equal to (<=) the current
date value in the YFS_Task_Q table.

Events Raised

None.

Tables Purged

YFS_ORDER_RELEASE_STATUS

Chapter 22. Time-Triggered Transaction Reference 475


Order Status Audit Purge
This purge removes order status audit data from the system. This reduces the load
on frequently accessed tables.

You can use purge codes pseudo-logic to analyze purges. If the following condition
is met, an order status audit is picked up for history purge:
v The last modified time falls before the lead time (in days) setup.

Any enterprise using the Console must schedule purge transactions.

This transaction needs to be run after negotiation is completed.

Attributes

The following are the attributes for this time-triggered transaction:


Table 309. Order Status Audit Purge Attributes
Attribute Value
Base Transaction ID STATUSAUDITPRG
Base Document Type Order
Base Process Type Order Fulfillment
Abstract Transaction No
APIs Called None
User Exits Called YFSBeforePurgeUE

Criteria Parameters

The following are the criteria parameters for this transaction:


Table 310. Order Status Audit Purge Criteria Parameters
Parameter Description
Action Required. Triggers the transaction. If left blank, it defaults to
Get, the only valid value.
Number of Records To Optional. Number of records to retrieve and process at one
Buffer time. If left blank or specified as 0 (zero), it defaults to 5000.
EnterpriseCode Optional. Enterprise for which the Order Status Audit Purge
needs to be run. If not passed, then all enterprises are
monitored.
Live Optional. Mode in which to run. Valid values are:
v Y - Default value. Moves qualifying records from the
regular tables listed under Tables Purged to the
corresponding history tables.
v N - Test mode. Determines the rows that are moved to
history tables without actually moving them.
PurgeCode Required. Cannot be modified. Used for internal calculations,
such as determining retention days. Corresponds with the
PurgeCode used in Business Rules Purge Criteria.
ColonyID Required in a multi schema deployment where the
YFS_STATUS_AUDIT Table may exist in multiple schemas.
Runs the agent for the colony.

476 Sterling Selling and Fulfillment Foundation: Application Platform Configuration Guide
Statistics Tracked

The following statistics are tracked for this transaction:


Table 311. Order Status Audit Purge Statistics
Statistic Name Description
NumStatusAuditsPurged Number of status audits purged.

Pending Job Count

For this transaction, the pending job count is the number of records that can be
purged from the YFS_Status_Audit table.

Events Raised

None.

Tables Purged

YFS_STATUS_AUDIT

Organization Audit Purge


This purge removes the YFS_AUDIT table data from the system, which reduces the
load on frequently accessed tables. It purges records in the YFS_AUDIT and the
YFS_AUDIT_HEADER tables that meet the following conditions:
v The YFS_AUDIT records that have ‘modifyts' greater than the retention days
specified and the records have the table name as 'YFS_ORGANIZATION'.
v The last modified time is before the lead time (in days) setup.

When the enterprise modifies records in the YFS_ORGANIZATION table through


the Applications Manager, the YFS_ ORGANIZATION is audited and the audit
records are inserted in the YFS_AUDIT table. In order to clean up the audit
records, this purge transaction can be used.

Any enterprise using the Console must schedule purge transactions.

Attributes

The following are the attributes for this time-triggered transaction:


Table 312. Organization Audit Purge Attributes
Attribute Value
Base Transaction ID YFS_ORGANIZATION_AUDIT_PURGE
Base Document Type General
Base Process Type General
Abstract Transaction No
APIs Called None
User Exits Called YFSBeforePurgeUE

Chapter 22. Time-Triggered Transaction Reference 477


Criteria Parameters

The following are the criteria parameters for this transaction:


Table 313. Organization Audit Purge Criteria Parameters
Parameter Description
Action Required. Triggers the transaction. If left blank, the value
defaults to Get, the only valid value.
Number of Records To Optional. Number of records to retrieve and process at one
Buffer time. If left blank or specified as 0 (zero), this value defaults
to 5000.
Live Optional. Mode in which to run. Valid values are:
v Y - Default value. Production mode. Deletes records from
the regular tables.
v N - Test mode.
PurgeCode Required. Cannot be modified. Used for internal calculations,
such as determining retention days. Corresponds to the
PurgeCode used in Business Rules Purge Criteria.
ColonyID Required in a multi schema deployment where the
YFS_AUDIT and YFS_AUDIT_HEADER tables may exist in
multiple schemas. Runs the agent for the colony.

Statistics Tracked

The following statistics are tracked for this transaction:


Table 314. Organization Audit Purge Statistics
Statistic Name Description
NumOrganizationAudit Number of organization audit records purged.
RecordsPurged

Pending Job Count

For this transaction, the pending job count is the number of records that can be
purged from the YFS_AUDIT table that match the criteria values.

Events Raised

None.

Tables Purged

YFS_AUDIT

YFS_AUDIT_HEADER

Person Info Purge


This purge gets a list of dates with the person info record count and sorts them by
date in ascending order. Then, based on the specified number of records to buffer
and the modify timestamp, it purges the applicable records and places them in the
YFS_PERSON_INFO_H table.

478 Sterling Selling and Fulfillment Foundation: Application Platform Configuration Guide
Attributes

The following are the attributes for this time-triggered transaction:


Table 315. PersonInfo Purge Attributes
Attribute Value
Base Transaction ID PERSONINFOPRG
Base Document Type General
Base Process Type General
Abstract Transaction No
APIs Called None
User Exits Called None

Criteria Parameters

The following are the criteria parameters for this transaction:


Table 316. PersonInfo Purge Criteria Parameters
Parameter Description
Action Required. Triggers the transaction. If left blank, it defaults to
Get, the only valid value.
Number of Records To Optional. Number of records to retrieve and process at one
Buffer time.
v If left blank or the number specified is less than 10000, it
defaults to 10000.
v If the number specified is greater than 10000, then that
value is used.
Live Optional. Mode in which to run. Valid values are:
v Y - Default value. Moves qualifying records from the
regular tables listed under Tables Purged to the
corresponding history tables.
v N - Test mode. Determines the rows that are moved to
history tables without actually moving them.
PurgeCode Required. Cannot be modified. Used for internal calculations,
such as determining retention days. Corresponds with the
PurgeCode used in Business Rules Purge Criteria.
CollectPendingJobs If this parameter is set to "N", the agent does not collect
information on the pending jobs for this monitor. This pending
job information is used for monitoring the monitor in the
System Management Console.
EnterpriseCode Optional. Enterprise for which the PersonInfo Purge needs to
be run. If not passed, then all enterprises are monitored.

Chapter 22. Time-Triggered Transaction Reference 479


Table 316. PersonInfo Purge Criteria Parameters (continued)
Parameter Description
TableType Required in a multi schema deployment when
YFS_Person_Info table may exist in multiple schemas.

Valid Values: CONFIGURATION, TRANSACTION, MASTER.

If set to CONFIGURATION, purge runs for the


YFS_Person_Info records associated with tables that have
TableType as CONFIGURATION; for example,
YFS_Organization, YFS_Ship_Node, and so forth.

If set to TRANSACTION, purge runs for the YFS_Person_Info


records associated with tables that have TableType as
TRANSACTION; for example, YFS_Order_Header,
YFS_Shipment, and so forth.

Note that purge would run for all TableTypes that exist in the
same schema as the one passed. For example, if set to
TRANSACTION, purge would also run for YFS_Person_Info
records associated with tables that have TableType as
MASTER, since they reside in the same schema.
ColonyID Required in a multi schema deployment where the
YFS_PERSON_INFO table may exist in multiple schemas.
Runs the agent for the colony.

Statistics Tracked

The following statistics are tracked for this transaction:

If it is left blank or any number less than 10,000 is specified, then it defaults to
10,000. But if any number > 10,000 is specified, then that value would be used.
Table 317. PersonInfo Purge Statistics
Statistic Name Description
NumPersonInfoPurged Number of person info records purged.

Pending Job Count

For this transaction, the pending job count is the number of records that can be
purged from the YFS_PERSON_INFO table.

Events Raised

None.

Tables Purged

YFS_PERSON_INFO

Person Info History Purge


This purge deletes records from the YFS_PERSON_INFO_H table based on the
purge criteria.

480 Sterling Selling and Fulfillment Foundation: Application Platform Configuration Guide
Attributes

The following are the attributes for this time-triggered transaction:


Table 318. PersonInfo History Purge Attributes
Attribute Value
Base Transaction ID PERSONINFOHISTPRG
Base Document Type General
Base Process Type General
Abstract Transaction No
APIs Called None
User Exits Called None

Criteria Parameters

The following are the criteria parameters for this transaction:


Table 319. PersonInfo History Purge Criteria Parameters
Parameter Description
Action Required. Triggers the transaction. If left blank, it defaults to
Get, the only valid value.
Number of Records To Optional. Number of records to retrieve and process at one
Buffer time.
v If left blank or the number specified is less than 10000, it
defaults to 10000.
v If the number specified is greater than 10000, then that
value is used.
Live Optional. Mode in which to run. Valid values are:
v Y - Default value. Moves qualifying records from the
regular tables listed under Tables Purged to the
corresponding history tables.
v N - Test mode. Determines the rows that are moved to
history tables without actually moving them.
PurgeCode Required. Cannot be modified. Used for internal calculations,
such as determining retention days. Corresponds with the
PurgeCode used in Business Rules Purge Criteria.
CollectPendingJobs If this parameter is set to "N", the agent does not collect
information on the pending jobs for this monitor. This pending
job information is used for monitoring the monitor in the
System Management Console.
EnterpriseCode Optional. Enterprise for which the PersonInfo Purge needs to
be run. If not passed, then all enterprises are monitored.

Chapter 22. Time-Triggered Transaction Reference 481


Table 319. PersonInfo History Purge Criteria Parameters (continued)
Parameter Description
TableType Required in a multi schema deployment when
YFS_Person_Info table may exist in multiple schemas.

Valid Values: CONFIGURATION, TRANSACTION, MASTER.

If set to CONFIGURATION, purge runs for the


YFS_Person_Info records associated with tables that have
TableType as CONFIGURATION; for example,
YFS_Organization, YFS_Ship_Node, and so forth.

If set to TRANSACTION, purge runs for the YFS_Person_Info


records associated with tables that have TableType as
TRANSACTION; for example, YFS_Order_Header,
YFS_Shipment, and so forth.

Note that purge would run for all TableTypes that exist in the
same schema as the one passed. For example, if set to
TRANSACTION, purge would also run for YFS_Person_Info
records associated with tables that have TableType as
MASTER, since they reside in the same schema.
ColonyID Required in a multi schema deployment where the
YFS_PERSON_INFO_H table may exist in multiple schemas.
Runs the agent for the colony.

Statistics Tracked

The following statistics are tracked for this transaction:


Table 320. PersonInfo History Purge Statistics
Statistic Name Description
NumPersonInfoHIstoryRecords Number of person info history records purged.
Purged

Pending Job Count

For this transaction, the pending job count is the number of records that can be
purged from the YFS_PERSON_INFO_H table.

Events Raised

None.

Tables Purged

YFS_PERSON_INFO_H

Picklist Purge
This purge picks up all picklists that have been existing for a period greater than
the retention days specified in the criteria parameters and those that do not have
any shipments.

Any enterprise using the Console must schedule purge transactions.

482 Sterling Selling and Fulfillment Foundation: Application Platform Configuration Guide
You can use purge codes pseudo-logic to analyze purges. If the following
conditions are met, a picklist is picked up for purge:
v The picklist should exist for more than the specified retention period.
v The picklist should not be associated with any shipment.

All shipments associated with the picklists should have been purged before
running this purge agent.

Attributes

The following are the attributes for this time-triggered transaction:


Table 321. Picklist Purge Attributes
Attribute Value
Base Transaction ID PICKLISTPRG
Base Document Type Order
Base Process Type Order Delivery
Abstract Transaction No
APIs Called None
User Exits Called YFSBeforePurgeUE

Criteria Parameters

The following are the criteria parameters for this transaction:


Table 322. Picklist Purge Criteria Parameters
Parameter Description
Action Required. Triggers the transaction. If left blank, it defaults to
Get, the only valid value.
Number of Records To Optional. Number of records to retrieve and process at one
Buffer time. If left blank or specified as 0 (zero), it defaults to 5000.
Live Optional. Mode in which to run. Valid values are:
v Y - Default value. Moves qualifying records from the
regular tables listed under Tables Purged to the
corresponding history tables.
v N - Test mode. Determines the rows that are moved to
history tables without actually moving them.
PurgeCode Required. Cannot be modified. Used for internal calculations,
such as determining retention days. Corresponds with the
PurgeCode used in Business Rules Purge Criteria.
ColonyID Required in a multi schema deployment where the
YFS_PICK_LIST table may exist in multiple schemas. Runs the
agent for the colony.

Chapter 22. Time-Triggered Transaction Reference 483


Statistics Tracked

The following statistics are tracked for this transaction:


Table 323. Picklist Purge Statistics
Statistic Name Description
NumPickListsPurged Number of picklists purged.

Pending Job Count

For this transaction, the pending job count is the number of records that can be
purged from the YFS_PICK_LIST table.

Events Raised

None.

Tables Purged

YFS_PICK_LIST

Price List Purge


This purge removes price list data from the system. This reduces the load on
frequently accessed tables.

Any enterprise using the Console must schedule purge transactions.

You can use purge codes pseudo-logic to analyze purges. If the following condition
is met, a price list is picked up for purge:
v The price list has valid date less than the current date minus the purge criteria's
retention days.

Attributes

The following are the attributes for this time-triggered transaction:


Table 324. Price List Purge Attributes
Attribute Value
Base Transaction ID PRICELISTPRG
Base Document Type General
Base Process Type General
Abstract Transaction No
APIs Called None
User Exits Called YFSBeforePurgeUE

484 Sterling Selling and Fulfillment Foundation: Application Platform Configuration Guide
Criteria Parameters

The following are the criteria parameters for this transaction:


Table 325. Price List Purge Criteria Parameters
Parameter Description
Action Required. Triggers the transaction. If left blank, it defaults to
Get, the only valid value.
Number of Records To Optional. Number of records to retrieve and process at one
Buffer time. If left blank or specified as 0 (zero), it defaults to 5000.
Live Optional. Mode in which to run. Valid values are:
v Y - Default value. Moves qualifying records from the
regular tables listed under Tables Purged to the
corresponding history tables.
v N - Test mode. Determines the rows that are moved to
history tables without actually moving them.
PurgeCode Required. Cannot be modified. Used for internal calculations,
such as determining retention days. Corresponds with the
PurgeCode used in Business Rules Purge Criteria.
ColonyID Required in a multi schema deployment where a table may
exist in multiple schemas. Runs the agent for the colony.

Statistics Tracked

The following statistics are tracked for this transaction:


Table 326. Price List Purge Statistics
Statistic Name Description
NumPriceSetsPurged Number of price sets purged.

Pending Job Count

For this transaction, the pending job count is the number of records that can be
purged from the YFS_Price_Set table.

Events Raised

None.

Tables Purged

YFS_PRICE_SET table with VALID_TILL_DATE less than or equal to (CurrentDate


- LeadDays)

YFS_PRICE_PROGRAM_DEFN

YFS_ITEM_PRICE_SET

YFS_ITEM_PRICE_SET_DTL

Chapter 22. Time-Triggered Transaction Reference 485


Purge Catalog Mass Audits
This purge removes old audit records from the YFS_CATALOG_MASS_AUDIT
table. This table contains data about changes to the catalog due to assignment of
attributes and attribute values to categories and items. It also contains information
about inherited attributes and attribute values. The purge transaction finds mass
audit records that have not been modified in a specified number of days and
removes those records from the database.

Attributes

The following are the attributes for this time-triggered transaction:


Table 327. Purge Catalog Mass Audits Attributes
Attribute Value
Base Transaction ID CATALOG_MASS_AUDIT_PURGE
Base Document Type General
Base Process Type General
Abstract Transaction No
APIs Called None
User Exits Called YFSBeforePurgeUE

Criteria Parameters

The following are the criteria parameters for this transaction:


Table 328. Purge Catalog Mass Audits Criteria Parameters
Parameter Description
Action Required. Triggers the transaction. If left blank, it defaults to
Get, the only valid value.
Number of Records To Optional. Number of records to retrieve and process at one
Buffer time. If left blank or specified as 0 (zero), it defaults to 5000.
Live Optional. Mode in which to run. Valid values are:
v Y - Default value. Moves qualifying records from the
regular tables listed under Tables Purged to the
corresponding history tables.
v N - Test mode. Determines the rows that are moved to
history tables without actually moving them.
PurgeCode Required. Cannot be modified. Used for internal calculations,
such as determining retention days. Corresponds with the
PurgeCode used in Business Rules Purge Criteria.
ColonyID Required in a multi schema deployment where the
YFS_CATALOG_MASS_AUDIT table may exist in multiple
schemas. Runs the agent for the colony.

486 Sterling Selling and Fulfillment Foundation: Application Platform Configuration Guide
Statistics Tracked

The following statistics are tracked for this transaction:


Table 329. Purge Catalog Mass Audits Statistics
Statistic Name Description
NumCatalogMassAuditsPurged Number of mass audit records purged.

Pending Job Count

For this transaction the pending job count is the total number of records that can
be purged from the YFS_CATALOG_MASS_AUDIT table.

Events Raised

None.

Tables Purged

The YFS_CATALOG_MASS_AUDIT table is purged when MODIFYTS <


(CurrentDate - LeadDays)

Receipt History Purge


This transaction deletes receipts previously archived by the Receipt Purge. See
“Receipt Purge” on page 489.

Any enterprise using the Console must schedule purge transactions.

You can use purge codes pseudo-logic to analyze purges. If the following
conditions are met, a receipt that is previously purged by the receipt purge agent is
picked up for history purge:
v The last modified date of the receipt should exceed the retention day period.
v The shipment associated with the receipt should be purged from the history
table.

To purge a receipt history, ensure that the Receipts are closed and Shipments are
purged.

Attributes

The following are the attributes for this time-triggered transaction:


Table 330. Receipt History Purge Attributes
Attribute Value
Base Transaction ID RECEIPTHISTPRG
Base Document Type Order
Base Process Type Order Fulfillment
Abstract Transaction No
APIs Called None
User Exits Called YFSBeforePurgeUE

Chapter 22. Time-Triggered Transaction Reference 487


Criteria Parameters

The following are the criteria parameters for this transaction:


Table 331. Receipt History Purge Criteria Parameters
Parameter Description
Action Required. Triggers the transaction.
Number of Records To Optional. Number of records to retrieve and process at one
Buffer time. If left blank or specified as 0 (zero), it defaults to 5000.
EnterpriseCode Optional. Enterprise for which the Receipt History Purge
needs to be run. If not passed, then all enterprises are
monitored.
Live Optional. Mode in which to run. Valid values are:
v Y - Default value. Removes qualifying records from the
history tables listed under Tables Purged.
v N- Test mode. Determines the rows that are removed
without actually removing them.
PurgeCode Required. Cannot be modified. Used for internal calculations,
such as determining retention days. Corresponds with the
PurgeCode used in Business Rules Purge Criteria.
ColonyID Required in a multi schema deployment where a table may
exist in multiple schemas. Runs the agent for the colony.

Statistics Tracked

The following statistics are tracked for this transaction:


Table 332. Receipt History Purge Statistics
Statistic Name Description
NumReceiptLineHistoriesPurged Number of receipt line histories purged.
NumReceiptHistoriesPurged Number of receipt histories purged.

Pending Job Count

For this transaction, the pending job count is the number of records that can be
purged from the YFS_Receipt_Header_H table.

Events Raised

None.

Tables Purged

YFS_RECEIPT_HEADER_H

YFS_RECEIPT_LINE_H

YFS_RECEIPT_STATUS_AUDIT_H

YFS_INSTRUCTION_DETAIL_H

488 Sterling Selling and Fulfillment Foundation: Application Platform Configuration Guide
Receipt Purge
This purge removes receipt data from the system. This reduces the load on
frequently accessed tables. This transaction picks up all receipts that are not open
and not pending inspection and archives them into their history tables. See
“Receipt History Purge” on page 487. It also archives and purges the receipt's child
tables.

This is a pipeline transaction and works from a task queue.

Any enterprise using the Console must schedule purge transactions.

You can use purge codes pseudo-logic to analyze purges. If the following
conditions are met, a receipt is picked up for purge:
v The last modified date of the receipt should exceed the retention day period.
v The shipment associated with the receipt should be purged.
v The receipt should be in pickable status for the purge transaction.
v The value of the OpenReceiptFlag field should be set to "N".
v The receipt should not have pending inspections.
v There is no inventory in the warehouse for the receipt.

To purge a receipt, ensure that the receipts are closed and Shipments are purged.

Attributes

The following are the attributes for this time-triggered transaction:


Table 333. Receipt Purge Attributes
Attribute Value
Base Transaction ID RECEIPTPRG
Base Document Type Order
Base Process Type Order Fulfillment
Abstract Transaction No
APIs Called None
User Exits Called YFSBeforePurgeUE

Criteria Parameters

The following are the criteria parameters for this transaction:


Table 334. Receipt Purge Criteria Parameters
Parameter Description
Action Required. Triggers the transaction.
Number of Records To Optional. Number of records to retrieve and process at one
Buffer time. If left blank or specified as 0 (zero), it defaults to 5000.
EnterpriseCode Optional. Enterprise for which the Receipt Purge needs to be
run. If not passed, then all enterprises are monitored.

Chapter 22. Time-Triggered Transaction Reference 489


Table 334. Receipt Purge Criteria Parameters (continued)
Parameter Description
Live Optional. Mode in which to run. Valid values are:
v Y - Default value. Moves qualifying records from the
regular tables listed under Tables Purged to the
corresponding history tables.
v N - Test mode. Determines the rows that are moved to
history tables without actually moving them.
PurgeCode Required. Cannot be modified. Used for internal calculations,
such as determining retention days. Corresponds with the
PurgeCode used in Business Rules Purge Criteria.
ColonyID Required in a multi schema deployment where a table may
exist in multiple schemas. Runs the agent for the colony.

Statistics Tracked

The following statistics are tracked for this transaction:


Table 335. Receipt Purge Statistics
Statistic Name Description
NumReceiptLinesPurged Number of Receipt Lines purged.
NumReceiptsPurged Number of receipts purged.

Pending Job Count

For this transaction, the pending job count is the number of records available to be
processed by the transaction with the AVAILABLE_DATE value less than or equal
to (<=) the current date value in the YFS_Task_Q table.

Events Raised

None.

Tables Purged

YFS_RECEIPT_HEADER

YFS_RECEIPT_LINE

YFS_RECEIPT_STATUS_AUDIT

YFS_INSTRUCTION_DETAIL

Reprocess Error Purge


This purge deletes reprocess errors from the system. This reduces the load on
frequently accessed tables.

You can use purge codes pseudo-logic to analyze purges. If the following
conditions are met, a YFS_REPROCESS_ERROR table is picked up for purge:
v YFS_REPROCESS_ERROR records with State = Fixed or Ignored is processed.
v The last modified time is earlier than the lead time (in days) setup.

490 Sterling Selling and Fulfillment Foundation: Application Platform Configuration Guide
This purge reads only the rules defined by the hub. Enterprise overridden rules are
not considered.

Any enterprise using the ConsoleConsole must schedule purge transactions.

Attributes

The following are the attributes for this time-triggered transaction:


Table 336. Reprocess Error Purge Attributes
Attribute Value
Base Transaction ID REPROCESSPRG
Base Document Type General
Base Process Type General
Abstract Transaction No
APIs Called None
User Exits Called YFSBeforePurgeUE

Criteria Parameters

The following are the criteria parameters for this transaction:


Table 337. Reprocess Error Purge Criteria Parameters
Parameter Description
Action Required. Triggers the transaction. If left blank, it defaults to
Get, the only valid value.
Number of Records To Optional. Number of records to retrieve and process at one
Buffer time. If left blank or specified as 0 (zero), it defaults to 5000.
Live Optional. Mode in which to run. Valid values are:
v Y - Default value. Moves qualifying records from the
regular tables listed under Tables Purged to the
corresponding history tables.
v N - Test mode. Determines the rows that are moved to
history tables without actually moving them.
PurgeCode Required. Cannot be modified. Used for internal calculations,
such as determining retention days. Corresponds with the
PurgeCode used in Business Rules Purge Criteria.
ColonyID Required in a multi schema deployment where the
YFS_REPROCESS_ERROR table may exist in multiple
schemas. Runs the agent for the colony.

Statistics Tracked

The following statistics are tracked for this transaction:


Table 338. Reprocess Error Purge Statistics
Statistic Name Description
NumReprocessErrorsPurged Number of reprocess errors purged.

Chapter 22. Time-Triggered Transaction Reference 491


Pending Job Count

For this transaction, the pending job count is the number of records that can be
purged from the YFS_REPROCESS_ERROR table.

Events Raised

None.

Tables Purged

YFS_REPROCESS_ERROR

Reservation Purge
This purge deletes expired inventory reservations from the system. This reduces
the load on frequently accessed tables as well as free up demands that are
consumed by expired reservations.

You can use purge codes pseudo-logic to analyze purges. If the following condition
is met, all records in the YFS_INVENTORY_RESERVATION tables are picked up
for purge:
v EXPIRATION_DATE is earlier than the current date or quantity is less than or
equal to 0

Any enterprise using the Console must schedule purge transactions.

Attributes

The following are the attributes for this time-triggered transaction:


Table 339. Reservation Purge Attributes
Attribute Value
Base Transaction ID RESERVATIONPRG
Base Document Type General
Base Process Type General
Abstract Transaction No
APIs Called None
User Exits Called None

Criteria Parameters

The following are the criteria parameters for this transaction:


Table 340. Reservation Purge Criteria Parameters
Parameter Description
Action Required. Triggers the transaction. If left blank, it defaults to
Get, the only valid value.
Number of Records To Optional. Number of records to retrieve and process at one
Buffer time. If left blank or specified as 0 (zero), it defaults to 5000.

492 Sterling Selling and Fulfillment Foundation: Application Platform Configuration Guide
Table 340. Reservation Purge Criteria Parameters (continued)
Parameter Description
Live Optional. Mode in which to run. Valid values are:
v Y - Default value. Moves qualifying records from the
regular tables listed under Tables Purged to the
corresponding history tables.
v N - Test mode. Determines the rows that are moved to
history tables without actually moving them.
PurgeCode Required. Cannot be modified. Used for internal calculations,
such as determining retention days. Corresponds with the
PurgeCode used in Business Rules Purge Criteria.
ColonyID Required in a multi schema deployment where the
YFS_INVENTORY_RESERVATION table may exist in multiple
schemas. Runs the agent for the colony.

Statistics Tracked

The following statistics are tracked for this transaction:


Table 341. Reservation Purge Statistics
Statistic Name Description
NumReservationsPurged Number of reservations purged.

Pending Job Count

For this transaction, the pending job count is the number of records that can be
purged from the YFS_INVENTORY_RESERVATION table.

Events Raised

None.

Tables Purged

YFS_INVENTORY_RESERVATION

Shipment History Purge


This transaction deletes shipments previously archived by the Shipment Purge. See
“Shipment Purge” on page 495.

Any enterprise using the Console must schedule purge transactions.

You can use purge codes pseudo-logic to analyze purges. If the following condition
is met, all records archived in the history table are picked up for purge:
v The last modification performed on the shipment falls before the lead time (in
days) setup.

Orders related to the shipments should have been purged by order purge.
Shipments should have been closed by the Close Shipment transaction. See “Close
Shipment” on page 379.

Chapter 22. Time-Triggered Transaction Reference 493


Attributes

The following are the attributes for this time-triggered transaction:


Table 342. Shipment History Purge Attributes
Attribute Value
Base Transaction ID SHIPMENTHISTPRG
Base Document Type Order
Base Process Type Order Delivery
Abstract Transaction No
APIs Called None
User Exits Called YFSBeforePurgeUE

Criteria Parameters

The following are the criteria parameters for this transaction:


Table 343. Shipment History Purge Criteria Parameters
Parameter Description
Action Required. Triggers the transaction.
Number of Records To Optional. Number of records to retrieve and process at one
Buffer time. If left blank or specified as 0 (zero), it defaults to 5000.
EnterpriseCode Optional. Enterprise for which the Shipment History Purge
needs to be run. If not passed, then all enterprises are
monitored.
Live Optional. Mode in which to run. Valid values are:
v Y - Default value. Removes qualifying records from the
history tables listed under Tables Purged.
v N- Test mode. Determines the rows that are removed
without actually removing them.
PurgeCode Required. Cannot be modified. Used for internal calculations,
such as determining retention days. Corresponds with the
PurgeCode used in Business Rules Purge Criteria.
ColonyID Required in a multi schema deployment where a table may
exist in multiple schemas. Runs the agent for the colony.

Statistics Tracked

The following statistics are tracked for this transaction:


Table 344. Shipment History Purge Statistics
Statistic Name Description
NumShipmentHistoriesPurged Number of shipment histories purged.
NumShipmentLineHistoriesPurged Number of shipment line histories purged.

Pending Job Count

For this transaction, the pending job count is the number of records that can be
purged from the YFS_Shipment_H table.

494 Sterling Selling and Fulfillment Foundation: Application Platform Configuration Guide
Events Raised

None.

Tables Purged

YFS_ADDITIONAL_ATTRIBUTE_H

YFS_ADDITIONAL_DATE_H

YFS_AUDIT

YFS_CONTAINER_DETA ILS_H

YFS_CONTAINER_STS_AUDIT_H

YFS_INSTRUCTION_DETAIL_H

YFS_SHIPMENT_CONTAINER_H

YFS_SHIPMENT_H

YFS_SHIPMENT_LINE_H

YFS_SHIPMENT_LINE_REQ_TAG_H

YFS_SHIPMENT_STATUS_AUDIT_H

YFS_SHIPMENT_TAG_SERIAL_H

YFS_CONTAINER_ACTIVITY_H

Shipment Purge
This purge removes shipment data from the system. This reduces the load on
frequently accessed tables. This transaction picks up all shipments that have been
marked as ‘Closed' and archives them into their history tables. See “Shipment
History Purge” on page 493. It also archives and purges the shipment's child
tables.

This is not a pipeline transaction. It also does not work from the task queue.

Any enterprise using the Console must schedule purge transactions.

Orders related to the shipments should have been purged by order purge.
Shipments should have been closed by the Close Shipment transaction. For more
information, see “Close Shipment” on page 379.

You can use purge codes pseudo-logic to analyze purges. If the following
conditions are met, a shipment is picked up for purge:
v The last modification performed on the shipment should fall before the lead
time (in days) setup.
v The value of the ShipmentClosedFlag field should be set to "Y".
v The order record should already be purged for all shipment lines.

Chapter 22. Time-Triggered Transaction Reference 495


Attributes

The following are the attributes for this time-triggered transaction:


Table 345. Shipment Purge Attributes
Attribute Value
Base Transaction ID SHIPMENTPRG
Base Document Type Order
Base Process Type Order Delivery
Abstract Transaction No
APIs Called None
User Exits Called YFSBeforePurgeUE

Criteria Parameters

The following are the criteria parameters for this transaction:


Table 346. Shipment Purge Criteria Parameters
Parameter Description
Action Required. Triggers the transaction.
Number of Records To Optional. Number of records to retrieve and process at one
Buffer time. If left blank or specified as 0 (zero), it defaults to 5000.
Number of Days To Optional. Maximum number of days before the lead days the
Execute agent will look for shipment records to purge.
EnterpriseCode Optional. Enterprise for which the Shipment Purge needs to be
run. If not passed, then all enterprises are monitored.
Live Optional. Mode in which to run. Valid values are:
v Y - Default value. Moves qualifying records from the
regular tables listed under Tables Purged to the
corresponding history tables.
v N - Test mode. Determines the rows that are moved to
history tables without actually moving them.
PurgeCode Required. Cannot be modified. Used for internal calculations,
such as determining retention days. Corresponds with the
PurgeCode used in Business Rules Purge Criteria.
ColonyID Required in a multi schema deployment where a table may
exist in multiple schemas. Runs the agent for the colony.

Statistics Tracked

The following statistics are tracked for this transaction:


Table 347. Shipment Purge Statistics
Statistic Name Description
NumShipmentsPurged Number of Shipments purged.
NumShipmentLinesPurged Number of Shipment Lines purged.

496 Sterling Selling and Fulfillment Foundation: Application Platform Configuration Guide
Pending Job Count

For this transaction, the pending job count is the number of records that can be
purged from the YFS_Shipment table.

Events Raised

None.

Tables Purged

YFS_ADDITIONAL_ATTRIBUTES

YFS_ADDITIONAL_DATE

YFS_AUDIT

YFS_CONTAINER_DETAILS

YFS_LOAD_SHIPMENT_CHARGE

YFS_MONITOR_ALERT

YFS_SHIPMENT_CONTAINER

YFS_SHIPMENT_STATUS_AUDIT

YFS_SHIPMENT

YFS_INSTRUCTION_DETAIL

YFS_SHIPMENT_MONITOR_ALERT

YFS_HEADER_CHARGES

YFS_LINE_CHARGES

YFS_TAX_BREAKUP

YFS_SHIPMENT_HOLD_TYPE

YFS_SHIPMENT_HOLD_TYPE_LOG

YFS_SHIPMENT_TAG_SERIALS

YFS_SHIPMENT_LINE

YFS_SHIPMENT_LINE_REQ_TAG

YFS_ACTIVITY_DEMAND

YFS_CONTAINER_STS_AUDIT

YFS_CONTAINER_ACTIVITY

Chapter 22. Time-Triggered Transaction Reference 497


Shipment Statistics Purge
This transaction deletes the shipment statistics from the table older than the
specified retention days.

This agent should be used whenever shipment statistics records need to be


removed, such as after application server restart.

You can use purge codes pseudo-logic to analyze purges. If the following condition
is met, the shipment statistics are picked up for purge:
v The last modification performed on the shipment statistics should fall before the
lead time (in days) setup.

Attributes

The following are the attributes for this time-triggered transaction:


Table 348. Shipment Statistics Purge Attributes
Attribute Value
Base Transaction ID PRG_SHIP_STATS
Base Document Type Order
Base Process Type Order Delivery
Abstract Transaction No
APIs Called None
User Exits Called YFSBeforePurgeUE

Criteria Parameters

The following are the criteria parameters for this transaction:


Table 349. Shipment Statistics Purge Criteria Parameters
Parameter Description
Action Required. Triggers the transaction. If left blank, it defaults to
Get, the only valid value.
Number of Records To Optional. Number of records to retrieve and process at one
Buffer time. If left blank or specified as 0 (zero), it defaults to 5000.
EnterpriseCode Optional. Enterprise for which the Shipment Statistics Purge
needs to be run. If not passed, then all enterprises are
monitored.
Live Optional. Mode in which to run. Valid values are:
v Y - Default value. Moves qualifying records from the
regular tables listed under Tables Purged to the
corresponding history tables.
v N - Test mode. Determines the rows that are moved to
history tables without actually moving them.
PurgeCode Required. Cannot be modified. Used for internal calculations,
such as determining retention days. Corresponds with the
PurgeCode used in Business Rules Purge Criteria.
ColonyID Required in a multi schema deployment where the
YFS_SHIPMENT_STATISTICS table may exist in multiple
schemas. Runs the agent for the colony.

498 Sterling Selling and Fulfillment Foundation: Application Platform Configuration Guide
Statistics Parameters

The following are the statistics parameters for this transaction:


Table 350. Shipment Statistics Purge Statistics
Parameter Description
NumShipmentStatisticsPurged Number of shipment statistics purged.

Pending Job Count

For this transaction, the pending job count is the number of records that can be
purged from the YFS_SHIPMENT_STATISTICS table.

Events Raised

None.

Tables Purged

YFS_SHIPMENT_STATISTICS

Statistics Purge
This purge removes statistics data from the system. It purges all records older than
the specified retention days.

You can use purge codes pseudo-logic to analyze purges. If the following condition
is met, the statistics detail is picked up for purge:
v The last modification performed on the statistics detail should fall before the
lead time (in days) setup.

This purge only reads the rules defined by the hub. Enterprise overridden rules are
not considered. This purge should be single threaded when you run it in batch
delete mode (BatchDelete=Y).

It is important to run this agent often. In a production environment, the


YFS_STATISTICS_DETAIL table can grow large, very quickly. It does not carry any
old data, therefore it is a good practice to purge it aggressively, from once a day to
once a week, depending on the table size.

Attributes

The following are the attributes for this time-triggered transaction:


Table 351. Statistics Purge Attributes
Attribute Value
Base Transaction ID STATTBLPRG
Base Document Type General
Base Process Type General
Abstract Transaction No
APIs Called None
User Exits Called YFSBeforePurgeUE

Chapter 22. Time-Triggered Transaction Reference 499


Criteria Parameters

The following are the criteria parameters for this transaction:


Table 352. Statistics Purge Criteria Parameters
Parameter Description
Action Required. Triggers the transaction. If left blank, it defaults to
Get, the only valid value.
Number of Records To Optional. Number of records to retrieve and process at one
Buffer time. If left blank or specified as 0 (zero), it defaults to 5000.
Live Optional. Mode in which to run. Valid values are:
v Y - Default value. Moves qualifying records from the
regular tables listed under Tables Purged to the
corresponding history tables.
v N - Test mode. Determines the rows that are moved to
history tables without actually moving them.
BatchDelete Required. The mode in which all records get deleted from the
table. Valid values are:
v Y - Default value. Records are deleted in batches.
v N - Records are deleted one by one.
PurgeCode Required. Cannot be modified. Used for internal calculations,
such as determining retention days. Corresponds with the
PurgeCode used in Business Rules Purge Criteria.
CollectPendingJobs If this parameter is set to "N", the agent does not collect
information on the pending jobs for this monitor. This pending
job information is used for monitoring the monitor in the
System Management.
ColonyID Required in a multi schema deployment where the
YFS_STATISTICS_DETAIL table may exist in multiple schemas.
Runs the agent for the colony.

Statistics Tracked

The following statistics are tracked for this transaction:


Table 353. Statistics Purge Statistics
Statistic Name Description
NumStatisticsPurged Number of statistics purged

Pending Job Count

For this transaction, the pending job count is the number of records that can be
purged from the YFS_STATISTICS_DETAIL table.

Events Raised

None.

Tables Purged

YFS_STATISTICS_DETAIL

500 Sterling Selling and Fulfillment Foundation: Application Platform Configuration Guide
User Activity Purge
This purge deletes the user activity data from the system. It purges all records
older than the specified retention days, and those records which have a logged out
status. This purge must be single threaded when you run it in batch delete mode
(BatchDelete=Y).

The following limitation is assumed when purging records:

This purge do not purge any record if the Application server goes down abruptly
because the audit records of users connected to the application server at the time
when the server went down cannot be updated. As a result, the last activity time
or the logout time is not populated. The purge does not know whether the user
has logged out or still logged in. Therefore, you need to manually delete these
records.

The following are the attributes for this time-triggered transaction:


Table 354. User Activity Purge Attributes
Attribute Value
Base Transaction ID USERACTIVITYPRG
Base Document Type None
Base Process Type None
APIs Called None
User Exits Called None

Criteria Parameters

The following are the criteria parameters for this transaction:


Table 355. User Activity Purge Parameters
Parameter Description
Action Required. Triggers the transaction. If left blank, it defaults to
Get, the only valid value.
PurgeCode Required. Cannot be modified. Used for internal calculations,
such as determining retention days. Corresponds with the
PurgeCode used in Business Rules Purge Criteria.
Live Optional. Mode in which to run. Valid values are:
v Y - Default value. Moves qualifying records from the
regular tables listed under Tables Purged to the
corresponding history tables.
v N - Test mode. Determines the rows that are moved to
history tables without actually moving them.
CollectPendingJobs If this parameter is set to "N", the agent does not collect
information on the pending jobs for this monitor. This
pending job information is used for monitoring the monitor
in the System Management ConsoleSystem Management.
Number of Records To Required. Number of records to retrieve and process at one
Buffer time. If left blank or specified as 0 (zero), it defaults to 100.

Chapter 22. Time-Triggered Transaction Reference 501


Table 355. User Activity Purge Parameters (continued)
Parameter Description
BatchDelete Required. The method by which all records are deleted from
the table. Valid values are:
v Y - Default value. Records are deleted in batches.
v N - Records are deleted one by one.
ColonyID Required in a multi schema deployment where the
YFS_USER_ACTIVITY table may exist in multiple schemas.
Runs the agent for the colony.

Statistics Tracked

The following statistics are tracked for this transaction:


Table 356. Statistics Purge Statistics
Statistic Name Description
NumStatisticsPurged Number of statistics purged

Pending Job Count

None.

Events Raised

None.

Tables Purged

YFS_USER_ACTIVITY

User Activity Audit Purge


This purge removes user activity audit data from the system. It purges all records
older than the specified retention days. It purges only those records which have a
logged out status (records with a Login_Type of ‘T' or ‘N'). This purge should be
single threaded when you run it in batch delete mode(BatchDelete=Y).

The following limitation is assumed when purging records:


v This purge does not purge any records if the Application server goes down
abruptly because the audit records of users connected to application servers at
the time the server went down cannot be updated. As a result, the last activity
time or the logout time does not get populated and the purge does not know
whether the user was logged out or was still logged in. These records have to be
deleted manually.

The following are the attributes for this time-triggered transaction:


Table 357. User Activity Audit Purge Attributes
Attribute Value
Base Transaction ID USERACTAUDPURGE
Base Document Type None

502 Sterling Selling and Fulfillment Foundation: Application Platform Configuration Guide
Table 357. User Activity Audit Purge Attributes (continued)
Attribute Value
Base Process Type None
APIs Called None
User Exits Called None

Criteria Parameters

The following are the criteria parameters for this transaction:


Table 358. User Activity Audit Purge Criteria Parameters
Parameter Description
Action Required. Triggers the transaction. If left blank, it defaults to
Get, the only valid value.
PurgeCode Required. Cannot be modified. Used for internal calculations,
such as determining retention days. Corresponds with the
PurgeCode used in Business Rules Purge Criteria.
Live Optional. Mode in which to run. Valid values are:
v Y - Default value. Moves qualifying records from the
regular tables listed under Tables Purged to the
corresponding history tables.
v N - Test mode. Determines the rows that are moved to
history tables without actually moving them.
CollectPendingJobs If this parameter is set to "N", the agent does not collect
information on the pending jobs for this monitor. This pending
job information is used for monitoring the monitor in the
System Management Console[Application System Management
Console].
Number of Records To Required. Number of records to retrieve and process at one
Buffer time. If left blank or specified as 0 (zero), it defaults to 100.
BatchDelete Required. The method by which all records are deleted from
the table. Valid values are:
v Y - Default value. Records are deleted in batches.
v N - Records are deleted one by one.
ColonyID Required in a multi schema deployment where the
YFS_USER_ACT_AUDIT table may exist in multiple schemas.
Runs the agent for the colony.

Statistics Tracked

The following statistics are tracked for this transaction:


Table 359. Statistics Purge Statistics
Statistic Name Description
NumStatisticsPurged Number of statistics purged

Pending Job Count

None.

Chapter 22. Time-Triggered Transaction Reference 503


Events Raised

None.

Tables Purged

YFS_USR_ACT_AUDIT

Work Order History Purge


This transaction deletes tasks previously archived by the Work Order Purge. See
“Work Order Purge” on page 506.

You can use purge codes pseudo-logic to analyze purges. If the last modified date
of the work order exceeds the retention day period, a work order that is previously
purged by the work order purge agent is picked up for history purge.

Attributes

The following are the attributes for this time-triggered transaction:


Table 360. Work Order History Purge Attributes
Attribute Value
Base Transaction ID WORK_ORDER_HISTORY_PURGE
Base Document Type Work Order
Base Process Type VAS
Abstract Transaction No
APIs Called None
User Exits Called YFSBeforePurgeUE

Criteria Parameters

The following are the criteria parameters for this transaction:


Table 361. Work Order History Purge Criteria Parameters
Parameter Description
Action Required. Triggers the transaction. If left blank, it defaults to
Get, the only valid value.
PurgeCode Required. Cannot be modified. Used for internal calculations,
such as determining retention days. Corresponds with the
PurgeCode used in Business Rules Purge Criteria.
Live Optional. Mode in which to run. Defaults to N.
v Y - Default value. Removes qualifying records from the
history tables listed under Tables Purged.
v N- Test mode. Determines the rows that are removed
without actually removing them.
Number of Records To Optional. Number of records to retrieve and process at one
Buffer time. If left blank or specified as 0 (zero), it defaults to 5000.
Node Optional. Node for which the Work Order History Purge
needs to be run. If not passed, then all nodes are monitored.

504 Sterling Selling and Fulfillment Foundation: Application Platform Configuration Guide
Table 361. Work Order History Purge Criteria Parameters (continued)
Parameter Description
AgentCriteriaGroup Optional. Used to classify nodes. This value can be accepted
by Sterling Warehouse Management System time-triggered
transactions that only perform their tasks on the nodes with a
matching node transactional velocity value.

Valid values are: LOW, HIGH, and any additional values


defined by the Hub from Application Platform > System
Administration > Agent Criteria Groups.
ColonyID Required in a multi schema deployment where a table may
exist in multiple schemas. Runs the agent for the colony.

Statistics Tracked

The following statistics are tracked for this transaction:


Table 362. Work Order History Purge Statistics
Statistic Name Description
NumWorkOrderHistoriesPurged Number of work order histories purged.

Pending Job Count

For this transaction, the pending job count is the number of records that can be
purged from the YFS_WORK_ORDER_H table.

Events Raised

None.

Tables Purged

YFS_AUDIT

YFS_WO_APPT_USER_H

YFS_WORK_ORDER_H

YFS_WORK_ORDER_APPT_H

YFS_WORK_ORDER_ACTIVITY_H

YFS_WORK_ORDER_ACTY_DTL_H

YFS_WORK_ORDER_AUDT_DTL_H

YFS_WORK_ORDER_COMPONENT_H

YFS_WORK_ORDER_COMP_TAG_H

YFS_WORK_ORDER_HOLD_TYPE_H

YFS_WORK_ORDER_HOLD_TYPE_LOG_H

Chapter 22. Time-Triggered Transaction Reference 505


YFS_WORK_ORDER_PROD_DEL_H

YFS_WORK_ORDER_SERVICE_LINE_H

YFS_WORK_ORDER_STS_AUDIT_H

YFS_WORK_ORDER_TAG_H

Work Order Purge


This time-triggered transaction purges all the work orders for a period greater than
the retention days specified in the Work Order Purge criteria and those, which are
either in the status of cancelled or completed.

You can use purge codes pseudo-logic to analyze purges. If the following
conditions are met, a work order is picked up for purge:
v The last modified date of the work order should exceed the retention day
period.
v The order associated with the work order should be purged.
v The work order should be in pickable status by the purge transaction.

Attributes

The following are the attributes for this time-triggered transaction:


Table 363. Work Order Purge Attributes
Attribute Value
Base Transaction ID WORK_ORDER_PURGE
Base Document Type Work Order
Base Process Type VAS
Abstract Transaction No
APIs Called None
User Exits Called YFSBeforePurgeUE

Criteria Parameters

The following are the criteria parameters for this transaction:


Table 364. Work Order Purge Criteria Parameters
Parameter Description
Action Required. Triggers the transaction. If left blank, it defaults to
Get, the only valid value.
PurgeCode Required. Cannot be modified. Used for internal calculations,
such as determining retention days. Corresponds with the
PurgeCode used in Business Rules Purge Criteria.
Live Optional. Mode in which to run. Defaults to Y.
v Y - Default value. Moves qualifying records from the
regular tables listed under Tables Purged to the
corresponding history tables.
v N - Test mode. Determines the rows that are moved to
history tables without actually moving them.

506 Sterling Selling and Fulfillment Foundation: Application Platform Configuration Guide
Table 364. Work Order Purge Criteria Parameters (continued)
Parameter Description
Number of Records To Optional. Number of records to retrieve and process at one
Buffer time. If left blank or specified as 0 (zero), it defaults to 5000.
Node Optional. Node for which the Work Order Purge needs to be
run. If not passed, then all nodes are monitored.
AgentCriteriaGroup Optional. Used to classify nodes. This value can be accepted
by Sterling Warehouse Management System time-triggered
transactions that only perform their tasks on the nodes with a
matching node transactional velocity value.

Valid values are: LOW, HIGH, and any additional values


defined by the Hub from Application Platform > System
Administration > Agent Criteria Groups.
ColonyID Required in a multi schema deployment where a table may
exist in multiple schemas. Runs the agent for the colony.

Statistics Tracked

The following statistics are tracked for this transaction:


Table 365. Work Order Purge Statistics
Statistic Name Description
NumWorkOrdersPurged Number of work orders purged.

Pending Job Count

For this transaction, the pending job count is the number of records that can be
purged from the YFS_WORK_ORDER table.

Events Raised

None.

Tables Purged

YFS_AUDIT

YFS_WO_APPT_USER

YFS_WORK_ORDER

YFS_WORK_ORDER_ACTIVITY

YFS_WORK_ORDER_ACTY_DTL

YFS_WORK_ORDER_HOLD_TYPE

YFS_WORK_ORDER_HOLD_TYPE_LOG

YFS_WORK_ORDER_APPT

YFS_WORK_ORDER_AUDT_DTL

Chapter 22. Time-Triggered Transaction Reference 507


YFS_WORK_ORDER_COMPONENT

YFS_WORK_ORDER_COMP_TAG

YFS_WORK_ORDER_PROD_DEL

YFS_WORK_ORDER_SERVICE_LINE

YFS_WORK_ORDER_STS_AUDIT

YFS_WORK_ORDER_TAG

YFS Audit Purge


This purge removes the YFS_AUDIT table data from the system, which reduces the
load on frequently accessed tables. It purges records in the YFS_AUDIT and the
YFS_AUDIT_HEADER tables that meet the following conditions:
v YFS_AUDIT records that have ‘modifyts' greater than the retention days
specified and the value of table name matches in the YFS_AUDIT table.
v The last modified time is before the lead time (in days) setup.

The way you configure the YFS Audit Purge may have some effect on the
functioning of the Configuration Data Versioning Tool. For more information about
configuration of the Data Versioning Tool, see the Sterling Selling and Fulfillment
Foundation: Configuration Deployment Tool Guide.

When the enterprise extends the entities and sets the extended entities attribute
AuditTable="Y", the extended tables are audited and the audit records are inserted
in the YFS_AUDIT table. In order to clean up the audit records, this purge
transaction can be used.

Any enterprise using the Console must schedule purge transactions.

Attributes

The following are the attributes for this time-triggered transaction:


Table 366. YFS Audit Purge Attributes
Attribute Value
Base Transaction ID YFS_AUDIT_PURGE
Base Document Type General
Base Process Type General
Abstract Transaction No
APIs Called None
User Exits Called YFSBeforePurgeUE

508 Sterling Selling and Fulfillment Foundation: Application Platform Configuration Guide
Criteria Parameters

The following are the criteria parameters for this transaction:


Table 367. YFS Audit Purge Criteria Parameters
Parameter Description
Action Required. Triggers the transaction. If left blank, this value
defaults to Get, the only valid value.
Number of Records To Optional. Number of records to retrieve and process at one
Buffer time. If left blank or specified as 0 (zero), this value defaults
to 5000.
Live Optional. Mode in which to run. Valid values are:
v Y - Default value. Production mode. Deletes records from
the regular tables.
v N - Test mode.
PurgeCode Required. Cannot be modified. Used for internal calculations,
such as determining retention days. Corresponds with the
PurgeCode used in Business Rules Purge Criteria.
Table Name Required. The table name for which the audit records need to
be purged.
TableType Required in a multischema deployment when YFS_AUDIT
table may exist in multiple schemas.

Valid Values: CONFIGURATION, TRANSACTION, MASTER.

If set to CONFIGURATION, the agent runs for the


YFS_AUDIT records associated with tables that have
TableType as CONFIGURATION; for example,
YFS_Organization, YFS_Ship_Node, and so forth.

If set to TRANSACTION, the agent runs for the YFS_AUDIT


records associated with tables that have TableType as
TRANSACTION; for example, YFS_Order_Header,
YFS_Shipment, and so forth.

Note that the agent would run for all TableTypes that exist in
the same schema as the one passed. For example, if set to
TRANSACTION, the agent would also run for YFS_AUDIT
records associated with tables that have TableType as
MASTER, since they reside in the same schema.
ColonyID Required in a multi schema deployment where the
YFS_AUDIT and YFS_AUDIT_HEADER tables may exist in
multiple schemas. Runs the agent for the colony.

Statistics Tracked

The following statistics are tracked for this transaction:


Table 368. YFS Audit Purge Statistics
Statistic Name Description
NumAuditRecordsPurged Number of audit records purged.

Chapter 22. Time-Triggered Transaction Reference 509


Pending Job Count

For this transaction, the pending job count is the number of records that can be
purged from the YFS_AUDIT table that match the criteria values.

Events Raised

None.

Tables Purged

YFS_AUDIT, YFS_AUDIT_HEADER

YFSInventoryOwnershipAudit Purge
This transaction purges all the records from YFS_INV_OWN_TRANSFER_RCD
prior to the lead days specified in criteria parameters.

Attributes

Following are the attributes for this time-triggered transaction:


Table 369. YFSInventoryOwnership Purge Attributes
Attribute Value
Base Transaction ID PURGE_INV_TRANSFR_RECORD
Base Document Type General
Base Process Type General
Abstract Transaction No
APIs Called None
User Exits Called None

Criteria Parameters

Following are the criteria parameters for this transaction:


Table 370. YFSInventoryOwnership Purge Criteria Parameters
Parameter Description
Action Required. Triggers the transaction. If left blank, this value
defaults to Get, which is the only valid value.
Number of Records To Optional. Number of records to retrieve and process at one
Buffer time. If left blank or specified as 0 (zero), this value defaults
to 5000.
EnterpriseCode Optional. The inventory organization for which the
YFSInventoryOwnership Audit Purge needs to run. If not
passed, all the enterprises are monitored.
Live Optional. Mode in which to run. Valid values are:
v Y - Default value. Production mode. Deletes records from
the regular tables.
v N - Test mode.
PurgeCode Required. Cannot be modified. Used for internal calculations,
such as determining retention days. Corresponds to the
PurgeCode used in the Business Rules Purge Criteria.

510 Sterling Selling and Fulfillment Foundation: Application Platform Configuration Guide
Table 370. YFSInventoryOwnership Purge Criteria Parameters (continued)
Parameter Description
Lead Days Number of days before the present date, the agent will purge
the records.
ColonyID Required in a multi schema deployment where the
YFS_INV_OWN_TRANSFER_RCD table may exist in multiple
schemas. Runs the agent for the colony.

Statistics Tracked

None.

Pending Job Count

None.

Tables Purged

YFS_INV_OWN_TRANSFER_RCD

Password Reset Request Purge


This purge deletes password reset request data from the system.

You can use purge codes pseudo-logic to analyze purges.

Any enterprise using the Console must schedule purge transactions.

Attributes

The following are the attributes for this time-triggered transaction:


Table 371. Password Reset Request Purge Attributes
Attribute Value
Base Transaction ID None
Base Document Type General
Base Process Type General
Abstract Transaction No
APIs Called None
User Exits Called None

Criteria Parameters

The following are the criteria parameters for this transaction:


Table 372. Password Reset Request Purge Criteria Parameters
Parameter Description
Action Required. Triggers the transaction. If left blank, it defaults to
Get, the only valid value.
Number of Records To Optional. Number of records to retrieve and process at one
Buffer time. If left blank or specified as 0 (zero), it defaults to 5000.

Chapter 22. Time-Triggered Transaction Reference 511


Table 372. Password Reset Request Purge Criteria Parameters (continued)
Parameter Description
Live Optional. Mode in which to run. Valid values are:
v Y - Default value. Moves qualifying records from the
regular tables listed under Tables Purged to the
corresponding history tables.
v N - Test mode. Determines the rows that are moved to
history tables without actually moving them.
PurgeCode Required. Cannot be modified. Used for internal calculations,
such as determining retention days. Corresponds with the
PurgeCode used in Business Rules Purge Criteria.
ColonyID Required in a multi schema deployment where the
PLT_PWD_REQ table may exist in multiple schemas. Runs the
agent for the colony.

Statistics Tracked

The following statistics are tracked for this transaction:


Table 373. Password Reset Request Purge Statistics
Statistic Name Description
NumPasswordRequestPurged Number of password requests purged.

Pending Job Count

For this transaction, the pending job count is the number of records that can be
purged from the PLT_PWD_REQ table.

Events Raised

None.

Tables Purged

PLT_PWD_REQ

User Login Failure Purge


This purge deletes data on number of failed login attempts of users from the
system.

You can use purge codes pseudo-logic to analyze purges.

Any enterprise using the Console must schedule purge transactions.

Attributes

The following are the attributes for this time-triggered transaction:


Table 374. User Login Failure Purge Attributes
Attribute Value
Base Transaction ID None

512 Sterling Selling and Fulfillment Foundation: Application Platform Configuration Guide
Table 374. User Login Failure Purge Attributes (continued)
Attribute Value
Base Document Type General
Base Process Type General
Abstract Transaction No
APIs Called None
User Exits Called None

Criteria Parameters

The following are the criteria parameters for this transaction:


Table 375. User Login Failure Purge Criteria Parameters
Parameter Description
Action Required. Triggers the transaction. If left blank, it defaults to
Get, the only valid value.
Number of Records To Optional. Number of records to retrieve and process at one
Buffer time. If left blank or specified as 0 (zero), it defaults to 5000.
Live Optional. Mode in which to run. Valid values are:
v Y - Default value. Moves qualifying records from the
regular tables listed under Tables Purged to the
corresponding history tables.
v N - Test mode. Determines the rows that are moved to
history tables without actually moving them.
PurgeCode Required. Cannot be modified. Used for internal calculations,
such as determining retention days. Corresponds with the
PurgeCode used in Business Rules Purge Criteria.
ColonyID Required in a multi schema deployment where the
PLT_USER_LOGIN_FAILED table may exist in multiple
schemas. Runs the agent for the colony.

Statistics Tracked

The following statistics are tracked for this transaction:


Table 376. User Login Failure Purge Statistics
Statistic Name Description
NumUserLoginFailPurged Number of failed login attempts purged.

Pending Job Count

For this transaction, the pending job count is the number of records that can be
purged from the PLT_USER_LOGIN_FAILED table.

Events Raised

None.

Chapter 22. Time-Triggered Transaction Reference 513


Tables Purged

PLT_USER_LOGIN_FAILED

Task Queue Syncher Time-Triggered Transactions


Many transactions use the task queue as their work repository. The workflow
manager automatically creates tasks for transactions to handle the next processing
step, as configured in your pipeline.

In some situations, the task queue repository may become out of date. For
example, when reconfiguring the processing pipeline while the pipeline is active,
the queue may go out of synch with the new pipeline configuration.

Alerts that indicate a halt in the lifecycle of a business document may indicate an
out-dated task queue repository.

The task queue syncher transactions are designed to update the task queue
repository with the latest list of open tasks to be performed by each transaction,
based on the latest pipeline configuration.

Some of the statistics collected and tracked in Release 9.1 for time-triggered
transactions, monitors, and integration and application servers may change with
the next release.

Load Execution Task Queue Syncher


This transaction synchronizes the task queue for the load execution process type.

You can use the following pseudo-logic to analyze this time-triggered transaction.
If the following conditions are met, a task queue for the load execution process
type is synchronized:
v LOAD_CLOSED_FLAG of Load should not be 'Y'.
v Load should be in a status that is pickable by a transaction in the pipeline.
v There should not be any Task Q record for the load, transaction combination in
the Task Q table. In this case, the system inserts one Task Q record for this load,
transaction combination with the current database time as the available date.

Attributes

The following are the attributes for this time-triggered transaction:


Table 377. Load Execution Task Queue Syncher Attributes
Attribute Value
Base Transaction ID TASK_QUEUE_SYNCHER_L_D
Base Document Type Load
Base Process Type Load Execution
Abstract Transaction No
APIs Called None

514 Sterling Selling and Fulfillment Foundation: Application Platform Configuration Guide
Criteria Parameters

The following are the criteria parameters for this transaction:


Table 378. Load Execution Task Queue Syncher Criteria Parameters
Parameter Description
Action Required. Triggers the transaction. If left blank, it defaults to
Get, the only valid value.
Number of Records To Optional. Number of records to retrieve and process at one
Buffer time. If left blank or specified as 0 (zero), it defaults to 5000.
ColonyID Required in a multi schema deployment where a table may
exist in multiple schemas. Runs the agent for the colony.

Statistics Tracked

The following statistics are tracked for this transaction:


Table 379. Load Execution Task Queue Syncher Statistics
Statistic Name Description
NumTasksCreated Number of tasks created.

Pending Job Count

None.

Events Raised

None.

Order Delivery Task Queue Syncher


This transaction synchronizes the order delivery process type.

Attributes

The following are the attributes for this time-triggered transaction:


Table 380. Order Delivery Task Queue Syncher Attributes
Attribute Value
Base Transaction ID TASK_QUEUE_SYNCHER_O_D
Base Document Type Order
Base Process Type Order Delivery
Abstract Transaction No
APIs Called None

Chapter 22. Time-Triggered Transaction Reference 515


Criteria Parameters

The following are the criteria parameters for this transaction:


Table 381. Order Delivery Task Queue Syncher Criteria Parameters
Parameter Description
Action Required. Triggers the transaction. If left blank, it defaults to
Get, the only valid value.
Number of Records To Optional. Number of records to retrieve and process at one
Buffer time. If left blank or specified as 0 (zero), it defaults to 5000.
ColonyID Required in a multi schema deployment where a table may
exist in multiple schemas. Runs the agent for the colony.

Statistics Tracked

The following statistics are tracked for this transaction:


Table 382. Order Delivery Task Queue Syncher Statistics
Statistic Name Description
NumTasksCreated Number of tasks created.

Pending Job Count

None.

Events Raised

None.

Order Fulfillment Task Queue Syncher


This transaction synchronizes the order fulfillment process type.

Attributes

The following are the attributes for this time-triggered transaction:


Table 383. Order Fulfillment Task Queue Syncher Attributes
Attribute Value
Base Transaction ID TASK_QUEUE_SYNCHER_O_F
Base Document Type Order
Base Process Type Order Fulfillment
Abstract Transaction No
APIs Called None

516 Sterling Selling and Fulfillment Foundation: Application Platform Configuration Guide
Criteria Parameters

The following are the criteria parameters for this transaction:


Table 384. Order Fulfillment Task Queue Syncher Criteria Parameters
Parameter Description
Action Required. Triggers the transaction. If left blank, it defaults to
Get, the only valid value.
Number of Records To Optional. Number of records to retrieve and process at one
Buffer time. If left blank or specified as 0 (zero), it defaults to 5000.
ColonyID Required in a multi schema deployment where a table may
exist in multiple schemas. Runs the agent for the colony.

Statistics Tracked

The following statistics are tracked for this transaction:


Table 385. Order Fulfillment Task Queue Syncher Statistics
Statistic Name Description
NumTasksCreated Number of tasks created.

Pending Job Count

None.

Events Raised

None.

Order Negotiation Task Queue Syncher


This transaction synchronizes the order negotiation process type.

Attributes

The following are the attributes for this time-triggered transaction:


Table 386. Order Negotiation Task Queue Syncher Attributes
Attribute Value
Base Transaction ID TASK_QUEUE_SYNCHER_O_N
Base Document Type Order
Base Process Type Order Negotiation
Abstract Transaction No
APIs Called None

Chapter 22. Time-Triggered Transaction Reference 517


Criteria Parameters

The following are the criteria parameters for this transaction:


Table 387. Order Negotiation Task Queue Syncher Criteria Parameters
Parameter Description
Action Required. Triggers the transaction. If left blank, it defaults to
Get, the only valid value.
Number of Records To Optional. Number of records to retrieve and process at one
Buffer time. If left blank or specified as 0 (zero), it defaults to 5000.
ColonyID Required in a multi schema deployment where a table may
exist in multiple schemas. Runs the agent for the colony.

Statistics Tracked

The following statistics are tracked for this transaction:


Table 388. Order Negotiation Task Queue Syncher Statistics
Statistic Name Description
NumTasksCreated Number of tasks created.

Pending Job Count

None.

Events Raised

None.

Quote Fulfillment Task Queue Syncher


This transaction synchronizes the quote fulfillment process type.

Attributes

The following are the attributes for this time-triggered transaction:


Table 389. Quote Fulfillment Task Queue Syncher Attributes
Attribute Value
Base Transaction ID TASK_QUEUE_SYNCHER_Q_F
Base Document Type Order
Base Process Type Quote Fulfillment
Abstract Transaction No
APIs Called None

518 Sterling Selling and Fulfillment Foundation: Application Platform Configuration Guide
Criteria Parameters

The following are the criteria parameters for this transaction:


Table 390. Quote Fulfillment Task Queue Syncher Criteria Parameters
Parameter Description
Action Required. Triggers the transaction. If left blank, it defaults to
Get, the only valid value.
Number of Records To Optional. Number of records to retrieve and process at one
Buffer time. If left blank or specified as 0 (zero), it defaults to 5000.
ColonyID Required in a multi schema deployment where a table may
exist in multiple schemas. Runs the agent for the colony.

Statistics Tracked

The following statistics are tracked for this transaction:


Table 391. Quote Fulfillment Task Queue Syncher Statistics
Statistic Name Description
NumTasksCreated Number of tasks created.

Pending Job Count

None.

Events Raised

None.

Monitors
Monitors are transactions that watch for processes or circumstances that are out of
bounds and then raise alerts.

Some of the statistics collected and tracked in Release 9.1 for time-triggered
transactions, monitors, and integration and application servers may change with
the next release of Sterling Selling and Fulfillment Foundation.

All Monitors have a CollectPendingJobs criteria parameter. If this parameter is set


to N, the agent does not collect information on the pending jobs for that monitor.
This pending job information is used for monitoring the monitor in the System
Management ConsolePlatform System Management and Administration Guide. By
default, CollectPendingJobs is set to Y. It can be helpful to set it to N if one
monitor is performing a significant amount of getPendingJobs queries and the
overhead cost is too high.

Availability Monitor
This time-triggered transaction monitors inventory availability. The Availability
Monitor raises global alerts when the available inventory falls below the
configured quantities on the current day, on subsequent days within the ATP time
frame, and on subsequent days outside of the ATP time frame. The quantities for
the days outside of the ATP time frame are determined by the maximum

Chapter 22. Time-Triggered Transaction Reference 519


monitoring days. Unlike the schedule and release transactions, the Availability
Monitor calculates the actual availability beyond the ATP horizon and does not
assume infinite inventory.

Attributes

The following are the attributes for this time-triggered transaction:


Table 392. Availability Monitor Attributes
Attribute Value
Base Transaction ID ATP_MONITOR
Base Document Type General
Base Process Type General
Abstract Transaction No
APIs Called None

Criteria Parameters

The following are the criteria parameters for this monitor:


Table 393. Availability Monitor Criteria Parameters
Parameter Description
Action Required. Triggers the transaction. If left blank, it
defaults to Get, the only valid value.
MonitorOption Optional. Specifies how to monitor inventory. Valid
values are:
v 1 - current inventory
v 0 - inventory within and outside of the ATP time
frame. This is the default value.
Number of Records To Buffer Optional. Number of records to retrieve and process
at one time. If left blank or specified as 0 (zero), it
defaults to 5000.
InventoryOrganizationCode Optional. Valid owner inventory organization.
Organization to process in this run. If not passed,
all inventory organizations are processed.
CollectPendingJobs If this parameter is set to N, the agent does not
collect information on the pending jobs for this
monitor. This pending job information is used for
monitoring the monitor in the System Management
Console.
Status The negotiation status you are monitoring.
ColonyID Required in a multi schema deployment where a
table may exist in multiple schemas. Runs the agent
for the colony.

Statistics Tracked

None.

520 Sterling Selling and Fulfillment Foundation: Application Platform Configuration Guide
Pending Job Count

None.

Events Raised

No events are raised. Individual actions associated with the monitoring rule are
run.

Data published to the actions is AVAILABILITY_MONITOR_dbd.txt.

Exception Monitor
This time-triggered transaction monitors exceptions in your system as noted below.
It monitors the exceptions logged in the system and escalates these exceptions:
v If an exception has not been assigned to a user by a certain time
v If an exception has not been resolved by a certain time
v If the active size of the queue is more than a certain maximum size

In order to prevent re-alerts on exceptions during every run of the Exception


Monitor, specify a re-alert interval through Alert Management in the Applications
Manager. This attribute is associated with a queue and can be configured for each
queue.

Attributes

The following are the attributes for this time-triggered transaction:


Table 394. Exception Monitor Attributes
Attribute Value
Base Transaction ID EXCEPTION_MONITOR
Base Document Type General
Base Process Type General
Abstract Transaction No
APIs Called None

Criteria Parameters

The following are the criteria parameters for this monitor:


Table 395. Exception Monitor Criteria Parameters
Parameter Description
Action Required. Triggers the transaction.
Number of Records To Optional. Number of records to retrieve and process at one
Buffer time. If left blank or specified as 0 (zero), it defaults to 5000.
QueueID Optional. Defines the Alert Queue into which exceptions from
this monitor are stored.
OrganizationCode Optional. Organization to process in this run. If not passed, all
inventory organizations are processed.

Chapter 22. Time-Triggered Transaction Reference 521


Table 395. Exception Monitor Criteria Parameters (continued)
Parameter Description
CollectPendingJobs If this parameter is set to N, the agent does not collect
information on the pending jobs for this monitor. This pending
job information is used for monitoring the monitor in the
System Management Console.
QueueGroup Optional. Defines the set of Queues for which the exceptions
will be monitored. If both QueueId and QueueGroup are
supplied, QueueId is ignored.
ColonyID Required in a multi schema deployment where a table may
exist in multiple schemas. Runs the agent for the colony.

Statistics Tracked

The following statistics are tracked for this transaction:


Table 396. Exception Monitor Statistics
Statistic Name Description
NumInboxProcessed Number of alerts processed.
NumExceededQueueSizeAlerts Number of actions raised when the number of
unresolved alerts exceeds the queue's maximum
active size.
NumUnResolvedAlerts Number of actions raised when the unresolved
alert time of an alert exceeds the queue's resolution
time.
NumUnAssignedAlerts Number of actions raised when the unassigned
alert time of an alert exceeds the queue's
assignment time.

Pending Job Count

None.

Events Raised

No events are raised. Individual actions associated with the monitoring rule are
run.

Inventory Monitor
This time-triggered transaction monitors inventory availability at ship node level. It
raises alerts at the ship node level when the available inventory exceeds or drops
below the configured quantities.

This monitor uses the OPEN_ORDER demand type to calculate available inventory
at a given node. All supplies assigned to a supply type that is considered by the
OPEN_ORDER demand type are considered. For more information about
configuring inventory supply and demand considerations, refer to the Sterling
Selling and Fulfillment Foundation: Global Inventory Visibility Configuration Guide.

522 Sterling Selling and Fulfillment Foundation: Application Platform Configuration Guide
Attributes

The following are the attributes for this time-triggered transaction:


Table 397. Inventory Monitor Attributes
Attribute Value
Base Transaction ID INVENTORY_MONITOR
Base Document Type General
Base Process Type General
Abstract Transaction No
APIs Called checkAvailability()

Criteria Parameters

The following are the criteria parameters for this monitor:


Table 398. Inventory Monitor Criteria Parameters
Parameter Description
Action Required. Triggers the transaction. If left blank, it
defaults to Get, the only valid value.
Number of Records To Buffer Optional. Number of records to retrieve and process
at one time. If left blank or specified as 0 (zero), it
defaults to 5000.
InventoryOrganizationCode Optional. Valid inventory owner organization.
Organization to process in this run. If not passed, all
inventory organizations are processed.
CollectPendingJobs If this parameter is set to N, the agent does not
collect information on the pending jobs for this
monitor. This pending job information is used for
monitoring the monitor in the System Management
Console.
AllowedOverriddenCriteria If this parameter is set to Y, the overriding value for
the agent criteria parameters can be provided in the
command line in the following format when
triggering the agent:
<AgentCriteriaAttribute>
<OverriddenValue>

For more information about passing these attributes,


see the Sterling Selling and Fulfillment Foundation:
Installation Guide
ShipNodes Optional. Comma-separated list of valid ship nodes
that should be processed in this run. If not passed,
all the ship nodes are processed.
ColonyID Required in a multi schema deployment where a
table may exist in multiple schemas. Runs the agent
for the colony.

Statistics Tracked

None.

Chapter 22. Time-Triggered Transaction Reference 523


Pending Job Count

None.

Events Raised

No events are raised. Individual actions associated with the monitoring rule are
run.

Data published to the actions is <INSTALL_DIR>/xapidocs/api_javadocs/dbd/


INVENTORY_MONITOR_dbd.txt.

Negotiation Monitor
This time-triggered transaction alerts the Enterprise when a negotiation remains in
a particular status for a specific amount of time. This also monitors the negotiation
expiration date. This time-triggered transaction invokes the actions configured
against the negotiation statuses. Configure status Expired (2000) to monitor
negotiation expiration date.

Use this monitor in environments where Order or order release has to go through
a negotiation phase and you want to monitor the negotiation.

Attributes

The following are the attributes for this time-triggered transaction:


Table 399. Negotiation Monitor Attributes
Attribute Value
Base Transaction ID ORD_NEGOTIATION_MONITOR
Base Document Type Order
Base Process Type Order Negotiation
Abstract Transaction No
APIs Called None

Criteria Parameters

The following are the criteria parameters for this monitor:


Table 400. Negotiation Monitor Criteria Parameters
Parameter Description
Action Required. Triggers the transaction. If left blank, it defaults to
Get, the only valid value.
Number of Records To Optional. Number of records to retrieve and process at one
Buffer time. If left blank or specified as 0 (zero), it defaults to 5000.
EnterpriseCode Optional. Enterprise for which the Negotiation Monitor needs
to be run. If not passed, then all enterprises are monitored.
CollectPendingJobs If this parameter is set to N, the agent does not collect
information on the pending jobs for this monitor. This pending
job information is used for monitoring the monitor in the
System Management Console.
Status The negotiation status you are monitoring.

524 Sterling Selling and Fulfillment Foundation: Application Platform Configuration Guide
Table 400. Negotiation Monitor Criteria Parameters (continued)
Parameter Description
ColonyID Required in a multi schema deployment where a table may
exist in multiple schemas. Runs the agent for the colony.

Statistics Tracked

The following statistics are tracked for this transaction:


Table 401. Negotiation Monitor Statistics
Statistic Name Description
NumNegotiationsProcessed Number of negotiations processed.
NumNegotiationsRequiringAlert Number of negotiations which have at least one
alert raised.

Pending Job Count

None.

Events Raised

This invokes the actions configured against the negotiation statuses.

Key Data - Not Applicable.

Data Published - YCP_getNegotiationDetails_output.xml

Enhanced Order Monitor


The enhanced order monitor enables you to monitor the following situations:
v Milestone x has not been reached y hours before a given date type.
v Milestone x has not been reached within y hours of a given date type.
v Milestone x has not been reached within y hours of milestone z.
v Milestone x has been reached y hours before a given date type.
v Milestone x has been reached within y hours of a given date type.
v Milestone x has been reached within y hours after milestone z.
v The order has been in status x for y hours.
v Date type x is y hours before date type z.
v Date type x is y hours after date type z.
v The order has been in hold type x for y hours.
v The order has been in hold type x for y hours before date type z.

The order monitor can be configured to monitor the following system date types
for and Purchase Order document types:
v Actual Order Date - Read from the ORDER_DATE column of the
YFS_ORDER_HEADER table.
v Actual Next Iteration Date - Read from the NEXT_ITER_DATE column of the
YFS_ORDER_HEADER table.

Chapter 22. Time-Triggered Transaction Reference 525


v Requested Ship Date - If there is an order release, read from the
REQ_SHIP_DATE column of the YFS_ORDER_RELEASE table. Otherwise, read
from the REQ_SHIP_DATE of the YFS_ORDER_LINE table.
v Expected Ship Date - Read from the EXPECTED_SHIPMENT_DATE column of
the YFS_ORDER_LINE_SCHEDULE table. If it is null, uses the same logic as
Requested Ship Date.
v Actual Ship Date - If the date is before 01/01/2500, read from he
EXPECTED_SHIPMENT_DATE column of the YFS_ORDER_LINE_SCHEDULE
table. If the date is on or after 01/01/2500, this date type is returned as null.
v Requested Delivery Date - If there is a release, read from the
REQ_DELIVERY_DATE column of the YFS_ORDER_RELEASE table.
v Expected Delivery Date - Read from the EXPECTED_DELIVERY_DATE column
of the YFS_ORDER_LINE_SCHEDULE table. If it is null, uses the same logic as
Requested Delivery Date.
v Actual Delivery Date - If the date is before 01/01/2500, read from he
EXPECTED_DELIVERY_DATE column of the YFS_ORDER_LINE_SCHEDULE
table. If the date is on or after 01/01/2500, this date type is returned as null.
For Order Fulfillment, Planned Order Execution, Reverse Logistics, and Purchase
Order Execution pipelines, the system defined dates such as Shipment and
Delivery are stored without a time component. Therefore when you configure a
rule using these dates, all time computations are carried out assuming they are
always 12:00:00 AM.

For more information about milestones, date types, and monitoring rules, refer to
the Sterling Selling and Fulfillment Foundation: Supply Collaboration Configuration
Guide, the , and the Sterling Selling and Fulfillment Foundation: Reverse Logistics
Configuration Guide.

If you run the Enhanced Order Monitor, you must configure and run the Close
Order time-triggered transaction in all applicable pipelines. For more information
about the Close Order time-triggered transaction, see “Close Order” on page 376.

The same relog interval is used for all document types

Attributes

The following are the attributes for this time-triggered transaction:


Table 402. Enhanced Order Monitor Attributes
Attribute Value
Base Transaction ID ORDER_MONITOR_EX
Base Document Type Order
Base Process Type Order Fulfillment
Abstract Transaction No
APIs Called None

526 Sterling Selling and Fulfillment Foundation: Application Platform Configuration Guide
Criteria Parameters

The following are the criteria parameters for this monitor:


Table 403. Enhanced Order Monitor Criteria Parameters
Parameter Description
Action Required. Triggers the transaction. If left blank, it defaults to
Get, the only valid value.
Number of Records To Optional. Number of records to retrieve and process at one
Buffer time. If left blank or specified as 0 (zero), it defaults to 5000.
EnterpriseCode Optional. Enterprise for which the Order Monitor needs to be
run. If not passed, then all enterprises are monitored.
ColonyID Required in a multi schema deployment where a table may
exist in multiple schemas. Runs the agent for the colony.

Statistics Tracked

The following statistics are tracked for this monitor:


Table 404. Enhanced Order Monitor Statistics
Statistic Name Description
NumOrdersProcessed Number of orders processed.
NumAlertsRaised Number of alerts raised.

Pending Job Count

For this transaction the pending job count is the number of open orders with the
value of NEXT_ALERT_TS less than or equal to (<=) the current date.

Events Raised

The Enhance Order Monitor transaction raises the ON_AUTO_CANCEL event, but
does not cancel the order. A service on this event should be configured to cancel
the order.
Table 405. Events Raised by the Enhanced Order Monitor Transaction
Template
Transaction/Event Key Data Data Published* Support?
ON_AUTO_CANCEL ORDER_ YFS_ORDER_MONITOR_EX.ON_ Yes
MONITOR AUTO_CANCEL.html
_dbd.txt
* These files are located in the following directory:
<INSTALL_DIR>/xapidocs/api_javadocs/XSD/HTML

Monitor Rule's Condition Template

If a monitor rule contains a condition, the <INSTALL_DIR>/repository/xapi/


template/source/smcfs/monitor/ORDER_MONITOR_EX_CONDITION.xml template file is
used to obtain both the order details and the evaluating monitor rule details. See
the provided <INSTALL_DIR>/repository/xapi/template/source/smcfs/monitor/
ORDER_MONITOR_EX_CONDITION.xml.sample file for more details.

Chapter 22. Time-Triggered Transaction Reference 527


If the <INSTALL_DIR>/repository/xapi/template/source/smcfs/monitor/
ORDER_MONITOR_EX_CONDITION.xml template file does not exist, the
MonitorConsolidation->Order element of the default monitor template, the
<INSTALL_DIR>/repository/xapi/template/source/smcfs/monitor/
ORDER_MONITOR_EX.xml file, is used.

If the default monitor template is used, the MonitorConsolidation->


Order->OrderStatuses-> OrderStatus-> MonitorRule element is ignored and is not
passed into the condition.

Enhanced Quote Monitor


The enhanced quote monitor enables you to monitor the following situations:
v Milestone x has not been reached y hours before a given date type.
v Milestone x has not been reached within y hours of a given date type.
v Milestone x has not been reached within y hours of milestone z.
v Milestone x has been reached y hours before a given date type.
v Milestone x has been reached within y hours of a given date type.
v Milestone x has been reached within y hours after milestone z.
v The order has been in status x for y hours.
v Date type x is y hours before date type z.
v Date type x is y hours after date type z.

The quote monitor can be configured to monitor the following system date types:
v Actual Expiration Date - Read from the EXPIRATION_DATE column of the
YFS_ORDER_HEADER table.

For more information about milestones, date types, and monitoring rules, refer to
the .

If you run the Enhanced Quote Monitor, you must configure and run the Close
Order time-triggered transaction in all applicable pipelines. For more information
about the Close Order time-triggered transaction, see “Close Order” on page 376.

The same relog interval is used for all document types.

Attributes

The following are the attributes for this time-triggered transaction:


Table 406. Enhanced Quote Monitor Attributes
Attribute Value
Transaction ID ORDER_MONITOR_EX.0015
Document Type Quote
Process Type Quote Fulfillment
Abstract Transaction No
APIs Called None

528 Sterling Selling and Fulfillment Foundation: Application Platform Configuration Guide
Criteria Parameters

The following are the criteria parameters for this monitor:


Table 407. Enhanced Quote Monitor Criteria Parameters
Parameter Description
Action Required. Triggers the transaction. If left blank, it defaults to
Get, the only valid value.
Number of Records To Optional. Number of records to retrieve and process at one
Buffer time. If left blank or specified as 0 (zero), it defaults to 5000.
EnterpriseCode Optional. Enterprise for which the Quote Monitor needs to be
run. If not passed, then all enterprises are monitored.
CollectPendingJobs If this parameter is set to N, the agent does not collect
information on the pending jobs for this monitor. This pending
job information is used for monitoring the monitor in the
System Management Console.
ColonyID Required in a multi schema deployment where a table may
exist in multiple schemas. Runs the agent for the colony.

Statistics Tracked

The following statistics are tracked for this monitor:


Table 408. Enhanced Quote Monitor Statistics
Statistic Name Description
NumOrdersProcessed Number of quotes processed.
NumAlertsRaised Number of alerts raised.

Pending Job Count

For this transaction the pending job count is the number of open orders with the
value of NEXT_ALERT_TS less than or equal to (<=) the current date.

Events Raised

No events are raised. Individual actions associated with the monitoring rule are
run.

The data published is ORDER_MONITOR_EX.0015.xml.

Monitor Rule's Condition Template

If a monitor rule contains a condition, the <INSTALL_DIR>/repository/xapi/


template/source/smcfs/monitor/ORDER_MONITOR_EX_CONDITION.xml template file is
used to obtain both the order details and the evaluating monitor rule details. See
the provided <INSTALL_DIR>/repository/xapi/template/source/smcfs/monitor/
ORDER_MONITOR_EX_CONDITION.xml.sample file for more details.

If the <INSTALL_DIR>/repository/xapi/template/source/smcfs/monitor/
ORDER_MONITOR_EX_CONDITION.xml template file does not exist, the
MonitorConsolidation->Order element of the default monitor template, the
<INSTALL_DIR>/repository/xapi/template/source/smcfs/monitor/
ORDER_MONITOR_EX.xml file, is used.

Chapter 22. Time-Triggered Transaction Reference 529


If the default monitor template is used, the MonitorConsolidation->
Order->OrderStatuses-> OrderStatus-> MonitorRule element is ignored and is not
passed into the condition.

Enhanced Return Monitor


The enhanced return monitor allows you to monitor the following situations:
v Milestone x has not been reached y hours before a given date type.
v Milestone x has not been reached within y hours of a given date type.
v Milestone x has not been reached within y hours of milestone z.
v Milestone x has been reached y hours before a given date type.
v Milestone x has been reached within y hours of a given date type.
v Milestone x has been reached within y hours after milestone z.
v The order has been in status x for y hours.
v Date type x is y hours before date type z.
v Date type x is y hours after date type z.

The enhanced return monitor can be configured to monitor the following system
date types:
v Actual Order Date - Read from the ORDER_DATE column of the
YFS_ORDER_HEADER table
v Requested Ship Date - If there is an order release, read from the
REQ_SHIP_DATE column of the YFS_ORDER_RELEASE table. Otherwise, read
from the REQ_SHIP_DATE of the YFS_ORDER_LINE table.
v Expected Ship Date - Read from the EXPECTED_SHIPMENT_DATE column of
the YFS_ORDER_LINE_SCHEDULE table. If it is null, uses the same logic as
Requested Ship Date.
v Actual Ship Date - If the date is before 01/01/2500, read from he
EXPECTED_SHIPMENT_DATE column of the YFS_ORDER_LINE_SCHEDULE
table. If the date is on or after 01/01/2500, this date type is returned as null.
v Requested Delivery Date - If there is a release, read from the
REQ_DELIVERY_DATE column of the YFS_ORDER_RELEASE table. Otherwise,
read from the REQ_DELIVERY_DATE of the YFS_ORDER_LINE table.
v Expected Delivery Date - Read from the EXPECTED_DELIVERY_DATE column
of the YFS_ORDER_LINE_SCHEDULE table. If it is null, uses the same logic as
Requested Delivery Date.
v Actual Delivery Date - If the date is before 01/01/2500, read from he
EXPECTED_DELIVERY_DATE column of the YFS_ORDER_LINE_SCHEDULE
table. If the date is on or after 01/01/2500, this date type is returned as null.
For Order Fulfillment, Planned Order Execution, Reverse Logistics, and Purchase
Order Execution pipelines, the system defined dates such as Shipment and
Delivery are stored without a time component. Therefore when you configure a
rule using these dates, all time computations are carried out assuming they are
always 12:00:00 AM.

For more information about milestones, date types, and monitoring rules, refer to
the Sterling Selling and Fulfillment Foundation: Supply Collaboration Configuration
Guide, the , and the Sterling Selling and Fulfillment Foundation: Reverse Logistics
Configuration Guide.

530 Sterling Selling and Fulfillment Foundation: Application Platform Configuration Guide
If you run the Enhanced Return Monitor, you must configure and run the Close
Order time-triggered transaction in all applicable pipelines. For more information
about the Close Order time-triggered transaction, see “Close Order” on page 376.

The same relog interval is used for all document types.

Attributes

The following are the attributes for this time-triggered transaction:


Table 409. Enhanced Order Monitor Attributes
Attribute Value
Base Transaction ID RETURN_MONITOR_EX
Base Document Type Return Order
Base Process Type Reverse Logistics
Abstract Transaction No
APIs Called None

Criteria Parameters

The following are the criteria parameters for this monitor:


Table 410. Enhanced Order Monitor Criteria Parameters
Parameter Description
Action Required. Triggers the transaction. If left blank, it defaults to
Get, the only valid value.
Number of Records To Optional. Number of records to retrieve and process at one
Buffer time. If left blank or specified as 0 (zero), it defaults to 5000.
EnterpriseCode Optional. Enterprise for which the Order Monitor needs to be
run. If not passed, then all enterprises are monitored.
FromStatus Optional. Statuses to monitor that are greater than or equal to
the passed status.
ToStatus Optional. Statuses to monitor that are less than or equal to the
passed status.
CollectPendingJobs If this parameter is set to N, the agent does not collect
information on the pending jobs for this monitor. This pending
job information is used for monitoring the monitor in the
System Management Console.
ColonyID Required in a multi schema deployment where a table may
exist in multiple schemas. Runs the agent for the colony.

Statistics Tracked

The following statistics are tracked for this monitor:


Table 411. Enhanced Order Monitor Statistics
Statistic Name Description
NumOrdersProcessed Number of orders processed.
NumAlertsRaised Number of alerts raised.

Chapter 22. Time-Triggered Transaction Reference 531


Pending Job Count

For this transaction the pending job count is the number of open orders with the
value of NEXT_ALERT_TS less than or equal to (<=) the current date.

Events Raised

No events are raised. Individual actions associated with the monitoring rule are
run.

The data published is RETURN_MONITOR_EX.xml.

Monitor Rule's Condition Template


If a monitor rule contains a condition, the <INSTALL_DIR>/repository/xapi/
template/source/smcfs/monitor/ORDER_MONITOR_EX_CONDITION.xml template file is
used to obtain both the order details and the evaluating monitor rule details. See
the provided <INSTALL_DIR>/repository/xapi/template/source/smcfs/monitor/
ORDER_MONITOR_EX_CONDITION.xml.sample file for more details.

If the <INSTALL_DIR>/repository/xapi/template/source/smcfs/monitor/
ORDER_MONITOR_EX_CONDITION.xml template file does not exist, the
MonitorConsolidation->Order element of the default monitor template, the
<INSTALL_DIR>/repository/xapi/template/source/smcfs/monitor/
ORDER_MONITOR_EX.xml file, is used.

If the default monitor template is used, the MonitorConsolidation-> Order->


OrderStatuses-> OrderStatus-> MonitorRule element is ignored and is not passed
into the condition.

Real-time Availability Monitor


The Real-time Availability Monitor time-triggered transaction monitors the
inventory availability of inventory items. It can be configured to raise the
REALTIME_AVAILABILITY_CHANGE event when the inventory level for a given item
changes between the thresholds defined in the Applications Manager in the Global
Inventory Visibility module.

It can be run in three modes:


v Activity Based: Raises the event in real time every time an item goes above or
below one of the thresholds.
v Quick Sync: Re-sends the most recently published inventory availability
information.
v Full Sync: Monitors all of the items regardless of activity and publishes the
inventory information for all of the items.

In all cases, the percentage of future inventory availability is used for considering
inventory availability at retrieval time. For more information about future
inventory availability, see the Sterling Selling and Fulfillment Foundation: Global
Inventory Visibility Configuration Guide.

Demand of type OPEN_ORDER is used in getting the inventory availability


picture. If sourcing is maintained, the Real-time Availability Monitor can either
monitor the total availability across nodes or the availability at individual nodes.

532 Sterling Selling and Fulfillment Foundation: Application Platform Configuration Guide
Inventory items without an Availability Monitor rule, or with a rule that is
disabled, are unable to be processed by this time-triggered transaction.

When monitoring the total availability across nodes, the Real-time Availability
Monitor monitors all nodes in the default distribution group of the inventory
organization.

When monitoring the availability at individual nodes, the Real-time Availability


Monitor monitors all nodes in a specified distribution group. For more information
about configuring distribution groups and node-level inventory monitoring, see the
Sterling Selling and Fulfillment Foundation: Global Inventory Visibility Configuration
Guide.

If configured, the Real-time Availability Monitor also considers the onhand and
future inventory availability safety factor during monitoring. For more information
about the inventory availability safety factors and the findInventory() API, see the
Sterling Selling and Fulfillment Foundation: Global Inventory Visibility Configuration
Guide and the Sterling Selling and Fulfillment Foundation: Javadocs.

When the onhand quantity is greater than the configured low threshold, the
REALTIME_ONHAND alert type is raised, and the alert level is based on the onhand
quantity.

When the onhand quantity falls below the configured low threshold, the
REALTIME_FUTURE_MAX alert type is raised, and the alert level is based on the total
future supply (FutureAvailableQuantity) with FirstFutureAvailableDate set to
the date on which the first future supply is available, and FutureAvailableDate set
to the date on which the maximum future supply is available.

When the Real-time Availability Monitor is run in activity based mode, changing
one of the thresholds of an inventory item does not cause the agent to monitor it
unless there is a change in activity. For example, if item I with available quantity
700 is being monitored with a low threshold of 600, and the low threshold is then
changed to 1000, no event is published unless there is change in I's activity. In
order to ensure that in such a scenario I is not left unmonitored, call the
createInventoryActivity API when changing a monitoring rule for an item.

Computing and Publishing the Maximum Ship Dates for Available


Quantities

If enabled, the Real-Time Availability Monitor computes and publishes a matrix of


maximum ship dates for available quantities, which includes the following
information:
v Available Quantity - Refers to the number of items that are available for
shipping on the maximum ship date.
v Maximum Ship Date - Refers to the time and date when available quantities are
shipped by.
v Effective Until Date - Refers to the last time and date that an order can be
placed if it is to be shipped by the maximum ship date.

The matrix is published to the REALTIME_AVAILABILITY_CHANGE event and stored in


XML format in the AVAILABILITY_INFO field of the YFS_INVENTORY_ALERTS
table. The monitorItemAvailability() API can be used to update the matrix. For
more information about the monitorItemAvailability() API, refer to the Sterling
Selling and Fulfillment Foundation: Javadocs.

Chapter 22. Time-Triggered Transaction Reference 533


For information about using the Real-Time Availability Monitor to calculate and
publish a matrix of maximum ship dates for available quantities, refer to the
chapter on Configuring Inventory Rules in the Sterling Selling and Fulfillment
Foundation: Global Inventory Visibility Configuration Guide.

Computing the Maximum Ship Date

The maximum ship date is equal to the maximum expected ship date across all the
nodes being considered. For information about calculating the expected ship date,
refer to the Sterling Selling and Fulfillment Foundation: Product Concepts Guide.
Additionally, the following options can be configured as part of the maximum ship
date:
v Maximum Ship Date Time
v Number of Days To Offset the Maximum Ship Date

Maximum Ship Date Time - If you specify a time for the maximum ship date, the
Real-Time Availability Monitor calculates the maximum ship date, as described
earlier, and then applies the following logic:
v If the time specified for the maximum ship date occurs later in the day than the
calculated ship date, the Real-Time Availability Monitor resets the maximum
ship date to the specified time. For example, if the Real-Time Availability
Monitor calculates the maximum ship date to be 10 a.m. on July 21 and
Maximum Ship Date Time is set to 11 a.m., the maximum ship date is
recalculated to be 11 a.m. on July 21.
v If the time specified for the maximum ship date occurs earlier in the day than
the calculated ship date, the maximum ship date is incremented by one day and
reset to the specified time. For example, if the maximum ship date is calculated
to be 11 a.m. on July 21 and Maximum Ship Date Time is set to 10 a.m., the
Real-Time Availability Monitor recalculates the maximum ship date to be 10 a.m.
on July 22.

Number of Days To Offset the Maximum Ship Date - You can specify a number
of days to offset the maximum ship date. The Real-Time Availability Monitor
calculates the maximum ship date, including the maximum ship date time, and
then increments the maximum ship date by the number of days specified by the
offset number. For example, if the Real-Time Availability Monitor has calculated a
maximum ship date to be 11 a.m. on July 19 and Number of Days to Offset the
Maximum Ship Date is set to 1, the maximum ship date is recalculated to be 11
a.m. on July 20.

Calculating the Effective Until Date

The Real-Time Availability Monitor calculates the effective until date by subtracting
the node's minimum notification time from the maximum ship date and then
adjusting for the preceding notification time on the node's notification schedule.
The effective until date is only valid while supplies are available at the node.

For example, if an available quantity has a maximum ship date of 4 p.m. on July
19 and the shipping node has the following notification schedule, the effective until
date is calculated to be 3 p.m. on July 18:
v 24-hour minimum notification time
v 3 p.m. and 5 p.m. notification times

534 Sterling Selling and Fulfillment Foundation: Application Platform Configuration Guide
In this example, the effective until date is calculated by first subtracting the
24-hour minimum notification time from the 4 p.m., July 19 maximum ship date
and then adjusting for the 3 p.m. notification time. If an order is not placed before
3 p.m. on July 18, the July 19 maximum ship date is no longer available because
the node must be notified at least 24 hours before shipping the items, by 4 p.m. on
July 19. Also, if a different order reduces available quantities at the node before the
order is placed at 3 p.m. on July 19, the maximum ship date cannot be met and the
effective until date becomes invalid.

Additionally, offset days are not considered when calculating the effective until
date. Thus, if the maximum ship date in the earlier example is updated to 4 p.m.
July 20 by setting Number of Days to Offset Maximum Ship Date to 1, the effective
until date is updated to 3 p.m., July 19.

Example 1: Computing Maximum Ship Dates for Available Quantities

Node 1 has the following supply picture:


v 24-hour minimum notification time
v Notification times are 3 p.m. and 5 p.m. daily
v Work Days are 24 hours-a-day, 7 days-a-week

Node 2 has the following supply picture:


v 48-hour minimum notification time
v Notification times are 2 p.m. and 5 p.m. daily
v Work Days are 24 hours-a-day, 7 days-a-week

The following table shows the availability matrix for Node 1 and Node 2, where
the following conditions are true:
v Current date is July 19
v Estimated time of arrival (ETA) equals the date that the quantity is expected to
be available at the node
v Maximum Ship Date Time is set to 4 p.m.
v Number of Days to Offset the Maximum Ship Date is set to 0
Table 412. Example: Availability Matrix of Maximum Ship Dates for Available Quantities
ETA Quantity Maximum Ship Date Effective Until Date
Node 1
7/19/2010 80 4 p.m., July 20 3 p.m., July 19
7/22/2010 10 4 p.m. July 22 3 p.m., July 21
Node 2
7/19/2010 100 4 p.m., July 21 2 p.m., July 19
7/22/2010 20 4 p.m., July 22 2 p.m., July 20

In this example, July 19 is the ETA for a quantity of 80 items at Node 1 and 100
items at Node 2. The matrix shows a 4 p.m., July 20 maximum ship date for the 80
available items from Node 1 and a 4 p.m., July 21 maximum ship date for the 100
available items from Node 2. For Node 1, the maximum ship date is calculated by
adding the 24-hour minimum notification time to the 3 p.m notification time on
July 19, and then adjusting for the 4 p.m. maximum ship date time. The effective
until date is calculated by subtracting the 24-hour minimum notification time from
the maximum ship date and then adjusting for the 3 p.m. notification time. For

Chapter 22. Time-Triggered Transaction Reference 535


Node 2, the maximum ship date and effective until date are calculated similarly,
with the exception that Node 2 has a 48-hour minimum notification time and a 2
p.m. notification time.

Additionally, the example shows July 22 as the ETA for a quantity of 10 items at
Node 1 and 20 items at Node 2. The maximum ship date is 4 p.m., July 22 for the
10 items at Node 1 and 4 p.m., July 22 for the 20 items at Node 2. If the difference
between the current date and the ETA is greater than the node's minimum
notification time, the ETA date is used for the maximum ship date. In this example,
the difference between the current date, July 19, and the ETA date, July 22, is
greater than the minimum notification times at both nodes. Thus, the maximum
ship date is set to the maximum ship date time on the ETA date at the nodes,
which is 4 p.m., July 22 at Node 1 and 4 p.m., July 22 at Node 2.

Example 2: Computing the Maximum Ship Date at Nodes With Non-Working


Days

The following table displays the availability matrix for Node 1 and Node 2 when
the supply picture and conditions from Example 1 are applied. However, in this
scenario, July 19 and July 20 are non-working days.
Table 413. Example: Availability Matrix for Nodes with Non-Working Days
ETA Quantity Maximum Ship Date Effective Until Date
Node 1
7/19/2010 80 4 p.m., July 22 3 p.m., July 21
Node 2
7/19/2010 100 4 p.m., July 23 2 p.m., July 21

In the example, Node 1 has an available quantity of 80 on July 19 and a minimum


notification time of 24 hours. Because July 19 and July 20 are non-working days at
Node 1, the 80 items are not considered available until July 21. In this case, the
maximum ship date is calculated by adding the 24-hour minimum notification time
to July 21 and adjusted for the 4 p.m. maximum ship date time. For Node 2, the
maximum ship date is calculated similarly, with the exception of a 48-hour
minimum notification time.

Example 3: Offsetting the Maximum Ship Date

The following table displays the availability matrix for Node 1 and Node 2 when
the supply picture and conditions from Example 2 are applied. However, in this
scenario, Number of Days To Offset the Maximum Ship Date is set to 1.
Table 414. Example: Availability Matrix When Offsetting the Maximum Ship Date
ETA Quantity Maximum Ship Date Effective Until Date
Node 1
7/19/2010 80 4 p.m., July 23 3 p.m., July 22
Node 2
7/19/2010 100 4 p.m., July 24 2 p.m., July 22

In the example, the maximum ship dates for Nodes 1 and 2 are calculated similarly
to Example 2. However, the maximum ship dates are incremented by 1 because
Number of Days to Offset the Maximum Ship Date is set to 1. In this example, the

536 Sterling Selling and Fulfillment Foundation: Application Platform Configuration Guide
effective until date is set to 3 p.m., July 22 for Node 1 and 2 p.m., July 22 for Node
2 because the offset days are not considered when calculating the effective until
date.

Attributes

The following are the attributes for this time-triggered transaction:


Table 415. Real-time Availability Monitor Attributes
Attribute Value
Base Transaction ID REALTIME_ATP_MONITOR
Base Document Type General
Base Process Type General
Abstract Transaction No
APIs Called FindInventory

Criteria Parameters

The following are the criteria parameters for this monitor:


Table 416. Real-time Availability Monitor Criteria Parameters
Parameter Description
Action Required. Triggers the transaction. If left blank, it
defaults to Get, the only valid value.
Number of Records To Buffer Optional. Number of records to retrieve and process
at one time. If left blank or specified as 0 (zero), it
defaults to 5000.
InventoryOrganizationCode Inventory organization code to use when
MonitorOption is passed as 3. The inventory
organization has to be an enterprise.

If this is not passed, the monitor runs for all


inventory organizations.
MonitorOption 1 - Activity Based (Monitor based on distinct
inventory items in YFS_INVENTORY_ACTIVITY table).

2 – Quick Sync (Re-raise event to publish


information from the YFS_INVENTORY_ALERTS
table).

3 – Full Sync (Monitor based on all inventory items


maintained by the inventory organization provided.
If no InventoryOrganizationCode is provided, all
inventory item is monitored).

If not provided, default value is 1.


ItemStatuses List of valid statuses of items to be processed.
Statuses must be separated by a , for example
3000,2000. This is only used when MonitorOption is
passed as 2 or 3. If provided, only items with the
matching statuses is monitored.

Chapter 22. Time-Triggered Transaction Reference 537


Table 416. Real-time Availability Monitor Criteria Parameters (continued)
Parameter Description
FromAlertTimestamp This is only used when MonitorOption is passed as
2. If provided, the agent raises the
REALTIME_AVAILABILITY_CHANGE event to
re-publish inventory availability information which
was published between the time that the agent
started and FromAlertTimestamp.

If not provided, all inventory availability


information published before the time that the agent
started is re-published.
AllowedOverriddenCriteria If set to Y, the overridden value for the agent criteria
parameters can be provided at the command line
while triggering the agent in the following format:
<AgentCriteriaAttribute> <OverriddenValue>

For more information about passing these attributes,


see the Sterling Selling and Fulfillment Foundation:
Installation Guide.
FromLastNumberOfHours This is only used when MonitorOption is passed as
2 to calculate the FromAlertTimestamp parameter, if
necessary.

If the FromAlertTimestamp parameter is not


provided, it is calculated as current timestamp
minus FromLastNumberOfHours.
CollectPendingJobs If this parameter is set to N, the agent does not
collect information on the pending jobs for this
monitor. This pending job information is used for
monitoring the monitor in the System Management
Console.
RaiseEventsOnAllAvailability When set to Y,
Changes REALTIME_AVAILABILITY_CHANGE event is
raised on all availability changes regardless of
whether availability exceeds or falls below specified
thresholds. This is only used when MonitorOption is
passed as 1. Valid values: Y or N. Default value: N.
ColonyID Required in a multi schema deployment where a
table may exist in multiple schemas. Runs the agent
for the colony.

Statistics Tracked

None.

Pending Job Count

None.

538 Sterling Selling and Fulfillment Foundation: Application Platform Configuration Guide
Events Raised

The following events are raised by this time-triggered transaction:


Table 417. Events Raised by the Realtime Availability Monitor Transaction
Template
Transaction/Event Key Data Data Published* Support?
REALTIME_ None YFS_REALTIME_ATP_MONITOR. Yes
AVAILABILITY_ REALTIME_AVAILABILITY
CHANGE _CHANGE.html
* These files are located in the following directory:
<INSTALL_DIR>/xapidocs/api_javadocs/XSD/HTML

Although described as 'real-time', availability changes may not be triggered


immediately as inventory changes occur if the agent has a backlog of messages to
process. Furthermore, this monitor exists as a time-triggered transaction, and thus
monitors availability of inventory items only when the monitor is triggered based
on the configured runtime properties.

Shipment Monitor
This time-triggered transaction reports the states of a shipment, based on rules in
the YFS_MONITOR_RULE table. This transaction enables you to monitor the
following situations:
v If the Shipment has been in a status for more than a specified amount of time.
v If a specified date that is associated with the shipment is:
– n hours before another specified date
– n hours after another specified date
– n hours not before another specified date
– n hours not after another specified date
v If the Shipment has been in a hold type for a specified amount of time.
v If the Shipment has been in a hold type for n hours before a specified date.

Monitoring rules can be configured for shipment's origin and destination points.

Monitoring rules cannot be configured for a shipment's intermediate pickup and


drop off points. A shipment has intermediate pickup or drop off only if it has
multiple pickup or drop off points. For example, a shipment has more than one
loads carrying it. The shipment status on first load deposit, second load deposit,
and so forth cannot be monitored. Once the last load deposits the shipment at its
destination, then the shipment status can be marked and monitored.

This is not a pipeline transaction. It also does not work from the task queue.

For more information about milestones, date types, and monitoring rules, see the
Sterling Selling and Fulfillment Foundation: Supply Collaboration Configuration Guide,
the , and the Sterling Selling and Fulfillment Foundation: Reverse Logistics
Configuration Guide.

Chapter 22. Time-Triggered Transaction Reference 539


Attributes

The following are the attributes for this time-triggered transaction:


Table 418. Shipment Monitor Attributes
Attribute Value
Base Transaction ID SHIPMENT_MONITOR
Base Document Type Order
Base Process Type Order Delivery
Abstract Transaction No
APIs Called None

Criteria Parameters

The following are the criteria parameters for this monitor:


Table 419. Shipment Monitor Criteria Parameters
Parameter Description
Action Required. Triggers the transaction. If left blank, it defaults to
Get, the only valid value.
Number of Records To Optional. Number of records to retrieve and process at one
Buffer time. If left blank or specified as 0 (zero), it defaults to 5000.
EnterpriseCode Optional. Enterprise for which the Shipment Monitor needs to
be run. If not passed, then all enterprises are monitored.
CollectPendingJobs If this parameter is set to N, the agent does not collect
information on the pending jobs for this monitor. This pending
job information is used for monitoring the monitor in the
System Management Console.
ColonyID Required in a multi schema deployment where a table may
exist in multiple schemas. Runs the agent for the colony.

Statistics Tracked

The following statistics are tracked for this transaction:


Table 420. Shipment Monitor Statistics
Statistic Name Description
NumShipmentsMonitored Number of shipments monitored.

Pending Job Count

For this transaction the pending job count is the number of open shipments with
the value of NEXT_ALERT_TS less than or equal to (<=) the current date.

Events Raised

This invokes the actions configured against shipment statuses.

Key Data - Not Applicable.

540 Sterling Selling and Fulfillment Foundation: Application Platform Configuration Guide
Data Published - SHIPMENT_MONITOR.xml

Monitor Rule's Condition Template

If a monitor rule contains a condition, the <INSTALL_DIR>/repository/xapi/


template/source/smcfs/monitor/SHIPMENT_MONITOR_CONDITION.xml template file is
used to obtain the shipment details and the evaluating monitor rule details. See the
provided <INSTALL_DIR>/repository/xapi/template/source/smcfs/monitor/
SHIPMENT_MONITOR_CONDITION.xml.sample file for more details.

If the <INSTALL_DIR>/repository/xapi/template/source/smcfs/monitor/
SHIPMENT_MONITOR_CONDITION.xml template file does not exist, the
MonitorConsolidation->Shipment element of the default monitor template, the
<INSTALL_DIR>/repository/xapi/template/source/smcfs/monitor/
SHIPMENT_MONITOR.xml file, is used.

If the default monitor template is used, the MonitorConsolidation->Shipment->


MonitorRule element is ignored and is not passed into the condition.

Work Order Monitor


This time-triggered transaction alerts the enterprise when a work order remains in
a particular state or hold type for a specific amount of time.

Use this monitor to track how long work orders stay in a particular state or hold
type.

Attributes

The following are the attributes for this time-triggered transaction:


Table 421. Work Order Monitor Attributes
Attribute Value
Base Transaction ID WORK_ORDER_MONITOR
Base Document Type Work Order
Base Process Type VAS Process
Abstract Transaction No

Criteria Parameters

The following are the criteria parameters for this monitor:


Table 422. Work Order Monitor Criteria Parameters
Parameter Description
Action Required. Triggers the transaction. If left blank it defaults to
Get, the only valid value.
Number of Records To Optional. Number of records to retrieve and process at one
Buffer time. If left blank or specified as 0 (zero), it defaults to 5000.
EnterpriseCode Optional. Enterprise for which the Work Order Monitor
needs to be run. If not passed, then all enterprises are
monitored.

Chapter 22. Time-Triggered Transaction Reference 541


Table 422. Work Order Monitor Criteria Parameters (continued)
Parameter Description
Node Optional. Node for which the Work Order Monitor needs to
be run. If not passed, then all nodes are monitored.
CollectPendingJobs If this parameter is set to N, the agent does not collect
information on the pending jobs for this monitor. This
pending job information is used for monitoring the monitor
in the System Management Console.
ColonyID Required in a multi schema deployment where a table may
exist in multiple schemas. Runs the agent for the colony.

Statistics Tracked

The following statistics are tracked for this transaction:


Table 423. Work Order Monitor Statistics
Statistic Name Description
NumWorkOrdersMonitored Number of work orders monitored.

Pending Job Count

For this transaction the pending job count is the number of Work Orders that are
monitored, where NEXT_ALERT_TS less than or equal to (<=) current date.

Events Raised

No events are raised. Individual actions associated with the monitoring rule are
run. Data published to the actions is workOrder_dbd.txt.

Monitor Rule's Condition Template

If a monitor rule contains a condition, the <INSTALL_DIR>/repository/xapi/


template/source/smcfs/monitor/monitor/WORK_ORDER_MONITOR_CONDITION.xml
template file is used to obtain the work order details and the evaluating monitor
rule details. See the provided <INSTALL_DIR>/repository/xapi/template/source/
smcfs/monitor/WORK_ORDER_MONITOR_CONDITION.xml.sample file for more details.

If the <INSTALL_DIR>/repository/xapi/template/source/smcfs/monitor/
WORK_ORDER_MONITOR_CONDITION.xml template file does not exist, the
MonitorConsolidation->WorkOrder element of the default monitor template, the
<INSTALL_DIR>/repository/xapi/template/source/smcfs/monitor/
WORK_ORDER_MONITOR.xml file, is used.

If the default monitor template is used, the MonitorConsolidation-> WorkOrder->


MonitorRule element is ignored and is not passed into the condition.

542 Sterling Selling and Fulfillment Foundation: Application Platform Configuration Guide
Chapter 23. Inventory and Capacity Change Transaction
Reference
The Inventory Change Transaction
The Inventory Change transaction is used for setting up events that involve
inventory changes.

Invoked By
v The adjustInventory() API
v Any other API that is capable of doing a status change

Attributes

The following are the attributes for this transaction:


Table 424. Inventory Change Atributes
Attribute Value
Base Transaction ID INVENTORY_CHANGE
Base Document Type General
Base Process Type General
Abstract Transaction No
APIs Called None

Events Raised

This transaction raises the following events:


v SUPPLY_CHANGE
This event is raised for every inventory supply change within Sterling
Application PlatformSterling Selling and Fulfillment Foundation. It publishes
detailed information about the changed supply.
Key Data: INSTALL_DIR/xapidocs/api_javadocs/dbd/
INVENTORY_CHANGE_SUPPLY_CHANGE_dbd.txt Data Published:
INSTALL_DIR/xapidocs/api_javadocs/XSD/HTML/
INV_INVENTORY_CHANGE_SUPPLY_CHANGE.html
v DEMAND_CHANGE
This event is raised for every inventory demand change within Sterling
Application PlatformSterling Selling and Fulfillment Foundation. It publishes
detailed information about the changed demand. Order information is published
when the inventory organization is set to create demand details.
Key Data: INSTALL_DIR/xapidocs/api_javadocs/dbd/
INVENTORY_CHANGE_DEMAND_CHANGE_dbd.txt
Data Published: INSTALL_DIR/xapidocs/api_javadocs/XSD/HTML/
INV_INVENTORY_CHANGE_DEMAND_CHANGE.html
v EXTERNAL_SUPPLY_CHANGE

© Copyright IBM Corp. 1999, 2011 543


This event is raised for every supply change for externally maintained
inventories within Sterling Application PlatformSterling Selling and Fulfillment
Foundation.
Key Data: INSTALL_DIR/xapidocs/api_javadocs/dbd/
INVENTORY_CHANGE_EXTERNAL_SUPPLY_CHANGE_dbd.txt
Data Published: INSTALL_DIR/xapidocs/api_javadocs/XSD/HTML/
INV_INVENTORY_CHANGE_ EXTERNAL_SUPPLY_CHANGE.html
v EXTERNAL_DEMAND_CHANGE
This event is raised for every demand change for each organization that does
not maintain its inventory within Sterling Application PlatformSterling Selling
and Fulfillment Foundation.
Key Data:
INSTALL_DIR/xapidocs/api_javadocs/dbd/
INVENTORY_CHANGE_EXTERNAL_DEMAND_CHANGE_dbd.txt Data
Published: INSTALL_DIR/xapidocs\api_javadocs\XSD\HTML\
INV_INVENTORY_CHANGE_ EXTERNAL_DEMAND_CHANGE.html
v INVENTORY_CHANGE
This event is raised only when we adjust Inventory with ONHAND_SUPPLY
supply type. For example, when Inventory changes from HELD to ONHAND
supply. It publishes detailed information of the changed supply. Key Data:
INSTALL_DIR/xapidocs/api_javadocs/dbd/
INVENTORY_CHANGE_INVENTORY_CHANGE_dbd.txt Data Published:
INSTALL_DIR/xapidocs/api_javadocs/dbd/
INVENTORY_CHANGE_INVENTORY_CHANGE_dbd.txt
v ON_INV_OWNERSHIP_TRNSFR
This event is raised each time a transfer of inventory ownership happens. It
publishes the information about the transfer of inventory ownership. Key Data:
INSTALL_DIR/xapidocs/api_javadocs/dbd/
INVENTORY_CHANGE_INVENTORY_TRANSFER_dbd.txt Data Published -
INSTALL_DIR/xapidocs/api_javadocs/XSD/HTML/
INV_INVENTORY_CHANGE.ON_INV_OWNERSHIP_TRANSFER.html

Note: When defining one of the following events:


v SUPPLY_CHANGE
v DEMAND_CHANGE
v EXTERNAL_SUPPLY_CHANGE
v EXTERNAL_DEMAND_CHANGE
You should not call the changeOrder API as a result of these events. Doing so could
cause the API to raise the event that called it, create an infinite cycle.

The Capacity Change Transaction


The Capacity Change transaction is used for setting up events that involve capacity
changes

Invoked By
v The adjustInventory() API
v The createResourcePool() API
v The modifyresourcePool() API
v The overrideResourcePoolCapacity()API

544 Sterling Selling and Fulfillment Foundation: Application Platform Configuration Guide
v Any other API that is capable of allocating capacity against external resource
pool

Attributes

The following are the attributes for this transaction:


Table 425. Capacity Change Attributes
Attribute Value
Base Transaction ID CAPACITY_CHANGE
Base Document Type General
Base Process Type General
Abstract Transaction No
APIs Called None

Events Raised

This transaction raises the following events:


v ON_CAPACITY_ADJUSTMENT
This event is raised for every standard capacity adjustment when the
createResourcePool() API or modifyResourcePool() APIs are invoked. It
publishes detailed information about the standard capacity adjustments.
Key Data: INSTALL_DIR/xapidocs/api_javadocs/dbd/
CAPACITY_CHANGE_ON_CAPACITY_ADJUSTMENT_dbd.txt
Data Published: INSTALL_DIR/xapidocs/api_javadocs/XSD/HTML/
INV_CAPACITY_CHANGE.ON_CAPACITY_ADJUSTMENT.xml
v ON_OVERRIDE_CAPACITY
This event is raised for every adjustment of overridden capacity when the
overrideResourcePoolCapacity() API is invoked. It publishes detailed
information about the changes in the overridden capacity.
Key Data: INSTALL_DIR/xapidocs/api_javadocs/dbd/
CAPACITY_CHANGE_ON_OVERRIDE_CAPACITY_dbd.txt
Data Published:INSTALL_DIR/xapidocs/api_javadocs/XSD/HTML/
INV_CAPACITY_CHANGE.ON_OVERRIDE_CAPACITY.xml
v EXTERNAL_CAPACITY_CHANGE
This event is raised for every external capacity change within Sterling Selling
and Fulfillment FoundationSterling Application Platform. It publishes detailed
information about the changed capacity of external resource pools.
Key Data: INSTALL_DIR/xapidocs/api_javadocs/dbd/
INVENTORY_CHANGE_EXTERNAL_SUPPLY_CHANGE_dbd.txt
Data Published: INSTALL_DIR/xapidocs/api_javadocs/XSD/HTML/
INV_INVENTORY_CHANGE_ EXTERNAL_SUPPLY_CHANGE.html

Note: When defining the EXTERNAL_CAPACITY_CHANGE event, you should


not call the changeOrder API as a result of this event. Doing so could cause the API
to raise the event that called it, creating an infinite cycle.

Chapter 23. Inventory and Capacity Change Transaction Reference 545


546 Sterling Selling and Fulfillment Foundation: Application Platform Configuration Guide
Chapter 24. Transport Nodes
Transport nodes determine how data should be transferred from one location to
another. To define their configuration properties, click the links connection going
into or out of the transport node. The link going into a transport node is a sender
link and the link going out is a receiver link.

Exception Handling

Asynchronous receiver links can be configured to handle exceptions, as described


in “Receiver Link Exception Handling” on page 601 “Receiver Link Exception
Handling” on page 601. The asynchronous receiver links that can be configured for
exception handling are the following:
v Database Receiver
v File I/O Receiver
v FTP Receiver
v Oracle WebLogic, MQSeries, and TIBCO JMS Receiver
v MSMQ Receiver

Database
The database node defines an asynchronous transport using a database table. The
database transport node can have sender and receiver links, the links capture the
respective properties.

Do not use the database node when scaling. Instead, use a JMS Queue node.

Database Sender
Configuration Properties

The following are the properties of the links connecting this node:
Table 426. Database Sender Configuration Properties
Property Description
Runtime Tab
Table Name Select the table you want the message to be written to. Valid
values are YFS_IMPORT and YFS_EXPORT.

© Copyright IBM Corp. 1999, 2011 547


Table 426. Database Sender Configuration Properties (continued)
Property Description
Rollback on Exception Select this check box if you want the message to be committed
to the database only after the service is completed.

Uncheck this check box if you want the message to be


committed to the database immediately.

For example, if the ON_SUCCESS event of any standard


Sterling Selling and Fulfillment FoundationApplication API is
attached to a service, in which the message is transactionally
written to the database, the message is committed to the
database only upon successful completion of the ON_SUCCESS
event. The message is then rolled back from the queue if there
is any error in the ON_SUCCESS event after the message is
staged. However, in non-transactional mode, the message
remains in the database, once it is staged and is not rolled
back.
Header Tab
The Header Name and Header Value allow the sender to
differentiate between messages in the table. See the Selector
field in the "Database Receiver Configuration Properties" table.

In addition to the Header Name/Value, EOF messages get


appended with MessageType=EOF in the USER_REFERENCE
column. If you are using USER_REFERENCE as the selector,
you need to modify the Selector criteria to include
MessageType=EOF as well.
Note: The header name must be unique. Two headers cannot
have the same header name.

Choose to add a new header name and value.

Choose to modify an existing header name and value.

Choose to delete an existing header name and value.

Important: Do not enter any spaces in the Header Name.

548 Sterling Selling and Fulfillment Foundation: Application Platform Configuration Guide
Table 426. Database Sender Configuration Properties (continued)
Property Description
Header Value Saved in the USER_REFERENCE column of the YFS_EXPORT
and YFS_IMPORT tables as a name value pair. A maximum
limit of these name/value pairs stored is 2048 bytes, beyond
which the references are truncated.

Each Header Name/Value pair specified is appended in the


USER_REFERENCE column of the YFS_IMPORT/YFS_EXPORT
table as Name1=Value1 Name2=Value2

These references can be used to identify the key data stored in


the MESSAGE field of the YFS_IMPORT/YFS_EXPORT table
when querying.

This can be set to dynamically extract from the message using


the following syntax xml://<full path of the element from root
node>/@<attribute name>.

For example, to get the sales order number from the publish
ship advice output XML: set the value as xml://
ShipmentAdvices/ShipmentAdvice/@SalesOrderNo results in
the USER_REFERENCE field to be populated with
NAME1=<value of attribute SalesOrderNo in the XML>

Important: Do not enter any spaces in the Header Value.

Database Receiver
Configuration Properties

The following are the properties of the links connecting this node:
Table 427. Database Receiver Configuration Properties
Property Description
Runtime Tab
Sub Service Name Enter a unique identifier for each asynchronous receiver.
Initial Threads Enter the number of threads that can process messages
simultaneously. This value must be a minimum of 1.
Based on your throughput requirements, you can increase
the number of threads.

The number of threads set in the configuration can be


increased for a Sub Service Name dynamically from the
System Management Console. For more information about
the System Management Console, see the Sterling Selling
and Fulfillment Foundation: Application Platform User Guide.

Chapter 24. Transport Nodes 549


Table 427. Database Receiver Configuration Properties (continued)
Property Description
Selector Enter the message to be processed, using the Header
Name and Header values from the "Database Sender
Configuration Properties" table, implemented as an SQL
where clause in the of form
USER_REFERENCE='<name>=value'

In addition to the Header Name/Value, EOF messages get


appended with MessageType=EOF in the
USER_REFERENCE column. If you are using
USER_REFERENCE as the selector, you need to modify
the Selector criteria to include MessageType=EOF as well.
Note: When specifying a selector, use only single quotes.
Note: If you configure two services to read from the same
table (and select the same records), the results may be
unpredictable. For a database, the columns that can be
used are FLOW_NAME, SUB_FLOW_NAME,
USER_REFERENCE, from the YFS_EXPORT/IMPORT
table.
Table Name Select the table you want the message to be read from.
Valid values are YFS_IMPORT and YFS_EXPORT.

Must match the table specified in the receiver link.


Polling Frequency (seconds) Enter the frequency in seconds to poll for messages from
the database table. Defaults to 600 seconds (10 minutes).

A separate thread manages all exceptions resolved from


the exception console and polls the database every 60
seconds (1 minute). The frequency of polling for exception
processing cannot be modified.
Service to Execute on EOF Required if the message contains an End Of File (EOF)
Message message ID.

Choose to select the service to be invoked when an


EOF message is received. Once the EOF message is
received, the framework waits for a few minutes
(configurable in the customer_overrides.properties file)
before executing this service. For more information see,
“Enabling EOF Messages in the Application Platform
Framework” on page 559. For additional information
about overriding properties using the
customer_overrides.properties file, see the Sterling
Selling and Fulfillment Foundation: Properties Guide.
Root Node Name of EOF This need to be specified only if the message contains an
Message EOF message ID.

Enter your custom root node name for the EOF message.

By default the EOF message has a root node name as


"EOF". For more information see, “Enabling EOF Messages
in the Application Platform Framework” on page 559
Server Tab
Server Name Required. Name of the integration server instance which
actually executes the service.

For more information about creating a new server, see


Adding a New Server.

550 Sterling Selling and Fulfillment Foundation: Application Platform Configuration Guide
Table 427. Database Receiver Configuration Properties (continued)
Property Description
Exception Tabs See Table 462 on page 602 for the receiver link exception
handling properties.

Connection Properties

The following are the Database node's connection properties:


Table 428. Database Connection Properties
Connection Node Connection Rules
Can be the first node after Yes, for services invoked both in a synchronous or
the start node asynchronous mode
Can be placed before v Any component node
v Any transport node (except for FTP, JMS, or File I/O); use
a Pass-through node to connect them
Can be placed after v Start node
v Any synchronous transport node.
v Any other component node
v Any asynchronous transport node (except for FTP, JMS, or
File I/O); use a Pass-through node to connect them
Passes data unchanged Transport nodes do not modify data

DCS 6.2 Database


The Distribution Center System (DCS) 6.2 database node defines an asynchronous
transport using a DCS 6.2 database table. The DCS 6.2 database transport node
enables you to define services or interfaces to read from or write to the DCS 6.2
tables that are comprised of positional data. The interface tables in the DCS 6.2
database are INFC_UPLD_TAB_1 and INFC_DNLD_TAB_1. Multiple records in these
interface tables constitute a transaction.

You can define defaults which can be applied on these interface tables. Hence, if
DCS 6.2 needed some specific attributes to be set in the data and that data is not
available in the external system, interface defaulting mechanisms can be used to set
them up. For more information about using the defaulting component refer to
“Defaulting Component” on page 615.

The DCS 6.2 database component reads unprocessed interface table


(INFC_DNLD_TAB_1) records for an interface type and node. If any of the components
following the DCS 6.2 database component in the service definition framework
throws an exception, the interface records for that transaction are marked as error.
Processing of these error records is based on a system property that is passed to a
server JVM running the inbound interface.

Note: If a text translator component converts the list of interface records into an
XML, an XSL transformation must be applied on the output of the text translator
to conform the XML to the input required by the API.

Chapter 24. Transport Nodes 551


DDCS 6.2 Database Sender
Configuration Properties

The following are the properties of the links connecting this node:
Table 429. DCS 6.2 Database Sender Configuration Properties
Property Description
Interface Type Enter the interface type. The records of this interface type are
processed.
Table Type Select either UPLD or DNLD for the upload or download interface
tables. The interface table names are derived from this and the
value entered in the Node field. The default value for the
sender is UPLD.
Node Enter the ship node associated with the service.
Table Name This field is not editable. The table name is automatically
entered once the Table Type is selected and is appended with
the entered ship node.

The table name is YFS_INFC_UPLD_TAB1_Node1 for UPLD and


YFS_INFC_DNLD_TAB1_Node1 for DNLD table types with the ship
node as Node1.
Remote Host ID Enter the remote host ID in the database.
Rollback on Exception Check this box if you want to rollback the database write if the
parent transaction fails.

Uncheck this check box if you want the message to be


committed to the database immediately.

For example, if the ON_SUCCESS event of any standard


Sterling Selling and Fulfillment FoundationApplication API is
attached to a service in which the message is transactionally
written to the database, the message is committed to the
database only upon successful completion of the ON_SUCCESS
event. The message is then rolled back from the database if
there is any error in the ON_SUCCESS event after the message
is staged. However, in non-transactional mode, the message
remains in the database, once it is staged and is not rolled
back.

DCS 6.2 Database Receiver


Configuration Properties

The following are the properties of the links connecting this node:
Table 430. DCS 6.2 Database Receiver Configuration Properties
Property Description
Runtime Tab
Sub Service Name Enter a unique identifier for each asynchronous receiver.
Node Enter the ship node associated with the service.
Selector Optional. This field can be used for selecting a specific
remote host ID.
Note: When specifying a selector, use only single quotes.

552 Sterling Selling and Fulfillment Foundation: Application Platform Configuration Guide
Table 430. DCS 6.2 Database Receiver Configuration Properties (continued)
Property Description
Table Type Select either UPLD or DNLD for the upload or download
interface tables. The interface table names are derived
from this and the value entered in the Node field. The
default value for the receiver is DNLD.
Table Name This field is not editable. The table name is automatically
entered once the Table Type is selected and is appended
with the entered ship node.

The table name is YFS_INFC_UPLD_TAB1_Node1 for UPLD and


YFS_INFC_DNLD_TAB1_Node1 for DNLD table types with the
ship node as Node1.
Interface Type The interface type in which the records are processed.
Polling Frequency (seconds) Enter the frequency in seconds to poll for messages from
the database table. Defaults to 600 seconds (10 minutes).
Server Tab
Server Name Required. Name of the integration server instance which
actually executes the service.

For more information about creating a new server, see


"Adding a New Server".
Exception Tabs See Table 462 on page 602 for the receiver link exception
handling properties.

Connection Properties

The following are the DCS 6.2 Database node's connection properties:
Table 431. DCS 6.2 Database Connection Properties
Connection Node Connection Rules
Can be the first node after Yes, for services invoked both in synchronous or
the start node asynchronous mode.
Can be placed before v Text Translator component node
v End node
Can be placed after v Start node
v Text Translator component node
Passes data unchanged Transport nodes do not modify data

Component Object Model (COM)


The Component Object Model (COM) transport Node defines the synchronous
COM call being made to the configured COM component.

Note: Make sure the <INSTALL_DIR>/bin directory is in your system path.

Chapter 24. Transport Nodes 553


Configuration Properties

The following are the properties of this node:


Table 432. COM Sender Configuration Properties
Property Description
Program ID Enter the COM component's program ID to be invoked.
The program ID can be found in the registry by running
the regedit utility and looking up the DLL to be invoked.

The custom COM component should implement an


execute method, the method signature should be as
follows:

[id(1), helpstring("method execute")] HRESULT


execute([in]BSTR sData, [out]VARIANT *outData, [out,
retval] long *RetVal);

Connection Properties

The following are the COM node's connection properties:


Table 433. COM Connection Properties
Connection Node Connection Rules
Can be the first node after Only for services invoked synchronously
the start node
Can be placed before v Any transport node except FTP or File I/O
v Any other component node
Can be placed after v Start node
v Any synchronous transport node
v Any other component node
v Any asynchronous transport node (except for FTP or File
I/O); use a Pass-through node to connect them.
Passes data unchanged No. The data returned by the COM component is passed to
the next service component.

Enterprise Java Beans (EJB)


The Enterprise Java Beans (EJB) Transport node defines the way messages are sent
synchronously using the EJB protocol. The EJB transport node has sender-related
properties.

The EJB node is needed only to call other, non-Application Sterling Selling and
Fulfillment FoundationEJBs.

554 Sterling Selling and Fulfillment Foundation: Application Platform Configuration Guide
Configuration Properties

The following are the properties of this node:


Table 434. EJB Sender Configuration Properties
Property Description
Provider URL Enter the provider URL for the JNDI lookup of the EJB
home.
v For Oracle WebLogic, set to t3://<DNS Server Name or
IP Address>:<port>
EJB Home Name Enter the class name implementing the EJB home
interface. This is used by the client to find, create, or
remove EJB objects.
JNDI Name Enter the name used to lookup the EJB home interface.
Initial Context Factory The class name of the initial context factory. This is the
class used for resolution of names for naming and
directory operations.
Method Name Enter the method to be invoked. This method must have
a standard signature:

Document outdoc = method(Document indoc)


Authenticate If selected, security-related authentications can be defined
for the security principal and security credential.

The Security Principal and Credentials are required for the


JNDI lookup.
Security Principal If you selected Authenticate, enter the user name for the
Access control list of the EJB container.
Security Credential If you selected Authenticate, enter the password for the
Access control list of the EJB container.

Connection Properties

The following are the EJB node's connection properties:


Table 435. EJB Connection Properties
Connection Node Connection Rules
Can be the first node after Only for services invoked synchronously
the start node
Can be placed before v Any transport node except FTP or File I/O
v Any other component node
Can be placed after v Start node
v Any synchronous transport node
v Any other component node
v Any asynchronous transport node (except for FTP or File
I/O); use a Pass-through node to connect them.
Data may be changed Data may be changed depending on what method is called
by the transport node.

Chapter 24. Transport Nodes 555


File Input/Output (File I/O)
The File Input/Output transport node defines how messages are exchanged
asynchronously using flat files. Files can be created or processed using this flow
component. It allows you to configure how to create or process files
asynchronously.

File I/O Sender


Configuration Properties

The following are the properties of links connecting this node:


Table 436. File I/O Sender Connection Properties
Property Description
Working Directory Enter the directory into which the incoming files are
placed before processing begins.
Note: Ensure the directory has the appropriate read/write
permissions and that the full path name has been
specified. If you are using variables instead of the full
path names ensure that the variable is defined in the
<INSTALL_DIR>/properties/
customer_overrides.properties file. For additional
information about overriding properties using the
customer_overrides.properties file, see the Sterling
Selling and Fulfillment Foundation: Properties Guide.
Completion Directory Enter the directory into which a file is moved after it has
been successfully processed or after it exceeds the sizes
specified by Max Output File Size or Max Transactions
Per File.
Note: Ensure the directory has the appropriate read/write
permissions and that the full path name has been
specified. If you are using variables instead of the full
path names ensure that the variable is defined in
the<INSTALL_DIR>/properties/
customer_overrides.properties file. For additional
information about overriding properties using the
customer_overrides.properties file, see the Sterling
Selling and Fulfillment Foundation: Properties Guide.
File Prefix Enter the name to prefix to each file name. Used to
differentiate output files from different services.
File Suffix Enter the name to append to each file name. Used to
differentiate output files from different services.
Max Output File Size (MB) Enter the maximum size (in MB) that can be reached
before closing the current file and opening a new one.
Starts writing to a new file when the minimum of Max
Out File Size and Max Transactions Per File is exceeded.
Max Transactions Per File Enter the maximum number of messages to write to a file
before closing the current file and opening a new one.
Starts writing to a new file when the minimum of Max
Out File Size and Max Transactions Per File is exceeded.
EncodingType Enter the character encoding of the input file. Takes
JVM-supported values such as UTF-8, UTF-16, ISO-8859.
Defaults to the Sterling Application Platform default for
the JVM unless otherwise specified.

556 Sterling Selling and Fulfillment Foundation: Application Platform Configuration Guide
Table 436. File I/O Sender Connection Properties (continued)
Property Description
Max Time to Rollover (mins) Enter the maximum time (in minutes) the output file
remains open.
Disable Root Element If you check this box, based on the value of the Max
Transactions Per File property, the XMLELEMENT root
element is deleted from the XML file.
v If the value of the Max Transactions Per File property is
equal to 1, the XMLELEMENT root element is deleted
from the XML file.
v If the value of the Max Transactions Per File property is
greater than 1, the XMLELEMENT root element is not
deleted from the XML file.

File I/O Receiver


Configuration Properties

The following are the properties of this node:


Table 437. File I/O Receiver Configuration Properties
Property Description
Runtime Tab
Sub Service Name Enter a unique identifier for each asynchronous receiver
within a service definition.
Note: When configuring a sub-flow, do not enter a Sub
Service Name beginning with "YIF".
Includes Pattern Enter the comma separated list of files to process together.
For example, to specify all files with the posCreateOrder.*
name, use .*\posCreateOrder.*. If not specified, processes all
files in the incoming directory in the order specified by the
File Processing Sequence.
Encoding Type Enter the character encoding of the input file. Takes
JVM-supported values such as UTF-8, ASCII, ANSI. Defaults
to the Sterling Application Platform default for the JVM,
unless otherwise specified.
File Processing Sequence Enter the order in which to processes files from the
Incoming Directory. Values are: LastModifiedTime (date) and
ByName (name). Defaults to Last Modified Time.
Maximum Errors Per File Enter the number of logged errors before the Receiver to
terminates processing the file. If set to 0, it defaults to 1. If
not specified, defaults to 10.
Polling Frequency (seconds) Enter the time (in seconds) to poll the source directory for
unprocessed files. Defaults to 600 seconds.
Create EOF Message Select this field if you want to create EOF message. If
checked the framework creates an EOF message at the end
of each file processed and pass to the next service
component. For more information about creating EOF
messages, see “Enabling EOF Messages in the Application
Platform Framework” on page 559.

Chapter 24. Transport Nodes 557


Table 437. File I/O Receiver Configuration Properties (continued)
Property Description
Do Not Fragment If you check this box, the output XML file is not fragmented
into 'n' number of separate files. For example, for a load, if
you create two different load lines, the output XML file
contains the "Load" root element and two "LoadList" child
elements.

If you do not check this box, the root element is deleted


from the output XML file and a separate XML file is created
for each of the child elements.
File Tab
Incoming Directory Enter the directory in which to look for input files.
Note: Ensure the directory has the appropriate read/write
permissions and that the full path name has been specified.
If you are using variables instead of the full path names
ensure that the variable is defined in the
<INSTALL_DIR>/properties/customer_overrides.properties
file. For additional information about overriding properties
using the customer_overrides.properties file, see the
Sterling Selling and Fulfillment Foundation: Properties Guide.
Completion Directory Enter the directory into which the processed files are
archived after they have been processed.
Note: Ensure the directory has the appropriate read/write
permissions and that the full path name has been specified.
If you are using variables instead of the full path names
ensure that the variable is defined in the
<INSTALL_DIR>/properties/customer_overrides.properties
file. For additional information about modifying properties
and the customer_overrides.properties file, see the Sterling
Selling and Fulfillment Foundation: Installation Guide.
Working Directory Enter the directory into which the files from the incoming
directory are moved before processing begins.
Note: Ensure the directory has the appropriate read/write
permissions and that the full path name has been specified.
If you are using variables instead of the full path names
ensure that the variable is defined in the
<INSTALL_DIR>/properties/customer_overrides.properties
file. For additional information about overriding properties
using the customer_overrides.properties file, see the
Sterling Selling and Fulfillment Foundation: Properties Guide.
Error Directory Enter the directory into which any errors in the file being
processed are created. A new error file is created for each file
processed.
Note: Ensure the directory has the appropriate read/write
permissions and that the full path name has been specified.
If you are using variables instead of the full path names
ensure that the variable is defined in the
<INSTALL_DIR>/properties/customer_overrides.properties
file. For additional information about overriding properties
using the customer_overrides.properties file, see the
Sterling Selling and Fulfillment Foundation: Properties Guide.
Error File Suffix Enter the name to append to error files. The error file
records errors that occur while processing the input file.
Defaults to .err.
Completion File Suffix Required if the Completion Directory is specified. Defaults to
.done.

558 Sterling Selling and Fulfillment Foundation: Application Platform Configuration Guide
Table 437. File I/O Receiver Configuration Properties (continued)
Property Description
Server Tab
Server Name Enter the name of the integration server instance which
actually executes the service.

For more information about creating a new server, see


"Adding a New Server".
Exception Tabs See Table 462 on page 602 for the receiver link exception
handling properties.

Connection Properties

The following are the File I/O node's connection properties:


Table 438. File I/O Connection Properties
Connection Node Connection Rules
Can be the first node after Only for services invoked asynchronously
the start node
Can be placed before v FTP transport node
v Text Translator component node
v End node
Can be placed after v Start node
v FTP transport node
v Text Translator component node
Passes data unchanged Transport nodes do not modify data

Enabling EOF Messages in the Application Platform


Framework
The create of EOF messages is divided into two parts:
v Modifying file input/output processing
v Modifying the JMS queue and database receiver to handle EOF messages

Modifying File Input/Output Processing


The File I/O receiver stamps the outgoing XML messages with a unique message
group identification, YantraMessageGroupID before it is sent to the next component
in the service definition framework. Once the end of the file is reached, an EOF
message is created with the same message group ID. This EOF message is useful if
special processing needs to be done at the end of each file.

Rules for creating EOF messages:

If you are using the Sterling Selling and Fulfillment FoundationApplication File IO
adapter component, the same unique message group ID is added and the message
header is appended to each message by default.

Chapter 24. Transport Nodes 559


The following are the rules for creating EOF messages when using a third party
component and integrating with Sterling Selling and Fulfillment
FoundationApplication:
v The EOF message must be of the format:
<EOF YantraMessageGroupID="Mandatory" />
v The XML root node name must be EOF and the YantraMessageGroupId is a
required attribute. This attribute is essential in identifying all messages that
belong to a group.
v When Sterling Selling and Fulfillment FoundationApplication is writing the EOF
messages to a JMS queue or a Database, then a message header with
MessageType="EOF" is created by the framework.

Note: If you are using a third party component for writing EOF messages into
JMS queues or Database, then you should make sure that the EOF message has a
header of MessageType="EOF".

Example scenario for creating EOF messages

The steps involved in creating EOF messages and processing the messages in a
JMS queue or a database is explained in detail with a sample XML file as an input
to the File I/O adapter.

The following figure shows the service framework with a File IO component.

1. The input file can be a delimited file, text file or an XML file. In this example
we consider an XML file.

<Items Attr1="Value1" Attr2="Value2" Attr3="Value3" >


<Item ItemId="Item1" />
<Item ItemId="Item2" />
<Item ItemId="Item3" />
</Items>

Figure 32. Sample Input File from File I/O Node

2. The parsed input XML file of each child node is then passed into the JMS
queue or a Database as a separate message.
3. The framework then appends all the input XML files root node attributes to
each of the message put in the queue.

Note: If the input XML's root node does not contain a YantraMessageGroupID,
the framework generates a unique ID and append to each message put into the
queue.
If the input files are non-XML files then the root node attributes does not get
included in the EOF node. It would contain the attributes given below:
<EOF YantraMessageGroupID="file1.txt.001" FileName=""
FileSize="" LastModifiedTime="" />
4. The EOF element contains the attributes in the root element of the input XML
file along with the file name, file size (in bytes) and the last modified time of
the file.

560 Sterling Selling and Fulfillment Foundation: Application Platform Configuration Guide
Modifying the JMS Queue and Database Receiver to Handle EOF
Messages
The messages received at the queue or the database is explained with the example
as described in Figure 33.

Figure 33. Output Messages created in the JMS queue or Database

1. <Item YantraMessageGroupID="file1.txt.001"
ItemID="Item1" Attr1="Value1" Attr2="Value2" Attr3="Value3"/>
/>
2. <Item YantraMessageGroupID="file1.txt.001"
ItemID="Item2" Attr1="Value1" Attr2="Value2" Attr3="Value3"
/>
<Item YantraMessageGroupID="file1.txt.001"
ItemID="Item3" Attr1="Value1" Attr2="Value2" Attr3="Value3"
/>
4. <EOF YantraMessageGroupID="file1.txt.001" ItemID="Item4"
Attr1="Value1" Attr2="Value2" Attr3="Value3" FileName=""
FileSize="" LastModifiedTime="" />
1. Once the EOF is reached the messages received by the JMS queue or Database
the framework checks whether the EOF has the same message group ID.
2. You must configure the JMS queue or Database receiver component to enable a
service to be invoked when the EOF message is received. If a service is not
invoked then an exception is thrown.
3. The framework is set wait for a certain amount of time which can be
configured in the <INSTALL_DIR>/properties/customer_overrides.properties
file, before calling the service.
For additional information about overriding properties using the
customer_overrides.properties file, see the Sterling Selling and Fulfillment
Foundation: Properties Guide.
In general, the XML file passed to the service must have a root node name as
EOF. However, you can specify a custom root node name instead of EOF. This
node name is specified in the JMS queue or Database receiver properties.
For example, when you customize the root node name as Root Node Name Of
EOF Message: NewRootNode and Service to execute on EOF Message:
NewService, add the XML attributes that must be included in the input to the
NewService with the with the MessageType value as "EOF" as follows:
<EOF YantraMessageGroupID='123' />
The input to the NewService would be constructed as <NewRootNode
YantraMessageGroupID=’123’/>

Error Handling by Integration Server:

When an EOF file message reaches the integration server it is checked for any
reprocessable messages for this service with the same YantraMessageGroupID. If
there are any pending error messages to be reprocessed, then the EOF messages
are marked as reprocessable. This error messages are then inserted into the
YFS_REPROCESS_TABLE.

Chapter 24. Transport Nodes 561


File Transfer Protocol (FTP)
The FTP node allows for sending and receiving files. Files residing in a local
directory are sent to a remote directory on an FTP server. Files residing in a remote
directory are received from an FTP server and stored in a local directory.

Note: Ensure that all source and destination directories and files have read/write
permissions for the remote user specified and for the user running the Integration
Server.

Note: The FTP server is not multi-threaded.

FTP Sender
Configuration Properties

The following are the properties of this node:


Table 439. FTP Sender Configuration Properties
Attribute Description
Runtime Tab
Sub Service Name Enter a unique identifier for each asynchronous receiver within a
service definition.
Server Address Enter the IP address of the remote FTP server.
Port Enter the port number of the remote FTP server. Default is port
21.
User ID Enter the login ID to use on the FTP server.
Polling Frequency Enter the time in seconds to poll the source directory for
unprocessed files.
Includes Pattern Enter the regular expression pattern of the files to retrieve. If not
specified all files in the working directory are included.

The following are examples of regular Perl expressions that can


be used:
v .*\.txt - All text files.
v temp.\.txt - All text files containing the pattern of ‘temp'.
Password Enter the password to use on the FTP server
Binary Transfer Select this option to transfer data that contains non-ascii
characters.
ASCII Transfer Select this option to transfer text files.
Compress File Select this field to compress and deliver a compressed file to the
remote FTP server.
Local Zip Completion If Compress File is selected, enter the directory in which the
Dir compressed file is to be stored. If you are using variables instead
of the full path names ensure that the variable is defined in the
<INSTALL_DIR>/properties/customer_overrides.properties file.
For additional information about overriding properties using the
customer_overrides.properties file, see the Sterling Selling and
Fulfillment Foundation: Properties Guide.
Source File Parameters Tab

562 Sterling Selling and Fulfillment Foundation: Application Platform Configuration Guide
Table 439. FTP Sender Configuration Properties (continued)
Attribute Description
Working Directory Enter the directory on the FTP server from which files are
transferred.
Note: Ensure the directory has the appropriate read/write
permissions and that the full path name has been specified. If
you are using variables instead of the full path names ensure that
the variable is defined in the <INSTALL_DIR>/properties/
customer_overrides.properties file. For additional information
about overriding properties using the
customer_overrides.properties file, see the Sterling Selling and
Fulfillment Foundation: Properties Guide.
Completion Directory Enter the remote completion directory files are to be moved to
after they are successfully transferred from the remote staging
directory.
Note: Ensure the directory has the appropriate read/write
permissions and that the full path name has been specified. If
you are using variables instead of the full path names ensure that
the variable is defined in the <INSTALL_DIR>/properties/
customer_overrides.properties file. For additional information
about overriding properties using the
customer_overrides.properties file, see the Sterling Selling and
Fulfillment Foundation: Properties Guide.
File Separator Enter the file separator used on the FTP server. The file separator
is the folder delimiter specified by the FTP server's settings. This
is most commonly represented as a forward slash ('/'). This field
is mandatory.
Completion Suffix Enter the suffix to append the file when the file from the remote
working directory is moved into the remote completion directory.
Destination File Properties Tab
Working Directory Enter the directory in which the files received are transferred to.
Note: Ensure the directory has the appropriate read/write
permissions and that the full path name has been specified. If
you are using variables instead of the full path names ensure that
the variable is defined in the <INSTALL_DIR>/properties/
customer_overrides.properties file. For additional information
about overriding properties using the
customer_overrides.properties file, see the Sterling Selling and
Fulfillment Foundation: Properties Guide.
Completion Directory Enter the local completion directory files are to be moved to after
they are successfully transferred from the remote working
directory.
Note: Ensure the directory has the appropriate read/write
permissions and that the full path name has been specified. If
you are using variables instead of the full path names ensure that
the variable is defined in the <INSTALL_DIR>/properties/
customer_overrides.properties file. For additional information
about overriding properties using the
customer_overrides.properties file, see the Sterling Selling and
Fulfillment Foundation: Properties Guide.
File Separator Enter the file separator used on the FTP server. This field is
mandatory.
Completion Suffix Enter the suffix to append the file when the file from the local
working directory is moved into the local completion directory.
Server Tab

Chapter 24. Transport Nodes 563


Table 439. FTP Sender Configuration Properties (continued)
Attribute Description
Server Name Enter the name of the server which actually executes the service.

For more information about creating a new server, see "Adding a


New Server".
Exception Tabs See Table 462 on page 602 for the receiver link exception
handling properties.

Note: Do not configure multiple instances of file receivers or senders trying to FTP
the same file. This can lead to file data loss.

FTP Receiver
Configuration Properties
The following are the properties of this node:
Table 440. FTP Receiver Configuration Properties
Attribute Description
Runtime Tab
Sub Service Name Enter a unique identifier for each asynchronous receiver within a
service definition.
Server Address Enter the IP address or host name of the remote FTP server.
Port Enter the port number of the remote FTP server. Defaults to port
21.
User ID Enter the login ID to use on the FTP server.
Polling Frequency Enter the time in seconds to poll the source directory for
unprocessed files.
Includes Pattern Enter the regular expression pattern of the files to retrieve. If not
specified all files are included in the working directory.

The following are examples of regular Perl expressions that can


be used:
v .*\.txt - All text files.
v temp.\.txt - All text files containing the pattern of ‘temp'.
Password Enter the password to use on the FTP server.
Binary Transfer Select this option to transfer data that contains non-ascii
characters.
ASCII Transfer Select this option to transfer text files.
Decompress File Select this field if the file being received is compressed.
Source File Parameters Tab
Working Directory Enter the directory on the FTP server from which files are to be
transferred.
Note: Ensure the directory has the appropriate read/write
permissions and that the full path name has been specified. If
you are using variables instead of the full path names ensure that
the variable is defined in the <INSTALL_DIR>/properties/
customer_overrides.properties file. For additional information
about overriding properties using the
customer_overrides.properties file, see the Sterling Selling and
Fulfillment Foundation: Properties Guide.

564 Sterling Selling and Fulfillment Foundation: Application Platform Configuration Guide
Table 440. FTP Receiver Configuration Properties (continued)
Attribute Description
Completion Directory Enter the completion directory. After successfully transferred
from the remote staging directory, the file is moved on the server
into the completion directory.
Note: Ensure the directory has the appropriate read/write
permissions and that the full path name has been specified. If
you are using variables instead of the full path names ensure that
the variable is defined in the <INSTALL_DIR>/properties/
customer_overrides.properties file. For additional information
about overriding properties using the
customer_overrides.properties file, see the Sterling Selling and
Fulfillment Foundation: Properties Guide.
File Separator Enter the file separator used on the FTP server. The file separator
is the folder delimiter specified by the FTP server's settings. This
is most commonly represented as a forward slash ('/'). This field
is mandatory.
Completion Suffix Enter the suffix to append the file when the file from the remote
working directory is moved into the remote completion directory.
Destination File Properties Tab
Working Directory Enter the directory in which the files received are transferred to.
Note: Ensure the directory has the appropriate read/write
permissions and that the full path name has been specified. If
you are using variables instead of the full path names ensure that
the variable is defined in the <INSTALL_DIR>/properties/
customer_overrides.properties file. For additional information
about overriding properties using the
customer_overrides.properties file, see the Sterling Selling and
Fulfillment Foundation: Properties Guide.
Completion Directory Enter the completion directory. After a file is transferred
successfully from the remote working directory, it is subsequently
moved to the local completion directory.
Note: Ensure the directory has the appropriate read/write
permissions and that the full path name has been specified. If
you are using variables instead of the full path names ensure that
the variable is defined in the <INSTALL_DIR>/properties/
customer_overrides.properties file. For additional information
about overriding properties using the
customer_overrides.properties file, see the Sterling Selling and
Fulfillment Foundation: Properties Guide.
File Separator Enter the file separator used on the FTP server. This field is
mandatory.
Completion Suffix Optional. The suffix to append the file when the file from the
local working directory is moved into the local completion
directory.
Server Tab
Server Name Enter the name of the server which actually executes the service.

For more information about creating a new server, see "Adding a


New Server".
Exception Tabs See Table 462 on page 602 for the receiver link exception
handling properties.

Chapter 24. Transport Nodes 565


Note: Do not configure multiple instances of file receivers or senders trying to FTP
the same file. This can lead to file data loss.

Connection Properties

The following are the FTP node's connection properties:


Table 441. FTP Connection Properties
Connection Node Connection Rules
Can be the first node after Only for services invoked asynchronously
the start node
Can be placed before v File I/O transport node
v End node
v Pass-through cannot follow FTP
Can be placed after v Start node, only for asynchronously invoked services
v File I/O transport node.
v Pass-through cannot precede FTP
Passes data unchanged Transport nodes do not modify data

Hypertext Transport Protocol (HTTP)


The HTTP transport node defines the way synchronous messages are sent using
the HTTP post method. The HTTP transport node has sender-related properties.

Configuration Properties

The following are the properties of this node:


Table 442. HTTP Configuration Properties
Property Description
URL Enter the URL to which the message is to be posted.
HTTP Post Variable Enter the variable name to which the HTTP post data is to be
assigned.
Is Secure If this field is selected, the message is encrypted when being
posted to the URL specified.
Key Store Type If Is Secure is checked, set this value to JKS (Java Key Store).
Key Store If Is Secure is selected, enter the key store for storing client side
digital certificates. If you are using variables instead of the full
path names ensure that the variable is defined in the
<INSTALL_DIR>/properties/customer_overrides.properties
file. For additional information about overriding properties
using the customer_overrides.properties file, see the Sterling
Selling and Fulfillment Foundation: Properties Guide.
Key Store Passwd If Is Secure is selected, enter the password to access the key
store.

566 Sterling Selling and Fulfillment Foundation: Application Platform Configuration Guide
Table 442. HTTP Configuration Properties (continued)
Property Description
Trust Store If Is Secure is selected, enter the trust store for storing server
side digital certificates. If you are using variables instead of the
full path names ensure that the variable is defined in the
<INSTALL_DIR>/properties/customer_overrides.properties
file. For additional information about overriding properties
using the customer_overrides.properties file, see the Sterling
Selling and Fulfillment Foundation: Properties Guide.
Trust Store Passwd If Is Secure is selected, enter the password to access the trust
store.

Note: Making a secure HTTP call requires modifying the <JAVA_HOME>/jre/lib/


security/java.security file. Comment the following line from the file:
security.provider.2=com.sun.rsajca.Provider

Commenting the property enables the runtime loading of the security.provider


variable set later in the code. If you do not want to change the common Java
Security file, refer to BEA documentation about using the weblogic.policy file and
modify it accordingly. Use the weblogic.policy file with the necessary changes as
suggested on the BEA web site at: http://download.oracle.com/docs/cd/
E13222_01/wls/docs81/index.html#1091743

You can enable the Java Security Manager to use the Oracle webLogic.policy
security policy file by adding these parameters to the Oracle WebLogic startup
script:

java -Djava.security.manager -Djava.security.policy=<WLS_HOME>/lib/


weblogic.policy:wConnection Properties

The following are the HTTP node's connection properties:


Table 443. HTTP Connection Properties
Connection Node Connection Rules
Can be the first node after Only for services invoked synchronously
the start node
Can be placed before v Any transport node except for FTP or File I/O
v Any other component node
Can be placed after v Start node
v Any synchronous transport node
v Any other component node
v Any asynchronous transport node (except for FTP or File
I/O); use a Pass-through node to connect them
Passes data unchanged Transport nodes do not modify data

WebService
This WebService transport node allows the Service Definition Framework to make
outbound webservice calls. For more information about WebServices and how to
create the smcfs<application_name>.ear, see the Sterling Selling and Fulfillment
Foundation: Installation Guide.

Chapter 24. Transport Nodes 567


Note: Webservice SDF component is deprecated and will be removed in the future
version. It is recommended that you do not use the WebServices SDF component
to invoke WebServices. Instead, create a custom API to invoke WebServices.

Note: WebServices cannot be used to call APIs in backward compatibility mode.


Also, outbound WebService calls using the Service Builder do not support HTTPS
protocol.

Configuration Properties

The following are the properties of this node:


v Configurable depending on your app server:
– Oracle WebLogic
– IBM Websphere
– JBoss

For IBM WebSphere,


Pass -D websphere-java2wsdl-style=<rpc|document> in the ear command line

For JBoss,
Pass -D jboss-java2wsdl-style=<rpc|document> in the ear command line.

For Oracle WebLogic, use document literal.

For JBoss based on variable

Build Ear.sh documentation where it talks about style of coding

Oracle WebLogic and IBM Websphere are supported and parameterizable and the
other supported for document literal.
Table 444. WebServices Configuration Properties
Property Description
General Tab
URL Enter the URL to which the message is to be posted. For
example, http://localhost:7001/smcfs<application_name>ejb/
services
Target Object URN Enter the web service's resource name. For example,
yantrawebservice
Are Sterling Selling and Check this box to indicate that this service is calling a Sterling
Fulfillment Selling and Fulfillment FoundationApplication Webservice.
FoundationApplication
Webservice If you check this box, the parameter name defaults to
apiString and the Parameter Name text box on this tab is
disabled.
Parameter Name Enter the name of the document parameter.
Encoding Style URI Enter the name of the encoding you want to use. For example,
http://schemas.xmlsoap.org/soap/encoding/
Method Name Enter the name of the method you want to invoke.
Is Secure If this field is selected, the message is encrypted when being
posted to the URL specified.

568 Sterling Selling and Fulfillment Foundation: Application Platform Configuration Guide
Table 444. WebServices Configuration Properties (continued)
Property Description
Trust Store If Is Secure is selected, enter the trust store for storing server
side digital certificates. If you are using variables instead of the
full path names ensure that the variable is defined in the
<INSTALL_DIR>/properties/customer_overrides.properties
file. For additional information about overriding properties
using the customer_overrides.properties file, see the Sterling
Selling and Fulfillment Foundation: Properties Guide.
Trust Store Passwd If Is Secure is selected, enter the password to access the trust
store.
Key Store Type If Is Secure is checked, set this value to JKS (Java Key Store).
Key Store If Is Secure is selected, enter the key store for storing client side
digital certificates. If you are using variables instead of the full
path names ensure that the variable is defined in the
<INSTALL_DIR>/properties/customer_overrides.properties
file. For additional information about overriding properties
using the customer_overrides.properties file, see the Sterling
Selling and Fulfillment Foundation: Properties Guide.
Key Store Passwd If Is Secure is selected, enter the password to access the key
store.
SOAPActionURI Enter the URI used by this attribute to invoke the required
outbound web service. For example, http://tempuri.org/
PricingEngineGold/Service1/PricingEngineFunc can be a valid
input URI.
Arguments Tab
Argument Name The name of the parameter to be passed to the Webservice
method.
Argument Value The value of the parameter to be passed to the Webservice
method.

Connection Properties

The following are the WebServices node's connection properties:


Table 445. WebServices Connection Properties
Connection Node Connection Rules
Can be the first node after Only for services invoked synchronously
the start node
Can be placed before v Any transport node except for FTP or File I/O
v Any other component node
Can be placed after v Start node
v Any synchronous transport node
v Any other component node
v Any asynchronous transport node (except for FTP or File
I/O); use a Pass-through node to connect them
Passes data unchanged Transport nodes do not modify data

Chapter 24. Transport Nodes 569


Synchronous Oracle WebLogic and MQSeries
The synchronous MQSeries and Oracle WebLogic transport nodes allow request
and response operations using JMS queues. If the response is not received within a
defined period, an exception is thrown.

Identification of appropriate response messages is done with a header field named


MESSAGEID. When the request message is put into the queue, the MESSAGEID
header is set to a unique value based on the current time and a counter. The
response headers must have this same message ID for it to be picked up and
processes correctly.

Note: In the case of MQSeries queues, when there are more threads running than
messages available for pickup, the following message may appear in the adapter
window:

2002.02.25 09:25:53 MQJMS2002E failed to get message from MQ queue

Note: If you are running on IBM AIX® and using MQSeries, include the following
environment variable in the application server launch script, integration adapter
script, and all agent server scripts:
LDR_CNTRL=MAXDATA=0x30000000
export LDR_CNTRL

Configuration Properties

The following are the properties of this node:


Table 446. Synchronous WebLogic JMSQueue and MQSeries Properties
Property Description
Runtime Tab
Provider URL Enter the provider URL of the JMS implementation used. This
is the URL to use for JNDI lookups.
v For MQSeries using Oracle WebLogic, set the property (for
file system context) to file:[drive:]/<pathname> and ensure
that the directory exists in your environment.
v For Oracle WebLogic JMS, set to t3://<DNS Server Name or
IP Address>:<port>.
Initial Context Factory The class name of the initial context factory. This is the starting
point for the resolution of names for naming and directory
operations.

Select WebSphere MQ if you are using MQSeries accessed


through a IBM WebSphere IIOP URL. This sets the class name
to com.ibm.websphere.naming.
WsnInitialContextFactory.

Select File if you are using MQSeries accessed through a file


URL, as with Oracle WebLogic. This sets the class name to
com.sun.jndi.fscontext.
RefFSContextFactory.

Select WebLogic if you are using Oracle WebLogic JMS. This


sets the class name to weblogic.jndi.
WLInitialContextFactory.

570 Sterling Selling and Fulfillment Foundation: Application Platform Configuration Guide
Table 446. Synchronous WebLogic JMSQueue and MQSeries Properties (continued)
Property Description
QCF Lookup Enter the queue connection factory name. This is used to
retrieve the queue connection factory from JNDI. A client uses a
queue connection factory to create queue connections with a
JMS provider. Enter any unique identifier for the QCF lookup.
This name must be the same as that configured in the Oracle
WebLogic console or MQSeries.
Needs Compression Select this option if the message needs to be compressed.
Enable JMS Security Check this box if you want JMS Security to be enabled. Once
selected, the JMS Security Properties tab is enabled to configure
Queue and/or JNDI based JMS security.
Note: Oracle WebLogic 10.3 only supports JNDI based JMS
security. If queue based security is enabled, it is altogether
bypassed. Therefore, you must configure JNDI based JMS
security if using Oracle WebLogic 10.3.
Note: If JMS security is enabled, the JMS session pooling
should be disabled. You can disable JMS session pooling by
setting the yfs.jms.session.disable.pooling property to 'Y' in the
<INSTALL_DIR>/properties/customer_overrides.properties
file. For additional information about overriding properties
using the customer_overrides.properties file, see the Sterling
Selling and Fulfillment Foundation: Properties Guide.
Response Tab
Queue Name Enter the name of the queue in which the response message is
received.
Selector Enter selectors based on the message headers. When specifying
a selector, use only single quotes. For example, specifying the
selector APINAME='createOrder' selects all messages with a
header name='APINAME' and value='createOrder'.
Time Out (seconds) Enter the time interval (in seconds) after which the requests
time out.
Request Tab
Queue Name Enter the name of the queue to which the request message is
sent.
Header Name The name of the message header. For example, APINAME.
Note: The header name must be unique. Two headers cannot
have the same header name.

Choose to add a new header name and value.

Choose to modify an existing header name and value.

Choose to delete an existing header name and value.

Chapter 24. Transport Nodes 571


Table 446. Synchronous WebLogic JMSQueue and MQSeries Properties (continued)
Property Description
Header Value The value associated with the Header Name. These name-value
pairs are stored as message headers and can be queried by
using message selectors.

This can be set to a static value. For example, ‘createOrder'


results in the message having a header APINAME=createOrder'

It can also be set to be dynamically extracted from the message


using the syntax xml://<full path of the element from
root>/@<attribute name>, which results in the message with a
header APINAME='<value of attribute name in the XML>'.
Reconnect Tab
Retry Interval In the event that the connection to the JMS server has been lost,
(milliseconds) enter the amount of time between each attempt to re-establish
contact with the JMS server. This parameter is used in
conjunction with the Number of Retries parameter. The default
value is 0, implying no delay time between retry attempts.
Number of Retries In the event that the connection to the JMS server has been lost,
enter the number of attempts to re-establish contact with the
JMS server before throwing an exception. This parameter is
used in conjunction with the Retry Interval parameter. The
default value is 0, implying no retries if the connection is lost
and an exception is thrown immediately.
JMS Security Properties Tab

This is enabled upon selecting Enable JMS Security in the runtime properties tab.
Note: You can override the JMS security properties specified here by defining the agent
and flow authorization parameters in the <INSTALL_DIR>/properties/
customer_overrides.properties file. For additional information about overriding
properties using the customer_overrides.properties file, see the Sterling Selling and
Fulfillment Foundation: Properties Guide.
Queue based security Check this box, if you want to provide Queue based security
for JMS service.
Note: Oracle WebLogic 10.3 only supports JNDI based JMS
security. If queue based security is enabled, it is altogether
bypassed. Therefore, you must configure JNDI based JMS
security if using Oracle WebLogic 10.3.
JNDI based security Check this box, if you want to provide JNDI based security for
JMS service.
JMS Security Parameters

For more information about application server-specific JMS security parameters, see
"Setting up the JMS Security Properties" section.
Parameter Name Enter the name of the Oracle security parameter.
Parameter Value Enter the value of the security parameter.

Note: The JMS session objects can be pooled based on the service being executed.
Hence, whenever the JMS sender requires a session object, the Sterling Application
Platform framework tries to get a free session object from the pool. If there are no
free sessions available, a new session object is created to send the message and
then added to the pool. Any session object that is idle for a certain configurable
period of time is closed by the framework. The yfs.jms.session.reaptime
property in the yfs.properties file is used to set the JMS session reaptime. To

572 Sterling Selling and Fulfillment Foundation: Application Platform Configuration Guide
modify this property, add an entry for it in the <INSTALL_DIR>/properties/
customer_overrides.properties file. For additional information about overriding
properties using the customer_overrides.properties file, see the Sterling Selling
and Fulfillment Foundation: Properties Guide

Connection Properties

The following are the synchronous Oracle WebLogic JMSQueue and MQSeries
nodes' connection properties:
Table 447. Synchronous WebLogic JMSQueue and MQSeries Properties
Connection Node Connection Rules
Can be the first node after Only for services invoked synchronously
the start node
Can be placed before v Any transport node except for FTP or File I/O
v Any other component node
Can be placed after v Start node
v Any synchronous transport node
v Any other component node
v Any asynchronous transport node (except for FTP or File
I/O); use Pass-through node to connect.
Passes data unchanged Transport nodes do not modify data

Oracle WebLogic, MQSeries, and TIBCO JMS Queue


This component provides a common interface to invoke messaging services on
WebLogic, MQSeries, and TIBCO JMS queues. You can specify the required
configuration properties in this component for enabling your JMS queues.

Note: In the case of MQSeries queues, when there are more threads running than
messages available for pickup, the following message may appear in the adapter
window:
2002.02.25 09:25:53 MQJMS2002E failed to get message from MQ queue

Note: If you are running on IBM AIX and using MQSeries, include the following
environment variable in the application server launch script, integration adapter
script, and all agent server scripts:
LDR_CNTRL=MAXDATA=0x30000000
export LDR_CNTRL

Oracle WebLogic, MQSeries, and TIBCO JMS Queue Sender


The JMS sender caches a single connection starting with the primary queue. When
the message sending fails, the JMS sender retries to send the message a
configurable number of times with a configurable delay between each attempt as
defined in the Reconnect Tab of the following table. An exception is thrown if the
retries are exhausted and there is no backup queue.

If a backup queue is setup, a connection is made to the backup queue. The backup
queue becomes the current queue for the next message sending attempt. The

Chapter 24. Transport Nodes 573


sender can be configured to reconnect to the primary queue. If the primary queue
is found to be working then a switch is made so that the primary queue becomes
the current queue.

Configuration Properties

The following are the configuration properties of these nodes:


Table 448. WebLogic, MQSeries, and TIBCO JMS Sender Configuration Properties
Property Description
Runtime Tab

You need to use the settings in this tab for the primary JMS server.
Queue Name Enter the name of the queue to which the message is sent.
Time To Live Enter the time period after which the messages are to be
deleted from the queue. A value of zero causes the message to
never be deleted from the queue.

If this is set to a non-zero value, messages in the queue that are


not consumed for the specified time interval are automatically
deleted from the queue by the provider.
Provider URL Enter the provider URL of the JMS implementation used. This
is the URL to use for JNDI lookups.
v For MQSeries using Oracle WebLogic, set the property (for
file system context) to file:[drive:]/<pathname> and ensure
that the directory exists in your environment.
v For Oracle WebLogic JMS, set to t3://<DNS Server Name or
IP Address>:<port>
v For TIBCO JMS, set to tcp://<DNS Server Name or IP
Address>:<port>
Initial Context Factory The class name of the initial context factory. This is the starting
point for the resolution of names for naming and directory
operations.

Select WebSphere MQ if you are using MQSeries accessed


through a IBM WebSphere IIOP URL. This sets the class name
to com.ibm.websphere.naming.
WsnInitialContextFactory.

Select File if you are using MQSeries accessed through a file


URL, as with Oracle WebLogic. This sets the class name to
com.sun.jndi.fscontext.
RefFSContextFactory.

Select WebLogic if you are using Oracle WebLogic JMS. This


sets the class name to weblogic.jndi.
WLInitialContextFactory.

Select TIBCO if you are using TIBCO JMS. This sets the class
name to
com.tibco.tibjms.naming.TibjmsInitialContextFactory.
QCF Lookup Enter the queue connection factory name. This is used to
retrieve the queue connection factory from JNDI. A client uses a
queue connection factory to create queue connections with a
JMS provider. Enter any unique identifier for the QCF lookup.
This name must be the same as that configured in the Oracle
WebLogic console, MQSeries, or TIBCO.

574 Sterling Selling and Fulfillment Foundation: Application Platform Configuration Guide
Table 448. WebLogic, MQSeries, and TIBCO JMS Sender Configuration
Properties (continued)
Property Description
Delivery Mode Indicate if the messages are to be Persistent or Non-Persistent
when dropped into the queue.
Needs compression Optional. Check this box if the message needs to be
compressed before dropping into the queue.
Commit of this message Check this box if you want the message to be committed to the
depends on parent queue only after the service is completed.
transaction
Uncheck this box if you want the message to be committed to
the queue immediately.

For example, if the ON_SUCCESS event of any standard


Sterling Selling and Fulfillment FoundationApplication API is
attached to a service in which the message is transactionally
written to the queue, the message is committed to the queue
only upon successful completion of the ON_SUCCESS event.
The message is then rolled back from the queue if there is any
error in the ON_SUCCESS event after the message is staged.
However, in non-transactional mode, the message remains in
the queue once it is staged and is not rolled back.
Note: If you check this box, the system synchronizes the JMS
commit along with the DB commit. However, it is not a
two-phase commit. Therefore, it may cause some errors, thus
resulting in duplicate messages.
Enable JMS Security Check this box if you want JMS Security to be enabled. Once
selected, the JMS Security Properties tab is enabled to configure
Queue and/or JNDI based JMS security.
Note: Oracle WebLogic 10.3 only supports JNDI based JMS
security. If queue based security is enabled, it is altogether
bypassed. Therefore, you must configure JNDI based JMS
security if using Oracle WebLogic 10.3.
Note: If JMS security is enabled, the JMS session pooling
should be disabled. You can disable JMS session pooling by
setting the yfs.jms.session.disable.pooling property to 'Y' in the
<INSTALL_DIR>/properties/customer_overrides.properties
file. For additional information about overriding properties
using the customer_overrides.properties file, see the Sterling
Selling and Fulfillment Foundation: Properties Guide.
Header Tab
Header Name The name of the message header. For example, APINAME.
Note: The header name must be unique. Two headers cannot
have the same header name.

Choose to add a new header name and value.

Choose to modify an existing header name and value.

Choose to delete an existing header name and value.

Chapter 24. Transport Nodes 575


Table 448. WebLogic, MQSeries, and TIBCO JMS Sender Configuration
Properties (continued)
Property Description
Header Value The value associated with the Header Name. These name-value
pairs are stored as message headers and can be queried by
using message selectors.

This can be set to a static value. For example, ‘createOrder'


results in the message having a header
APINAME='createOrder'

It can also be set to be dynamically extracted from the message


using the syntax xml://<full path of the element from
root>/@<attribute name>, which results in the message with a
header APINAME=’<value of attribute name in the XML>’.
Reconnect Tab

You need to use the settings in this tab are for the backup JMS server.
Retry Interval In the event that the connection to the primary JMS server is
(milliseconds) lost, enter the amount of time between attempts to re-establish
contact with the primary JMS server. This parameter is used in
conjunction with the Number of Retries parameter. The default
value is 0 which means no delay time between retry attempts.
Number of Retries In the event that the connection to the primary JMS server is
lost, enter the number of attempts to re-establish contact with
the primary JMS server before failing over to the backup JMS
server, if enabled, or throwing an exception. This parameter is
used in conjunction with the Retry Interval parameter. The
default value is 0 which means there are no retries if the
connection is lost and either failover occurs, if enabled, or an
exception is thrown immediately.
Use backup JMS Queue Check this box if you want to enable a backup JMS queue.

Only upon selecting this checkbox, other controls in this tab are
enabled.
Provider URL Enter the backup JMS server provider URL of the JMS
implementation used. This is the URL to use for JNDI lookups.
v For MQSeries using a file URL, set the property (for file
system context) to file:[drive:]/<pathname> and ensure
that the directory exists in your environment.
v For Oracle WebLogic JMS, set to t3://<DNS Server Name or
IP Address>:<port>
v For IBM WebSphere JMS, set to corbaloc::<DNS Server Name
or IP Address>:<bootstrapport>
v For TIBCO JMS, set to tcp://<DNS Server Name or IP
Address>:<port>

576 Sterling Selling and Fulfillment Foundation: Application Platform Configuration Guide
Table 448. WebLogic, MQSeries, and TIBCO JMS Sender Configuration
Properties (continued)
Property Description
Initial Context Factory The class name of the initial context factory for the backup JMS
server. This is the starting point for the resolution of names for
naming and directory operations.
v Select WebSphere MQ if you are using MQSeries accessed
through a IBM WebSphere IIOP URL. This sets the class
name to
com.ibm.websphere.naming.WsnInitialContextFactory.
v Select File if you are using MQSeries accessed through a file
URL, as with Oracle WebLogic. This sets the class name to
com.sun.jndi.fscontext.RefFSContextFactory.
v Select Oracle WebLogic if you are using Oracle WebLogic
JMS. This sets the class name to weblogic.jndi.
WLInitialContextFactory.
v Select TIBCO if you are using TIBCO JMS. This sets the class
name to
com.tibco.tibjms.naming.TibjmsInitialContextFactory.
Queue Name Enter the name of the backup queue to which the message is
sent.
QCF Lookup Enter the back JMS server's queue connection factory name.
This is used to retrieve the queue connection factory from
JNDI. A client uses a queue connection factory to create queue
connections with a JMS provider. Enter any unique identifier
for the QCF lookup. This name must be the same as that
configured in the Oracle WebLogic console, MQSeries, or
TIBCO.
Reconnect To Primary Check this box if you want to reconnect to the primary JMS
JMS Queue queue after a failover to the backup JMS queue server has
occurred. Once this checkbox is selected, enter the wait time
before it reconnects.
Time Before Reconnect Enter the maximum amount of time between attempts to
(seconds) re-establish contact with the primary JMS server after a failover
to the backup JMS server. If contact is re-established with the
primary JMS server, it reverts back to using the primary JMS
server. If contact with the primary JMS server cannot be
established, it continues to use the backup JMS server. The
default value is 600 seconds.
JMS Security Properties Tab

This is enabled upon selecting Enable JMS Security in the runtime tab.
Note: You can override the JMS security properties specified here by defining the agent
and flow authorization parameters in the <INSTALL_DIR>/properties/
customer_overrides.properties file. For additional information about overriding
properties using the customer_overrides.properties file, see the Sterling Selling and
Fulfillment Foundation: Properties Guide.
Queue based security Check this box, if you want to provide Queue based security
for JMS service.
Note: Oracle WebLogic 10.3 only supports JNDI based JMS
security. If queue based security is enabled, it is altogether
bypassed. Therefore, you must configure JNDI based JMS
security if using Oracle WebLogic 10.3.
JNDI based security Check this box, if you want to provide JNDI based security for
JMS service.

Chapter 24. Transport Nodes 577


Table 448. WebLogic, MQSeries, and TIBCO JMS Sender Configuration
Properties (continued)
Property Description
JMS Security Parameters

For more information about application server-specific JMS security parameters, see
"Setting up the JMS Security Properties" section.
Parameter Name Enter the name of the security parameter
Parameter Value Enter the value of the security parameter.

Note: The JMS session objects can be pooled based on the service being executed.
Hence, whenever the JMS sender requires a session object, the Sterling Application
Platform framework tries to get a free session object from the pool. If there are no
free sessions available, a new session object is created to send the message and
then added to the pool. Any session object that is idle for a certain configurable
period of time is closed by the framework.

Note: The yfs.jms.session.reaptime property in the yfs.properties file is used


to set the JMS session reaptime. To modify this property, add an entry for it in the
<INSTALL_DIR>/properties/customer_overrides.properties file. For additional
information about overriding properties using the customer_overrides.properties
file, see the Sterling Selling and Fulfillment Foundation: Properties Guide.

Oracle WebLogic, MQSeries, and TIBCO JMS Receiver


The JMS receiver does not have a backup queue, therefore two different services
must be configured. One to listen on the primary queue and one to listen on the
backup queue. When an exception occurs, the receiver retries using an exponential
back off mechanism with a configurable maximum wait limit between retries.

For example, if 600 seconds is the maximum wait time, it first waits for 1 second,
then 2 seconds, 4, 8, 16 and so on exponentially until it reaches 600 seconds, after
which it retries every 600 seconds. So there is no bound on the total wait time.

Since the JMS receivers operate independently of each other with respect to the
primary and backup queues, the order of messages across these queues is not
supported.

Configuration Properties

The following are the configuration properties of this node:


Table 449. WebLogic, MQSeries, and TIBCO JMS Receiver Configuration Properties
Property Description
Runtime Tab
Sub Service Name Enter a unique identifier for each asynchronous receiver within
a service definition.
Queue Name Enter the name of the queue to which the message is sent.

578 Sterling Selling and Fulfillment Foundation: Application Platform Configuration Guide
Table 449. WebLogic, MQSeries, and TIBCO JMS Receiver Configuration
Properties (continued)
Property Description
Provider URL Enter the provider URL of the JMS implementation used. This
is the URL to use for JNDI lookups.
v For MQSeries using Oracle WebLogic, set the property (for
file system context) to file:[drive:]/<pathname> and ensure
that the directory exists in your environment.
v For Oracle WebLogic JMS, set to t3://<DNS Server Name or
IP Address>:<port>
v For TIBCO JMS, set to tcp://<DNS Server Name or IP
Address>:<port>
Initial Context Factory The class name of the initial context factory. This is the starting
point for the resolution of names for naming and directory
operations.

Select WebSphere MQ if you are using MQSeries accessed


through a IBM WebSphere IIOP URL. This sets the class name
to com.ibm.websphere.naming.
WsnInitialContextFactory.

Select File if you are using MQSeries accessed through a file


URL, as with Oracle WebLogic. This sets the class name to
com.sun.jndi.fscontext.
RefFSContextFactory.

Select Oracle WebLogic if you are using Oracle WebLogic JMS.


This sets the class name to weblogic.jndi.
WLInitialContextFactory.

Select TIBCO if you are using TIBCO JMS. This sets the class
name to
com.tibco.tibjms.naming.TibjmsInitialContextFactory.
QCF Lookup Enter the queue connection factory name. This is used to
retrieve the queue connection factory from JNDI. A client uses a
queue connection factory to create queue connections with a
JMS provider. Enter any unique identifier for the QCF lookup.
This name must be the same as that configured in the Oracle
WebLogic console, MQSeries, or TIBCO.
Receiving Mode Indicates whether the messages are received in a transactional
mode or non-transactional mode.
v If you set this to non-transactional mode, the messages are
removed from the queue as soon as it is read.
v If you set this to transactional mode, the messages are
removed from the queue when they are functionally
processed and if an exception is thrown when processing it.
Note: If the IsReprocessible flag is checked and an exception
occurs when processing the message, then before deleting these
messages, ensure that they are added to the
YFS_REPROCESS_ERROR or YFS_INBOX table. However, if
the "service suspend" exception occurs when adding these
deleted messages to a table, the messages are maintained in the
queue.

Chapter 24. Transport Nodes 579


Table 449. WebLogic, MQSeries, and TIBCO JMS Receiver Configuration
Properties (continued)
Property Description
Initial Threads Enter the number of threads that can process messages
simultaneously. Based on your throughput, you can increase
the number of threads to enhance performance using the
System Management Console. For more information about
using the System Management Console, see the Sterling Selling
and Fulfillment Foundation: System Management and
Administration GuidePlatform System Management and
Administration Guide.

You can also start multiple instances of the Service Definition


Framework for a specific integration adapter for a specific
server. For more information about the integration adapter, see
the Sterling Selling and Fulfillment Foundation: Performance
Management Guide.
Selector Enter selectors based on the message headers. These selectors
must be in the form Header Name='Header Value'. When
specifying a selector, use only single quotes. For example, using
the selector APINAME='createOrder' selects all messages with a
header name='APINAME' and value='createOrder'.
Service to Execute on Required if the message contains an EOF message ID.
EOF Message
Choose to select the service to be invoked when an EOF
message is received. Once the EOF message is received, the
framework waits for a few minutes (configurable in the
<INSTALL_DIR>/properties/customer_overrides.properties
file) before executing this service. For more information see,
“Enabling EOF Messages in the Application Platform
Framework” on page 559. For additional information about
overriding properties using the customer_overrides.properties
file, see the Sterling Selling and Fulfillment Foundation: Properties
Guide.
Root Node Name of EOF If the message contains an EOF message ID, enter your custom
Message root node name for the EOF message.

By default the end of file message has a root node of "EOF". For
more information see, “Enabling EOF Messages in the
Application Platform Framework” on page 559.
Enable JMS Security Check this box if you want JMS Security to be enabled. Once
selected, the JMS Security Properties tab is enabled to configure
Queue and/or JNDI based JMS security.
Note: Oracle WebLogic 10.3 only supports JNDI based JMS
security. If queue based security is enabled, it is altogether
bypassed. Therefore, you must configure JNDI based JMS
security if using Oracle WebLogic 10.3.
Server Tab
Server Name Select the name of the server which actually executes the
service.

For more information about creating a new server, see "Adding


a New Server".
Needs Decompression Select this field to indicate that the incoming message is
compressed and needs to be decompressed.

580 Sterling Selling and Fulfillment Foundation: Application Platform Configuration Guide
Table 449. WebLogic, MQSeries, and TIBCO JMS Receiver Configuration
Properties (continued)
Property Description
Exception Tabs See Table 462 on page 602 for the receiver link exception
handling properties.
Reconnect Tab
Maximum Time Between Enter the maximum time between reconnection attempts. The
Retries (minutes) default value is 10 minutes.
JMS Security Properties Tab

This is enabled upon selecting Enable JMS Security in the runtime tab.
Note: You can override the JMS security properties specified here by defining the agent
and flow authorization parameters in the <INSTALL_DIR>/properties/
customer_overrides.properties file. For additional information about overriding
properties using the customer_overrides.properties file, see the Sterling Selling and
Fulfillment Foundation: Properties Guide.
Queue based security Check this box, if you want to provide Queue based security
for JMS service.
Note: Oracle WebLogic 10.3 only supports JNDI based JMS
security. If queue based security is enabled, it is altogether
bypassed. Therefore, you must configure JNDI based JMS
security if using Oracle WebLogic 10.3.
JNDI based security Check this box, if you want to provide JNDI based security for
JMS service.
JMS Security Parameters

For more information about application server-specific JMS security parameters, see
"Setting up the JMS Security Properties" section.
Parameter Name Enter the name of the security parameter.
Parameter Value Enter the value of the security parameter.

Connection Properties

The following are the WLJMS and MQJMS nodes' connection properties:
Table 450. WebLogic JMS and MQSeries JMS Connection Properties
Connection Node Connection Rules
Can be the first node after Yes, for services invoked both in a synchronous or
the start node asynchronous mode
Can be placed before v Any component node
v Any transport node (except for FTP or File I/O); use a
Pass-through node to connect them
Can be placed after v Start node
v Any synchronous transport node
v Any other component node
v Any asynchronous transport node (except for FTP or File
I/O); use a Pass-through node to connect them
Passes data unchanged Transport nodes do not modify data

Chapter 24. Transport Nodes 581


IBM WebSphere Default Messaging JMS Queue
This component provides a common interface to invoke messaging services on IBM
WebSphere Default Messaging JMS queues. You can specify the required
configuration properties by using the MQSeries component node.

IBM WebSphere Default Messaging JMS Queue Sender


The JMS sender caches a single connection starting with the primary queue. When
the message sending fails, the JMS sender retries to send the message a
configurable number of times with a configurable delay between each attempt as
defined in the Reconnect Tab of the following table. An exception is thrown if the
retries are exhausted and there is no backup queue.

If a backup queue is setup, a connection is made to the backup queue. The backup
queue becomes the current queue for the next message sending attempt. The
sender can be configured to reconnect to the primary queue. If the primary queue
is found to be working then a switch is made so that the primary queue becomes
the current queue.

Configuration Properties

The following are the configuration properties of these nodes:


Table 451. WebSphere Default Messaging JMS Queue Sender Configuration Properties
Property Description
Runtime Tab

You need to use the settings in this tab for the primary JMS server.
Queue Name Enter the name of the queue to which the message is sent.
Time To Live Enter the time period after which the messages are to be
deleted from the queue. A value of zero causes the message to
(seconds) never be deleted from the queue.

If this is set to a non-zero value, messages in the queue that are


not consumed for the specified time interval are automatically
deleted from the queue by the provider.
Provider URL Enter the provider URL of the JMS implementation used. This
is the URL to use for JNDI lookups.
v For IBM WebSphere Default Messaging JMS Queue, set to
corbaloc::<DNS Server Name or IP
Address>:<bootstrapport>
Initial Context Factory The class name of the initial context factory. This is the starting
point for the resolution of names for naming and directory
operations.

Select WebSphere MQ if you are using IBM WebSphere Default


Messaging JMS Queue. This sets the class name to

com.ibm.websphere.naming.
WsnInitialContextFactory.

582 Sterling Selling and Fulfillment Foundation: Application Platform Configuration Guide
Table 451. WebSphere Default Messaging JMS Queue Sender Configuration
Properties (continued)
Property Description
QCF Lookup Enter the queue connection factory name. This is used to
retrieve the queue connection factory from JNDI. A client uses a
queue connection factory to create queue connections with a
JMS provider. Enter any unique identifier for the QCF lookup.
This name must be the same as that configured in the IBM
WebSphere administration console.
Persistent Select this option if you want the messages to be persistent
when dropped into the queue.
Non Persistent Select this option if you want the messages to be not persistent
when dropped into the queue.
Needs compression Optional. Check this box if the message needs to be
compressed before dropping into the queue.
Commit of this message Check this box if you want the message to be committed to the
depends on parent queue only after the service is completed.
transaction
Uncheck this box if you want the message to be committed to
the queue immediately.

For example, if the ON_SUCCESS event of any standard


Sterling Selling and Fulfillment FoundationApplication API is
attached to a service in which the message is transactionally
written to the queue, the message is committed to the queue
only upon successful completion of the ON_SUCCESS event.
The message is then rolled back from the queue if there is any
error in the ON_SUCCESS event after the message is staged.
However, in non-transactional mode, the message remains in
the queue once it is staged and is not rolled back.
Note: If you check this box, the system synchronizes the JMS
commit along with the DB commit. However, it is not a
two-phase commit. Therefore, it may cause some errors, thus
resulting in duplicate messages.
Enable JMS Security Check this box if you want JMS Security to be enabled. Once
selected, the JMS Security Properties tab is enabled to configure
Queue and/or JNDI based JMS security.
Note: Oracle WebLogic 10.3 only supports JNDI based JMS
security. If queue based security is enabled, it is altogether
bypassed. Therefore, you must configure JNDI based JMS
security if using Oracle WebLogic 10.3.
Header Tab
Header Name The name of the message header. For example, APINAME.
Note: The header name must be unique. Two headers cannot
have the same header name.

Choose to add a new header name and value.

Choose to modify an existing header name and value.

Choose to delete an existing header name and value.

Chapter 24. Transport Nodes 583


Table 451. WebSphere Default Messaging JMS Queue Sender Configuration
Properties (continued)
Property Description
Header Value The value associated with the Header Name. These name-value
pairs are stored as message headers and can be queried by
using message selectors.

This can be set to a static value. For example, ‘createOrder'


results in the message having a header
APINAME='createOrder'

It can also be set to be dynamically extracted from the message


using the syntax xml://<full path of the element from
root>/@<attribute name>, which results in the message with a
header APINAME=’<value of attribute name in the XML>’.
Reconnect Tab

You need to use the settings in this tab for the backup JMS server.
Retry Interval In the event that the connection to the primary JMS server is
(milliseconds) lost, enter the amount of time between attempts to re-establish
contact with the primary JMS server. This parameter is used in
conjunction with the Number of Retries parameter. The default
value is 0 which means no delay time between retry attempts.
Number of Retries In the event that the connection to the primary JMS server is
lost, enter the number of attempts to re-establish contact with
the primary JMS server before failing over to the backup JMS
server, if enabled, or throwing an exception. This parameter is
used in conjunction with the Retry Interval parameter. The
default value is 0 which means there are no retries if the
connection is lost and either failover occurs, if enabled, or an
exception is thrown immediately.
Use backup JMS Queue Check this box if you want to enable a backup JMS queue.

Only upon selecting this checkbox, other controls in this tab are
enabled.
Provider URL Enter the backup JMS server provider URL of the JMS
implementation used. This is the URL to use for JNDI lookups.
v For IBM WebSphere Default Messaging JMS Queue, set to
corbaloc::<DNS Server Name or IP
Address>:<bootstrapport>
Initial Context Factory The class name of the initial context factory. This is the starting
point for the resolution of names for naming and directory
operations.

Select WebSphere MQ if you are using IBM WebSphere Default


Messaging JMS Queue. This sets the class name to
v com.ibm.websphere.naming.
WsnInitialContextFactory.
Queue Name Enter the name of the backup queue to which the message is
sent.
QCF Lookup Enter the back JMS server's queue connection factory name.
This is used to retrieve the queue connection factory from
JNDI. A client uses a queue connection factory to create queue
connections with a JMS provider. Enter any unique identifier
for the QCF lookup. This name must be the same as that
configured in the IBM WebSphere administration console.

584 Sterling Selling and Fulfillment Foundation: Application Platform Configuration Guide
Table 451. WebSphere Default Messaging JMS Queue Sender Configuration
Properties (continued)
Property Description
Reconnect To Primary Check this box if you want to reconnect to the primary JMS
JMS Queue queue after a failover to the backup JMS queue server has
occurred. Once this checkbox is selected, enter the wait time
before it reconnects.
Time Before Reconnect Enter the maximum amount of time between attempts to
(seconds) re-establish contact with the primary JMS server after a failover
to the backup JMS server. If contact is re-established with the
primary JMS server, it reverts back to using the primary JMS
server. If contact with the primary JMS server cannot be
established, it continues to use the backup JMS server. The
default value is 600 seconds.
JMS Security Properties Tab

This is enabled upon selecting Enable JMS Security in the runtime tab.
Note: You can override the JMS security properties specified here by defining the agent
and flow authorization parameters in the <INSTALL_DIR>/properties/
customer_overrides.properties file. For additional information about overriding
properties using the customer_overrides.properties file, see the Sterling Selling and
Fulfillment Foundation: Properties Guide.
Queue based security Check this box, if you want to provide Queue based security
for JMS service.
Note: Oracle WebLogic 10.3 only supports JNDI based JMS
security. If queue based security is enabled, it is altogether
bypassed. Therefore, you must configure JNDI based JMS
security if using Oracle WebLogic 10.3.
JNDI based security Check this box, if you want to provide JNDI based security for
JMS service.
JMS Security Parameters

For more information about application server-specific JMS security parameters, see
"Setting up the JMS Security Properties" section.
Parameter Name Enter the name of the security parameter.
Parameter Value Enter the value of the security parameter.

Note: The JMS session objects can be pooled based on the service being executed.
Hence, whenever the JMS sender requires a session object, the Sterling Application
Platform framework tries to get a free session object from the pool. If there are no
free sessions available, a new session object is created to send the message and
then added to the pool. Any session object that is idle for a certain configurable
period of time is closed by the framework. The yfs.jms.session.reaptime
property in the yfs.properties file is used to set the JMS session reaptime. To
modify this property, add an entry for it in the <INSTALL_DIR>/properties/
customer_overrides.properties file. For additional information about overriding
properties using the customer_overrides.properties file, see the Sterling Selling
and Fulfillment Foundation: Properties Guide.

IBM WebSphere Default Messaging JMS Queue Receiver


The JMS receiver does not have a backup queue, therefore two different services
must be configured. One to listen on the primary queue and one to listen on the

Chapter 24. Transport Nodes 585


backup queue. When an exception occurs, the receiver retries using an exponential
back off mechanism with a configurable maximum wait limit between retries.

For example, if 600 seconds is the maximum wait time, it first waits for 1 second,
then 2 seconds, 4, 8, 16 and so on exponentially until it reaches 600 seconds, after
which it retries every 600 seconds. So there is no bound on the total wait time.

Since the JMS receivers operate independently of each other with respect to the
primary and backup queues, the order of messages across these queues is not
supported.

Configuration Properties

The following are the configuration properties of this node:


Table 452. WebSphere Default Messaging JMS Queue Receiver Configuration Properties
Property Description
Runtime Tab
Sub Service Name Enter the name of the queue to which the message is

sent.
Queue Name Enter the name of the queue to which the message is sent.
Provider URL Enter the JMS server provider URL of the JMS implementation
used. This is the URL to use for JNDI lookups.
v For IBM WebSphere Default Messaging JMS Queue, set to
corbaloc::<DNS Server Name or IP
Address>:<bootstrapport>
Initial Context Factory The class name of the initial context factory. This is the starting
point for the resolution of names for naming and directory
operations.

Select WebSphere MQ if you are using IBM WebSphere Default


Messaging JMS Queue. This sets the class name to

com.ibm.websphere.naming.
WsnInitialContextFactory.
QCF Lookup Enter the back JMS server's queue connection factory name.
This is used to retrieve the queue connection factory from
JNDI. A client uses a queue connection factory to create queue
connections with a JMS provider. Enter any unique identifier
for the QCF lookup. This name must be the same as that
configured in the IBM WebSphere administration console.

586 Sterling Selling and Fulfillment Foundation: Application Platform Configuration Guide
Table 452. WebSphere Default Messaging JMS Queue Receiver Configuration
Properties (continued)
Property Description
Receiving Mode Indicates whether the messages are received in a transactional
mode or non-transactional mode.
v If you set this to non-transactional mode, the messages are
removed from the queue as soon as it is read.
v If you set this to transactional mode, the messages are
removed from the queue when they are functionally
processed and if an exception is thrown when processing it.
Note: If the IsReprocessible flag is checked and an exception
occurs when processing the message, then before deleting these
messages, ensure that they are added to the
YFS_REPROCESS_ERROR or YFS_INBOX table. However, if
the "service suspend" exception occurs when adding these
deleted messages to a table, the messages are maintained in the
queue.
Initial Threads Enter the number of threads that can process messages
simultaneously. Based on your throughput, you can increase
the number of threads to enhance performance using the
System Management Console. For more information about
using the System Management Console, see the Sterling Selling
and Fulfillment Foundation: System Management and
Administration GuidePlatform System Management and
Administration Guide.

You can also start multiple instances of the Service Definition


Framework for a specific integration adapter for a specific
server. For more information about the integration adapter, see
the Sterling Selling and Fulfillment Foundation: Performance
Management Guide.
Selector Enter selectors based on the message headers. These selectors
must be in the form Header Name='Header Value'. When
specifying a selector, use only single quotes. For example, using
the selector APINAME='createOrder' selects all messages with a
header name='APINAME' and value='createOrder'.
Service to Execute on Required if the message contains an EOF message ID.
EOF Message
Choose to select the service to be invoked when an EOF
message is received. Once the EOF message is received, the
framework waits for a few minutes (configurable in the
<INSTALL_DIR>/properties/customer_overrides.properties
file) before executing this service. For more information see,
“Enabling EOF Messages in the Application Platform
Framework” on page 559. For additional information about
overriding properties using the customer_overrides.properties
file, see the Sterling Selling and Fulfillment Foundation: Properties
Guide.
Root Node Name of EOF If the message contains an EOF message ID, enter your custom
Message root node name for the EOF message.

By default the end of file message has a root node of "EOF". For
more information see, “Enabling EOF Messages in the
Application Platform Framework” on page 559.

Chapter 24. Transport Nodes 587


Table 452. WebSphere Default Messaging JMS Queue Receiver Configuration
Properties (continued)
Property Description
Enable JMS Security Check this box if you want JMS Security to be enabled. Once
selected, the JMS Security Properties tab is enabled to configure
Queue and/or JNDI based JMS security.
Note: Oracle WebLogic 10.3 only supports JNDI based JMS
security. If queue based security is enabled, it is altogether
bypassed. Therefore, you must configure JNDI based JMS
security if using Oracle WebLogic 10.3.
Server Tab
Server Name Select the name of the server which actually executes the
service.

For more information about creating a new server, see "Adding


a New Server".
Needs Decompression Select this field to indicate that the incoming message is
compressed and needs to be decompressed.
Exception Tabs See Table 462 on page 602 for the receiver link exception
handling properties.
Reconnect Tab
Maximum Time Between Enter the maximum time between reconnection attempts.
Retries (milliseconds)
JMS Security Properties Tab

This is enabled upon selecting Enable JMS Security in the runtime tab.
Note: You can override the JMS security properties specified here by defining the agent
and flow authorization parameters in the <INSTALL_DIR>/properties/
customer_overrides.properties file. For additional information about overriding properties
using the customer_overrides.properties file, see the Sterling Selling and Fulfillment
Foundation: Properties Guide.
Queue based security Check this box, if you want to provide Queue based security
for JMS service.
Note: Oracle WebLogic 10.3 only supports JNDI based JMS
security. If queue based security is enabled, it is altogether
bypassed. Therefore, you must configure JNDI based JMS
security if using Oracle WebLogic 10.3.
JNDI based security Check this box, if you want to provide JNDI based security for
JMS service.
JMS Security Parameters

For more information about application server-specific JMS security parameters, see
"Setting up the JMS Security Properties" section.
Parameter Name Enter the name of the security parameter.
Parameter Value Enter the value of the security parameter.

588 Sterling Selling and Fulfillment Foundation: Application Platform Configuration Guide
Connection Properties

The following are the WLJMS and MQJMS nodes' connection properties:
Table 453. WebSphere Default Messaging JMS Queue Connection Properties
Connection Node Connection Rules
Can be the first node after Yes, for services invoked both in a synchronous or
the start node asynchronous mode
Can be placed before v Any component node
v Any transport node (except for FTP or File I/O); use a
Pass-through node to connect them
Can be placed after v Start node
v Any synchronous transport node
v Any other component node
v Any asynchronous transport node (except for FTP or File
I/O); use a Pass-through node to connect them
Passes data unchanged Transport nodes do not modify data

JBoss Default Messaging JMS Queue


This component provides a common interface to invoke messaging services on the
JBoss Default Messaging JMS queues. You can specify the configuration properties
by using the Generic JMS component node.

JBoss Default Messaging JMS Queue Sender


The JMS sender caches a single connection starting with the primary queue. If the
message is not sent, the JMS sender retries to send the message a configurable
number of times with a configurable delay between each attempt as defined for the
Reconnect property in the following table. An exception is thrown if the configured
number of retries are exhausted and there is no backup queue.

If a backup queue is set up, a connection is made to the backup queue. The
backup queue becomes the current queue for the next attempt to send a message.
The sender can be configured to reconnect to the primary queue. If the primary
queue is working, a switch is made so that the primary queue becomes the current
queue.

Configuration Properties

The following are the configuration properties of these nodes:


Table 454. JBoss Default Messaging JMS Queue Sender Configuration Properties
Property Description
Runtime Tab

Use the settings in this tab for the primary JMS queue server.
Queue Name Enter the name of the queue to which the message is sent.

Chapter 24. Transport Nodes 589


Table 454. JBoss Default Messaging JMS Queue Sender Configuration
Properties (continued)
Property Description
Time To Live Enter the time period after which you want the messages to be
deleted from the queue.
(seconds)
v If you enter a zero value, the messages are not deleted from
the queue.
v If you enter a non-zero value, the messages that are not
consumed for the specified time interval are automatically
deleted from the queue by the provider.
Note: If you do not enter any value, the system considers a
zero value.
Provider URL Enter the provider URL of the JMS implementation to use for
JNDI lookups.

For the JBoss Default Messaging JMS Queue, enter the URL as:
jnp::<DNS Server Name or IP Address>:<bootstrapport>
Initial Context Factory The class name of the initial context factory. This is the starting
point for the resolution of names for naming and directory
operations.

Select Jboss if you are using the JBoss Default Messaging JMS
Queue. This sets the class name to
org.jnp.interfaces.NamingContextFactory
QCF Lookup Enter the queue connection factory name. This is used to
retrieve the queue connection factory from JNDI. A client uses a
queue connection factory to create queue connections with a
JMS provider. Enter any unique identifier for the QCF lookup.
This name must be the same as the one configured in the JBoss
administration console.
Delivery Mode This is not used for JBoss Messaging. Persistence is set for each
queue. Do not allow the application to override the persistence.
Needs compression Optional. Check this box if the message needs to be
compressed before dropping it into the queue.
Commit of this message Check this box if you want the message to be committed to the
depends on parent queue only after the service is completed.
transaction
Uncheck this box if you want the message to be committed to
the queue immediately.

For example, if the ON_SUCCESS event of any standard


Sterling Selling and Fulfillment FoundationApplication API is
attached to a service in which the message is transactionally
written to the queue, the message is committed to the queue
only upon successful completion of the ON_SUCCESS event.
The message is later rolled back from the queue if an error is
encountered in the ON_SUCCESS event after the message is
staged. However, in the non-transactional mode, the message
remains in the queue once it is staged and not rolled back.
Note: If you check this box, the system synchronizes the JMS
commit along with the DB commit. However, it is not a
two-phase commit. Therefore, it may cause some errors, thus
resulting in duplicate messages.
Enable JMS Security Check this box if you want to enable the JMS Security. If you
check this box, the JMS Security Properties tab is enabled for
you to configure Queue and/or JNDI based JMS security.

590 Sterling Selling and Fulfillment Foundation: Application Platform Configuration Guide
Table 454. JBoss Default Messaging JMS Queue Sender Configuration
Properties (continued)
Property Description
Header Tab
Header Name The name of the message header. For example, APINAME.
Note: The header name must be unique. Two headers cannot
have the same header name.

Choose to add a new header name and value.

Choose to modify an existing header name and value.

Choose to delete an existing header name and value.


Header Value The value associated with the Header Name. These name-value
pairs are stored as message headers and can be queried by
using message selectors.

This can be set to a static value. For example, ‘createOrder'


results in the message having a header
APINAME='createOrder'.

This can also be set to be dynamically extracted from the


message using the syntax, xml://<full path of the element from
root>/@<attribute name>, which results in the message with a
header APINAME='<value of attribute name in the XML>'.
Reconnect Tab

Use the settings in this tab for the backup JMS queue server.
Retry Interval In the event that the connection to the primary JMS queue
(milliseconds) server is lost, enter the time required to reestablish contact with
the primary JMS queue server. This parameter is used in
conjunction with the Number of Retries parameter. The default
value is 0 (zero), which means no time delay between retry
attempts.
Number of Retries In the event that the connection to the primary JMS queue
server is lost, enter the number of attempts to reestablish
contact with the primary JMS queue server before failing over
to the backup JMS queue server, if enabled, or an exception is
thrown. This parameter is used in conjunction with the Retry
Interval parameter. The default value is 0 (zero), which means
there are no retries if the connection is lost and failover occurs,
if enabled, or an exception is thrown.
Use backup JMS Queue Check this box if you want to enable a backup JMS queue.

When you check this box, other controls in this tab are enabled.
Provider URL Enter the backup JMS queue server provider URL of the JMS
implementation used. This is the URL to use for JNDI lookups.

For the JBoss Default Messaging JMS Queue, enter the URL as:
jnp::<DNS Server Name or IP Address>:<bootstrapport>

Chapter 24. Transport Nodes 591


Table 454. JBoss Default Messaging JMS Queue Sender Configuration
Properties (continued)
Property Description
Initial Context Factory The class name of the initial context factory. This is the starting
point for the resolution of names for naming and directory
operations.

Select Jboss if you are using the JBoss Default Messaging JMS
Queue. This sets the class name to
org.jnp.interfaces.NamingContextFactory
Queue Name Enter the name of the backup queue to which the message is
sent.
QCF Lookup Enter the backup queue of the JMS server connection factory
name. This is used to retrieve the queue connection factory
from JNDI. A client uses a queue connection factory to create
queue connections with a JMS provider. Enter any unique
identifier for the QCF lookup. This name must be the same as
the one configured in the JBoss administration console.
Reconnect To Primary Check this box if you want to reconnect to the primary JMS
JMS Queue queue after a failover to the backup JMS queue has occurred.
Once this box is selected, enter the wait time before it
reconnects.
Time Before Reconnect Enter the maximum time required to reestablish contact with
(seconds) the primary JMS queue server after a failover to the backup
JMS queue server. If a contact is reestablished, the primary JMS
queue server is used. Otherwise, the backup JMS queue server
is used. The default value is 600 seconds.
JMS Security Properties Tab

This tab is enabled when you select Enable JMS Security option in the runtime tab.
Note: You can override the JMS security properties specified here by defining the agent
and flow authorization parameters in the <INSTALL_DIR>/properties/
customer_overrides.properties file. For additional information about overriding
properties using the customer_overrides.properties file, see the Sterling Selling and
Fulfillment Foundation: Properties Guide.
Queue based security Check this box, if you want to provide Queue based security
for JMS service.
JNDI based security Check this box, if you want to provide JNDI based security for
JMS service.
Note: This checkbox is not applicable for JBoss as it does not
support JNDI based JMS security.
JMS Security Parameters

For more information about application server-specific JMS security parameters, see
"Setting up the JMS Security Properties" section.
Parameter Name Enter the name of the security parameter.
Parameter Value Enter the value of the security parameter.

Note: The JMS session objects can be pooled based on the service being executed.
Hence, whenever the JMS sender requires a session object, the Sterling Application
Platform framework tries to get a free session object from the pool. If there are no
free sessions available, a new session object is created to send the message and
then added to the pool. Any session object that is idle for a certain configurable
period of time is closed by the framework. The yfs.jms.session.reaptime

592 Sterling Selling and Fulfillment Foundation: Application Platform Configuration Guide
property in the yfs.properties file is used to set the JMS session reaptime. To
modify this property, add an entry for it in the <INSTALL_DIR>/properties/
customer_overrides.properties file. For additional information about overriding
properties using the customer_overrides.properties file, see the Sterling Selling
and Fulfillment Foundation: Properties Guide.

JBoss Default Messaging JMS Queue Receiver


The JMS receiver does not have a backup queue. Therefore, you must configure
two different services; one to listen on the primary queue and the other to listen on
the backup queue. When an exception occurs, the receiver retries to use an
exponential back off mechanism with a configurable maximum wait limit between
retries.

For example, if 600 seconds is the maximum wait time, the receiver first waits for 1
second, then 2 seconds, 4, 8, 16, and so forth until it reaches 600 seconds, after
which, the receiver retries every 600 seconds. Therefore, there is no boundary on
the total wait time.

As JMS receivers operate independently of each other with respect to the primary
and backup queues, the order of messages across these queues is not supported.

Configuration Properties

The following are the configuration properties of this node:


Table 455. JBoss Default Messaging JMS Queue Receiver Configuration Properties
Property Description
Runtime Tab
Sub Service Name Enter the name of the queue to which the message is sent.
Queue Name Enter the name of the queue to which the message is sent.
Provider URL Enter the JMS queue server provider URL of the JMS
implementation to use for JNDI lookups.

For the JBoss Default Messaging JMS Queue, enter the URL as:
jnp::<DNS Server Name or IP Address>:<bootstrapport>
Initial Context Factory The class name of the initial context factory. This is the starting
point for the resolution of names for naming and directory
operations.

Select Jboss, if you are using JBoss Default Messaging JMS


Queue. This sets the class name to

org.jnp.interfaces.NamingContextFactory
QCF Lookup Enter the backup queue of the JMS queue server connection
factory name. This is used to retrieve the queue connection
factory from JNDI. A client uses a queue connection factory to
create queue connections with a JMS provider. Enter any
unique identifier for the QCF lookup. This name must be the
same as the one configured in the JBoss administration console.

Chapter 24. Transport Nodes 593


Table 455. JBoss Default Messaging JMS Queue Receiver Configuration
Properties (continued)
Property Description
Receiving Mode Indicates whether the messages are received in transactional
mode or non-transactional mode.
v If you set this to non-transactional mode, the messages are
removed from the queue as soon as they are read.
v If you set this to transactional mode, the messages are
removed from the queue when they are functionally
processed or if an exception is thrown when processing it.
Note: If the IsReprocessible flag is checked and an exception
occurs when processing the message, before deleting the
message, ensure that it is added to the
YFS_REPROCESS_ERROR or YFS_INBOX table. However, if
the "service suspend" exception occurs when adding deleted
messages to a table, the messages are maintained in the queue.
Initial Threads Enter the number of threads that can process messages
simultaneously. Based on your throughput, you can increase
the number of threads to enhance performance using the
System Management Console. For more information about
using the System Management Console, see the Sterling Selling
and Fulfillment Foundation: System Management and
Administration GuidePlatform System Management and
Administration Guide.

You can also start multiple instances of the Service Definition


Framework for a specific integration adapter and a server. For
more information about the integration adapter, see the Sterling
Selling and Fulfillment Foundation: Performance Management Guide.
Selector Enter selectors based on the message headers. These selectors
must be in the form Header Name='Header Value'. When
specifying a selector, use only single quotes. For example, using
the selector APINAME='createOrder' selects all messages with
the header name='APINAME' and the value='createOrder'.
Service to Execute on Required if the message contains an EOF message ID.
EOF Message
Click to select the service to invoke when an EOF message
is received. Once the EOF message is received, the framework
waits for a few minutes (configurable in the
<INSTALL_DIR>/properties/customer_overrides.properties
file) before executing this service. For more information about
EOF messages, see “Enabling EOF Messages in the Application
Platform Framework” on page 559. For additional information
about overriding properties using the
customer_overrides.properties file, see the Sterling Selling and
Fulfillment Foundation: Properties Guide.
Root Node Name of EOF If the message contains an EOF message ID, enter your custom
Message root node name for the EOF message.

By default the EOF message has a root node of "EOF". For more
information about EOF messages, see “Enabling EOF Messages
in the Application Platform Framework” on page 559.
Enable JMS Security Check this box if you want to enable JMS Security. When this
box is selected, the JMS Security Properties tab is enabled for
you to configure Queue and/or JNDI based JMS security.
Server Tab

594 Sterling Selling and Fulfillment Foundation: Application Platform Configuration Guide
Table 455. JBoss Default Messaging JMS Queue Receiver Configuration
Properties (continued)
Property Description
Server Name Select the name of the server that executes the service.

For more information about creating a new server, see "Adding


a New Server".
Needs Decompression Check this box to indicate that the incoming message is
compressed and needs to be decompressed.
Exception Tabs See Table 462 on page 602 for the receiver link exception
handling properties.
Reconnect Tab
Maximum Time Between Enter the maximum time required between reconnection
Retries (milliseconds) attempts.
JMS Security Properties Tab

This tab is enabled only when you check the Enable JMS Security box provided in the
runtime tab.

Note: You can override the JMS security properties specified here by defining the agent
and flow authorization parameters in the <INSTALL_DIR>/properties/
customer_overrides.properties file. For additional information about overriding properties
using the customer_overrides.properties file, see the Sterling Selling and Fulfillment
Foundation: Properties Guide.
Queue based security Check this box, if you want to provide Queue based security
for JMS service.
JNDI based security Check this box, if you want to provide JNDI based security for
JMS service.
Note: This checkbox is not applicable for JBoss as it does not
support JNDI based JMS security.
JMS Security Parameters

For more information about application server-specific JMS security parameters, see
"Setting up the JMS Security Properties" section.
Parameter Name Enter the name of the security parameter.
Parameter Value Enter the value of the security parameter.

Connection Properties

The following are the Generic JMS queue node connection properties:
Table 456. JBoss Default Messaging JMS Queue Connection Properties
Connection Node Connection Rules
Can be the first node after Yes, for services invoked both in a synchronous or
the start node asynchronous mode.
Can be placed before v Any component node
v Any transport node (except for FTP or File I/O). Use a
pass-through node to connect them.

Chapter 24. Transport Nodes 595


Table 456. JBoss Default Messaging JMS Queue Connection Properties (continued)
Connection Node Connection Rules
Can be placed after v Start node
v Any synchronous transport node
v Any other component node
v Any asynchronous transport node (except for FTP or File
I/O). Use a pass-through node to connect them.
Passes data unchanged Transport nodes do not modify data.

Synchronous IBM WebSphere Default Messaging


The synchronous IBM WebSphere Default Messaging transport nodes allow request
and response operations using JMS queues. If the response is not received within a
defined period, an exception is thrown.

Identification of appropriate response messages is done with a header field named


MESSAGEID. When the request message is put into the queue, the MESSAGEID
header is set to a unique value based on the current time and a counter. The
response headers must have this same message ID in order for it to be picked up
and processed correctly.

Configuration Properties

The following are the properties of this node:


Table 457. Synchronous WAS Default Messaging Properties
Property Description
Runtime Tab
Provider URL Enter the provider URL of the JMS implementation used. URL
to use for JNDI lookups using the IBM WebSphere Default
Messaging JMS queue:
corbaloc::<DNS Server Name or IP Address>:<bootstrapport>
Initial Context Factory The class name of the initial context factory. This is the starting
point for the resolution of names for naming and directory
operations.

Select synchronous WebSphere MQ if you are using MQSeries


accessed through a IBM WebSphere corbaloc URL. This sets the
class name to IBM corbaloc::<DNS Server Name or IP
Address>:<bootstrapport>
QCF Lookup Enter the queue connection factory name. This is used to
retrieve the queue connection factory from JNDI. A client uses a
queue connection factory to create queue connections with a
JMS provider. Enter unique identifier for the QCF lookup. This
name must be the same as that configured in the WAS
administration console.
Needs Compression Select this option if the message needs to be compressed.

596 Sterling Selling and Fulfillment Foundation: Application Platform Configuration Guide
Table 457. Synchronous WAS Default Messaging Properties (continued)
Property Description
Enable JMS Security Check this box if you want JMS Security to be enabled. Once
checked, the JMS Security Properties tab is enabled to configure
Queue and/or JNDI based JMS security.
Note: Oracle WebLogic 10.3 only supports JNDI based JMS
security. If queue based security is enabled, it is altogether
bypassed. Therefore, you must configure JNDI based JMS
security if using Oracle WebLogic 10.3.
Request Tab
Queue Name Enter the name of the queue to which the request message is
sent.
Header Name The name of the message header. For example, APINAME.
Note: The header name must be unique. Two headers cannot
have the same header name.

Choose to add a new header name and value.

Choose to modify an existing header name and value.

Choose to delete an existing header name and value.


Header Value The value associated with the Header Name. These name-value
pairs are stored as message headers and can be queried by
using message selectors.

This can be set to a static value. For example, ‘createOrder'


results in the message having a header
APINAME=createOrder'.

It can also be set to be dynamically extracted from the message


using the syntax, xml://<full path of the element from
root>/@<attribute name>, which results in the message with a
header APINAME='<value of attribute name in the XML>'.
Response Tab
Queue Name Enter the name of the queue in which the response message is
received.
Selector Enter the selectors based on the message headers. When
specifying a selector, use only single quotation marks. For
example, specifying the selector APINAME='createOrder'
selects all messages with a header name='APINAME' and
value='createOrder'.
Time Out (seconds) This is a mandatory parameter. Enter the time interval (in
seconds) after which the request times out.
Reconnect Tab
Retry Interval In the event that the connection to the JMS server is been lost,
(milliseconds) enter the amount of time between each attempt to re-establish
contact with the JMS server. This parameter is used in
conjunction with the Number of Retries parameter. The default
value is zero, implying no delay time between retry attempts.

Chapter 24. Transport Nodes 597


Table 457. Synchronous WAS Default Messaging Properties (continued)
Property Description
Number of Retries In the event that the connection to the JMS server is been lost,
enter the number of attempts to re-establish contact with the
JMS server before throwing an exception. This parameter is
used in conjunction with the Retry Interval parameter. The
default value is zero, implying no retries if the connection is
lost and an exception is thrown immediately.
JMS Security Properties Tab

This is enabled when you select Enable JMS Security in the Runtime Tab.
Note: Oracle WebLogic 10.3 only supports JNDI based JMS security. If queue based
security is enabled, it is altogether bypassed. Therefore, you must configure JNDI based
JMS security if using Oracle WebLogic 10.3.
Note: You can override the JMS security properties specified here by defining the agent
and flow authorization parameters in the <INSTALL_DIR>/properties/
customer_overrides.properties file. For additional information about overriding
properties using the customer_overrides.properties file, see the Sterling Selling and
Fulfillment Foundation: Properties Guide.
Queue based security Check this box, if you want to provide Queue based security
for JMS service.
JNDI based security Check this box, if you want to provide JNDI based security for
JMS service.
JMS Security Parameters.

For more information about application server-specific JMS security parameters, see
"Setting up the JMS Security Properties".
Parameter Name Enter the name of the security parameter.
Parameter Value Enter the value of the security parameter.

Note: The JMS session objects can be pooled based on the service being executed.
Hence, whenever the JMS sender requires a session object, the Sterling Application
Platform framework tries to get a free session object from the pool. If there are no
free sessions available, a new session object is created to send the message and
then added to the pool. Any session object that is idle for a certain configurable
period of time is closed by the framework. The yfs.jms.session.reaptime
property in the yfs.properties file is used to set the JMS session reaptime. To
modify this property, add an entry for it in the <INSTALL_DIR>/properties/
customer_overrides.properties file. For additional information about overriding
properties using the customer_overrides.properties file, see the Sterling Selling
and Fulfillment Foundation: Properties Guide.

Note:

Connection Properties

The following are the synchronous MQSeries nodes' connection properties:


Table 458. Synchronous WAS Default Messaging Properties
Connection Node Connection Rules
Can be the first node after Only for services invoked synchronously
the start node

598 Sterling Selling and Fulfillment Foundation: Application Platform Configuration Guide
Table 458. Synchronous WAS Default Messaging Properties (continued)
Connection Node Connection Rules
Can be placed before v Any transport node except for FTP or File I/O
v Any other component node
Can be placed after v Start node
v Any synchronous transport node
v Any other component node
v Any asynchronous transport node (except for FTP or File
I/O); use Pass-through node to connect.
Passes data unchanged Transport nodes do not modify data.

Microsoft Message Queue (MSMQ)


The Microsoft Message Queue (MSMQ) transport node allows the Service
Definition Framework to read or write messages to an MSMQ queue. MSMQ has
the ability to use both local or remote queues. If a message is sent to a remote
queue that cannot be found, an error is not generated. Instead, MSMQ creates a
local queue of the same name. If the remote queue becomes available at a later
time, the messages in the local queue are then transferred to the remote queue.

Note: MSMQ must be installed on the same system the integration adapter is
running on.

MSMQ Sender
Configuration Properties

The following are the properties of this node:


Table 459. MSMQ Sender Configuration Properties
Property Description
Queue Name Enter the name of the queue to which the message is to be sent
using the following format:

<machineName>/private$/<QueueName>

Sterling Selling and Fulfillment FoundationApplication does


not support Queue Lookup through the Active Directory.
Time To Live Enter the time period after which the messages are to be
deleted from the queue. A value of 0 causes the message to
never be deleted from the queue.

If this is set to a non-zero value, messages in the queue which


are not consumed for the specified time interval are
automatically deleted from the queue by the provider.
Persistent/Non Persistent Select if the messages are to be Persistent or Non-Persistent
when dropped into the queue.

Chapter 24. Transport Nodes 599


Table 459. MSMQ Sender Configuration Properties (continued)
Property Description
Transactional/Non Select Transactional if you want the message to be committed
Transactional to the queue only after the service is completed.

Select Non Transactional if you want the message to be


committed to the queue immediately.

For example, if the ON_SUCCESS event of any standard


Sterling Selling and Fulfillment FoundationApplication API is
attached to a service, in which the message is transactionally
written to the queue, the message is committed to the queue
only upon successful completion of the ON_SUCCESS event.
The message is then rolled back from the queue if there is any
error in the ON_SUCCESS event after the message is staged.
However, in non-transactional mode, the message remains in
the queue, once it is staged and is not rolled back.
Note: If you plan to use transactional mode of messaging,
create the queue in MSMQ as transactional queue.
String Message Select this field if you want to set the PROPID_M_BODY_TYPE
to VT_BSTR

De-select this field if you want to set the


PROPID_M_BODY_TYPE to VT_EMPTY.

Note: The JMS session objects can be pooled based on the service being executed.
Hence, whenever the JMS sender requires a session object, the Sterling Application
Platform framework tries to get a free session object from the pool. If there are no
free sessions available, a new session object is created to send the message and
then added to the pool. Any session object that is idle for a certain configurable
period of time is closed by the framework. The yfs.jms.session.reaptime
property in the yfs.properties file is used to set the JMS session reaptime. To
modify this property, add an entry for it in the <INSTALL_DIR>/properties/
customer_overrides.properties file. For additional information about overriding
properties using the customer_overrides.properties file, see the Sterling Selling
and Fulfillment Foundation: Properties Guide.

MSMQ Receiver
Configuration Properties

The following are the properties of this node:


Table 460. MSMQ Receiver Properties
Property Description
Runtime Tab
Runtime ID Enter a unique identifier for each asynchronous receiver within
a service definition.
Queue Name Enter the name of the queue to which the message is to be sent
using the following format:

<machineName>/private$/<QueueName>

Sterling Selling and Fulfillment FoundationApplication does


not support Queue Lookup through the Active Directory.
Max Threads The maximum number of threads for this process.

600 Sterling Selling and Fulfillment Foundation: Application Platform Configuration Guide
Table 460. MSMQ Receiver Properties (continued)
Property Description
Transactional/Non Select if the messages are to be received in a Transactional or
Transactional Non Transactional Mode.
Note: If you plan to use transactional mode of messaging,
create the queue in MSMQ as a transactional queue.
Server Tab
Server Name Select the name of the server which actually executes the
service.

For more information about creating a new server, see "Adding


a New Server".
Exception Tabs See Table 462 on page 602 for the receiver link exception
handling properties.

Connection Properties

The following are the MSMQ node's connection properties:


Table 461. MSMQ Connection Properties
Connection Node Connection Rules
Can be the first node after Yes, for services invoked both in a synchronous or
the start node asynchronous mode
Can be placed before v Any component node
v Any transport node (except for FTP or File I/O); use a
Pass-through node to connect them
Can be placed after v Start node
v Any synchronous transport node
v Any other component node
v Any asynchronous transport node (except for FTP or File
I/O); use a Pass-through node to connect them
Passes data unchanged Transport nodes do not modify data

Note: Make sure the <INSTALL_DIR>/bin directory and the directory containing
the jvm.dll are in your system PATH.

Receiver Link Exception Handling


For each asynchronous receiver node, enter exception parameters. Exception
handling can be configured for the following nodes:
v Database Receiver
v DCS 6.2 Database Receiver
v File I/O Receiver
v FTP Receiver
v Oracle WebLogic, MQSeries, and TIBCO JMS Receiver
v MSMQ Receiver

Chapter 24. Transport Nodes 601


Configuration Properties

The following are the exception properties of the asynchronous receiver nodes:
Table 462. Receiver Link Exception Handling Properties
Property Description
Alert Type Enter the type of Alert being raised when an exception occurs.
For example, you can enter the text OrderCreate.

This displays in the Alert console and can be used to filter


particular type of alerts.
Alert Queue Name Select the name of the alert queue to which the exceptions are
sent.
Suspend API Select this field if a suspendable exception is returned by an
extended API, the message is retained in the queue and the
execution restarts after the Suspend Wait Time interval.

For details regarding the exception to be thrown, see the


YIFRestartableAPI interface in the Sterling Selling and Fulfillment
Foundation: JavadocsJavadocs.
Suspend Wait Time Enter the time to wait before attempting to reprocess the
message.
Is Reprocessible Select this field if the message received from an asynchronous
source (like a message queue or database) and the error XML
must be saved in the exception console when an exception
occurs.

Messages marked as Reprocessible can be corrected in the


Exception Console and submitted for reprocessing. For more
information about the Exception Console, see the Sterling Selling
and Fulfillment Foundation: Application Platform User Guide
Note: There will only be one reprocess-timer thread per
integration server. The reprocess-timer thread will run with a
sleep delay of ONE minute and will process 50 reprocessible
records at a time.
Check for Prior Exception Select this filed to check for prior exceptions before the
execution of the service. Choosing this option implies that prior
to executing the service, a check is made to see if any related
errors exist for the message. This check must be implemented
externally through the YIFErrorSequenceUE user exit.
Note: This option is applicable only when all the related
services are associated to the same server.
Exception Group Enter a group of related services where exceptions are linked.
For example, two services for receiving modifications on an
order from external systems.
Note: This option is applicable only when all the related
services are associated to the same server.
Prior Errors User Exit Enter the class name that implements YIFErrorSequenceUE user
exit for checking prior related errors for the message.
Exception References Tab
Exception Reference Enter the name of the exception reference. Saved in the
Name ERROR_REFERENCE column of the YFS_REPROCESS_ERROR
table to indicate as Name=Value. For example, NAME1.

602 Sterling Selling and Fulfillment Foundation: Application Platform Configuration Guide
Table 462. Receiver Link Exception Handling Properties (continued)
Property Description
Exception Reference Enter the associated Exception Reference value. These name
Value value/pairs are stored in the ERROR_REFERENCE field in the
YFS_REPROCES_ERROR table for querying purposes.

Can be set to be static. For example, entering ‘1234' results in


the ERROR_REFERENCE field to be populated with
NAME1=1234.

Can also be set for dynamically extraction from the message


using the following syntax xml://<full path of the element
from root>/@<attribute name>.

For example, to get the sales order number from the


createOrder input XML, use xml://Order/@OrderNo. This
results in the ERROR_REFERENCE field to be populated with
NAME1=<value of attribute OrderNo in the XML>.

Component Nodes
Component nodes determine how data should be transformed from one format to
another. Define their configuration properties by clicking the node and editing the
properties.

Alert
This component allows Alerts to be registered in the Alert console. This is same as
invoking alerts from an Action in releases prior to 5.0. You can also consolidate the
alerts by grouping the attributes in the YFS_INBOX table.

Configuration Properties

The following are the properties of this node:


Table 463. Alert Configuration Properties
Property Description
General Tab
Alert Queue Name Select the name of the queue alerts should be sent to.
User ID Select the user ID to which the alert is assigned.
Alert Type Enter the type of the alert. The type that is assigned here
displays as the Alert Type in the Alert Console and can be
used to filter alerts. The type entered is user defined.
Priority Enter the priority of the exception raised.
Description Enter a brief description of the alert raised.

Chapter 24. Transport Nodes 603


Table 463. Alert Configuration Properties (continued)
Property Description
Template Name Enter the XSL Template Name.

The output of the XSL and the incoming XML document


merge displays in the description field on the Alert
Console. For example, to display OrderNo, the sample
XSL is <INSTALL_DIR>/repository/xapi/template/merged/
exception_console/sample_exception_console.xsl

When the type of incoming XML is TYPE_JAVA_MAP, to


display the OrderNo, the sample XSL is
<INSTALL_DIR>/repository/xapi/template/merged/
exception_console/
sample_keymap_exception_console.xsl.

This XSL is called by the raiseEvent API. For more


information about the incoming XML data types, see the
Sterling Selling and Fulfillment Foundation: JavadocsJavadocs.
List Template Enter the XSL list template. The output of the XSL and the
incoming XML document merge displays on the Alert List
and Home Page.
Resolve By (Hrs) Enter the number of hours the alert should be resolved
by. The hours can be specified in decimals also, for
example 5.5 or 20.
Expiration Days Specify the number of expiration days for the alert after
which this exception may be automatically closed. A value
of zero means the exception does not expire.
System Arguments Tab
Argument Name Predefined elements available to a particular process
repository. The following attributes are optional and can
be specified as static or dynamic values.
xml:/<ElementName>/@<AttributeName>
Argument Value Static or dynamic values that are specified in the
following format:
xml:/<ElementName>/@<AttributeName>
User Arguments Tab
Reference Name Enter additional name/value data that can be used to add
information to the alert.
Reference Value Enter the reference value. This is a static or dynamic
values that are specified in the following format:
xml:/<ElementName>/@<AttributeName>
Reference Type Enter the reference type. Valid values are: TEXT, URL
Consolidation Tab
Consolidation Required Check this box if you wish to consolidate the alerts. A
consolidation count is kept to increment similar alerts that
follow the same template attributes.

If it is not selected, then the count always remains 1.

604 Sterling Selling and Fulfillment Foundation: Application Platform Configuration Guide
Table 463. Alert Configuration Properties (continued)
Property Description
Consolidation Template Select either Default or Custom for consolidating the
alerts. The default chosen option is Default.

If Custom is chosen, then the attributes for the


consolidation template appear below. These attributes are
from the YFS_INBOX table and the corresponding XML file
can be found in <INSTALL_DIR>/repository/xapi/
template/merged/resource/exceptionConsolidation.xml.
You can select any of the attributes by right clicking the
attribute and including it for consolidation.

If you have extended the columns in YFS_INBOX table, then


those attributes appear under the Extn element.
Consolidate Dates By Specify whether the consolidation is done daily or hourly.
By default the option is set to Day.

Choosing this option is useful only if you include any


time attributes such as Date in the consolidation template.
Routing Tab
Routing Required Check this box, if you want to route the alert based on the
routing rules. For more information about defining
routing rules, see Section 16.3.3 "Creating an Exception
Routing Rule".
Routing Organization Enter the XML path of the organization that owns the
alert routing rules.

By default, this field is disabled.


Attribute Name Displays the predefined routing attributes applicable for
an alert. You can specify the following predefined routing
attributes:
v BUYER
v SELLER
v ENTERPRISE
v NODE
v DEPARTMENT CODE
Note: You can also enter your own custom routing
attributes.
Attribute XPath Enter the XML path of the routing attribute.

Connection Properties

The following are the alert node's connection properties:


Table 464. Alert Connection Properties
Connection Node Connection Rules
Can be the first node after Only for services invoked synchronously
the start node
Can be placed before v Any transport node except for FTP or File I/O
v Any other component node

Chapter 24. Transport Nodes 605


Table 464. Alert Connection Properties (continued)
Connection Node Connection Rules
Can be placed after v Start node
v Any transport node except for FTP or File I/O
v Any other component node
Passes data unchanged Yes

Application Programming Interface (API)


The API component is used to invoke the Sterling Selling and Fulfillment
FoundationApplication System APIs or any user-written Java class.

To configure extended database APIs for custom and hang-off entities, refer to the
Sterling Selling and Fulfillment Foundation: Extending the Database.

Configuration Properties

The following are the properties of this node:


Table 465. API Configuration Properties
Property Description
General Tab
Standard Sterling Selling and Select this option if a standard Sterling Selling and
Fulfillment Fulfillment FoundationApplication API is to be invoked. If
FoundationApplication API selected, a Standard Sterling Selling and Fulfillment
FoundationApplication API Name drop down list
displays. For each API, the Class Name and Method
Name are provided and cannot be edited.
Extended API Select this option if a custom java code is to be invoked.
Extended Database API Select this option if the service invokes a custom or
hang-off API. If selected, a custom API Name drop-down
list displays. For each API, the Class Name and Method
Name are provided and cannot be edited.
Note: If you want to lock a record in a custom table, pass
the SelectMethod attribute as part of the input XML to the
custom entity API. The SelectMethod attribute can take
the following values:

WAIT, NO_WAIT, and NONE.

For more information about locking records in Extended


APIs, refer to the Sterling Selling and Fulfillment Foundation:
Customizing APIs
API Name Select or enter the API to be called.
Note: You can use only document-based APIs. This field
is for integration purposes only.
Class Name Specifies the class to be called.
Method Name Specifies the method to be called.
Requires Backward Select this field to indicate that input data coming through
Compatibility the API is from a previous version (only applicable to
Sterling Selling and Fulfillment FoundationApplication
system APIs).

606 Sterling Selling and Fulfillment Foundation: Application Platform Configuration Guide
Table 465. API Configuration Properties (continued)
Property Description
Version If you chose Requires Backward Compatibility, select the
Sterling Selling and Fulfillment FoundationApplication
version the API is to behave as. Only the applicable
versions for the individual API display.
Arguments Tab
Argument Name You can pass name/value pairs to the API by entering the
values in the Arguments Tab.

In order for custom APIs to access custom values, the API


should implement the interface
com.yantra.interop.japi.YIFCustomApi.

If entered, these name/value pairs are passed to the


CustomApi as a Properties object.
Argument Value Enter the argument value.
Template Tab
When the Sterling Selling and Fulfillment
FoundationApplication System APIs are invoked, you can
specify an output template to be used by the API. You can
specify the template in the configuration properties of the
Service Definition, the Resource Definition in the Resource
Hierarchy tree, or both. However, if the template has been
specified at both definition levels, the template specified
in the Service Definition is used.
XML Template Select this radio button to construct the XML to be used
for the API output. Enter the template root element name
and click OK. You can then construct the XML.
File Name Select this radio button to enter the filename of the XML
file to be used as the API output template. This file
should also exist in your CLASSPATH.
Facts Tab
A Fact is an attribute that is used by an API or an agent
in Sterling Selling and Fulfillment FoundationBased on
the fact name and fact value entered, the corresponding
colony is determined.
Fact Name Enter the fact name of the XML attribute.
Fact Value Enter the fact value of the XML attribute.

Connection Properties

The following are the API node's connection properties:


Table 466. API Connection Properties
Connection Node Connection Rules
Can be the first node after Only for services invoked synchronously
the start node
Can be placed before v Any transport node except FTP or File I/O
v Any other component node

Chapter 24. Transport Nodes 607


Table 466. API Connection Properties (continued)
Connection Node Connection Rules
Can be placed after v Start node
v Any transport node except FTP or File I/O
v Any other component node
Passes data unchanged Yes

Composite Service
The Composite service node enables users to specify multiple services that need to
be executed as part of a single service. Only services that can be invoked
synchronously can be part of the Composite service.

Note: If a transaction fails after executing a service in a composite component


which drops the message into Oracle WebLogic JMS, MQ JMS, DB or FILE I/O.
The message in the asynchronous medium cannot be rolled back.

Note: Never configure a composite service to call its parent service if not it leads
to an infinite loop.
Table 467. Composite Service Configuration Properties
Property Description
Service Name Select services to be invoked by this service.

After you add a service, you can view and edit its properties. On the list of
services, double-click the name of the Composite service you want to view or edit.
It opens in a new window.

Connection Properties

The following are the Composite Service node’s connection properties:


Table 468. Composite Service Connection Properties
Connection Node Connection Rules
Can be the first node after Only for services invoked synchronously
the start node
Can be placed before v Any transport node except for FTP or File I/O
v Any other component node
Can be placed after v Start node
v Any transport node except for FTP or File I/O
v Any other component node
Passes data unchanged Yes

Condition
This node is invoked synchronously. Conditions allow you to build branching logic
within the service.

608 Sterling Selling and Fulfillment Foundation: Application Platform Configuration Guide
Note: Do not place a Condition node very close to other objects (nodes or
connectors), otherwise the outbound connector points may not become active.

Configuration Properties

The following are the properties of this node:


Table 469. Condition Configuration Properties
Property Description
Condition Name Select a condition from a list of pre-configured condition
names or you can create a new Condition.

Connection Properties

The Condition node requires two outgoing connections, one for true circumstances
and one to false. When you create the outgoing links, first link to the node that
processes the true condition and then link to the node that processes the false
condition.

The following are the Condition node’s connection properties:


Table 470. Condition Connection Properties
Connection Node Connection Rules
Can be the first node Only for services invoked synchronously

after the start node


Can be placed before v Any transport node except for FTP or File I/O
v Any other component node
Can be placed after v Start node
v Any transport node except for FTP or File I/O
v Any other component node
Passes data unchanged Yes

E-Mail
The E-Mail component type wraps the SMTP protocol. It can be invoked
synchronously or asynchronously. The configuration allows you to specify either
the addresses (From, To, and so forth) from the XML should be dynamically
retrieved or sent to a static address.

Note: If the e-mail being sent contains HTML content, the XSL that is transforming
the input XML to the HTML format should have a comment such as the following
example:

<xsl:comment>CONTENT_TYPE=text/
html</xsl:comment>, so the transformed HTML has a comment:
<!--CONTENT_TYPE=text/html-->

The framework uses this information to set the content_type to text/html, if this
comment is not present the content_type is set to text/plain.

Chapter 24. Transport Nodes 609


Configuration Properties

The following are the properties of this node:


Table 471. E-Mail Configuration Properties
Property Description
E-mail Server Enter the name or IP address of the mail server.
E-mail Server Listener Port Enter the port number of the mail server.
Subject Enter what you want to appear in the subject line of the
e-mail.

If you specify XML in the format of xml://


<ElementName>/@<AttributeName>, it is replaced
dynamically with the value from the input XML data. For
example, the text “Thank you for your online Order
xml://Order/@OrderNo” is a combination of static and
dynamic text that results as “Thank you for your online
Order MyOrder005”.
Body Template XSL file that contains formatting to apply to the body of
the message. Sterling Selling and Fulfillment
FoundationApplication supplies the <INSTALL_DIR>/
repository/xapi/template/merged/email/orders_mail.xsl
file.
From Can be static or dynamic with the XML path specified as
xml://<ElementName>/@<AttributeName>. Use
semi-colons as a delimiter between addresses.
To Required. Can be static or dynamic with the XML path
specified as xml://<ElementName>/@<AttributeName>.
Use semi-colons as a delimiter between addresses.
CC Can be static or dynamic with the XML path specified as
xml://<ElementName>/@<AttributeName>. Use
semi-colons as a delimiter between addresses.
BCC Can be static or dynamic with the XML path specified as
xml://<ElementName>/@<AttributeName>. Use
semi-colons as a delimiter between addresses.

Connection Properties

These are the connection properties of this node:


Table 472. E-Mail Connection Properties
Connection Node Connection Rules
Can be the first node after Only for services invoked synchronously
the start node
Can be placed before v Any transport node except for FTP or File I/O
v Any other component node
Can be placed after v Start node
v Any transport node except for FTP or File I/O
v Any other component node
Passes data unchanged Yes

610 Sterling Selling and Fulfillment Foundation: Application Platform Configuration Guide
Note: The SMTP connection objects can be pooled based on the service being
executed. Hence whenever the SMTP sender require a connection object the
Sterling Application Platform framework tries to get a free connection object from
the pool. If the connection objects in the pool are occupied or if the pool is empty,
then a new connection object is created to send the message and then added to the
pool. Any connection object idle for a certain configurable period of time and can
be closed by the framework. For information about setting the properties for
connection reaptime, check the yfs.properties file in <INSTALL_DIR>/properties
directory.

The yfs.smtp.session.reaptime property in the yfs.properties file is used to set


the JMS session reaptime. To modify this property, add an entry for it in the
<INSTALL_DIR>/properties/customer_overrides.properties file. For additional
information about overriding properties using the customer_overrides.properties
file, see the Sterling Selling and Fulfillment Foundation: Properties Guide.

Nomenclature Runtime Component


The Nomenclature Runtime component provides a mapping tool that allows you
to configure unique terms you use to match unique terms your trading partners
use.

Configuration Properties

The following are the properties of this node:


Table 473. Nomenclature Runtime Properties
Property Description
Nomenclature XML Name Defines the source to destination mapping for documents
needing transformation.

Nomenclature Runtime
For configuring the runtime properties:
Table 474. Nomenclature Runtime Configuration Properties
Property Description
XML Name Select XML name created through nomenclature
configuration. For more information about nomenclature
configuration, see Section 10.4, "Defining Nomenclature
Configuration".

Connection Properties

The following are the Nomenclature Runtime connection properties of this node:
Table 475. Nomenclature Runtime Connection Properties
Connection Node Connection Rules
Can be the first node after Only for services invoked synchronously
the start node
Can be placed before v Any transport node except for FTP or File I/O
v Any other component node

Chapter 24. Transport Nodes 611


Table 475. Nomenclature Runtime Connection Properties (continued)
Connection Node Connection Rules
Can be placed after v Start node
v Any transport node except for FTP or File I/O
v Any other component node
Passes data unchanged No

Router
Allows business documents to be routed based on participant preferences.
Participants can be configured with different services to enable business documents
to be delivered to them. In the scenario modeling, data published to trading
partners is marked through a Router.

Router extracts the organization code from the data published during run time and
extracts relevant organization preferences for document delivery and executes the
service specified for the Participant.

Configuration Properties

The following are the properties of this node:


Table 476. Router Configuration Properties
Property Description
Document Name Select the document being routed to the Participant. For
example, Purchase Order.
Route XML Data To Following Roles
Trading Partner Role Select the participant’s role. For example, BUYER or
SELLER
XML Attribute Enter the XML path where the participant’s organization
code is located. For example, xml://Order/
@OrganizationCode.

Participant preferences are appended to the document


before executing the specified service.

Connection Properties

The following are the Router node’s connection properties:


Table 477. Router Connection Properties
Connection Node Connection Rules
Can be the first node after Only for services invoked synchronously
the start node
Can be placed before v Any transport node except FTP or File I/O
v Any other component node
Can be placed after v Start node
v Any transport node except FTP or File I/O
v Any other component node

612 Sterling Selling and Fulfillment Foundation: Application Platform Configuration Guide
Table 477. Router Connection Properties (continued)
Connection Node Connection Rules
Passes data unchanged Yes

Text Translator
The Text Translator converts flat files to and from XML format, enabling flat-file
applications to integrate with Sterling Selling and Fulfillment
FoundationApplication. For detailed information about Text Translator file
configuration, see "Time-Triggered Transaction Reference".

Configuration Properties

The following are the properties of this node:


Table 478. Text Translator Configuration Properties
Property Description
Input Data Format Select the format in which data is input. Options are:
v Text - Flat text files
v XML - Structured text files
Output Data Format Enter the format of the output data, automatically
determined by the choices for Input Data Format
combined with Input Text Format or Output Text Format.
Input Text Format If you selected Input Data Format to be Text select:
v Text Positional - For a Flat text file with fields that have
a fixed maximum length and records that have a
common end-of-record terminator
v Text Delimited - For a Flat text file that contains one or
more records separated by a specified delimiter, or
separator
Schema Name Enter the relative path to the schema description file of
the translation from XML input to a flat file. The location
is relative to the CLASSPATH of the integration adapter.

For example, if the flat file schema XML file is located in


<INSTALL_DIR>/bin/test.xml, and <INSTALL_DIR> is in
the CLASSPATH, then the value of the attribute is
/bin/test.xml.

Connection Properties

A Text Translator has to be either preceded by a File or DCS 6.2 Database node or
succeeded by a File or DCS 6.2 Database node, using the following conditions:
v When the File or DCS 6.2 Database node is followed by a Text Translator
component:
– Output format is always XML
– Input format must be text
v When the Text Translator component is followed by a File or DCS 6.2 Database
node:
– Output format must be text (either positional or delimited)
– Input format must be XML

Chapter 24. Transport Nodes 613


The Text Translator component cannot be directly before or after a pass-through
node.

The following are the Text Translator node's connection properties:


Table 479. Text Translator Connection Properties
Connection Node Connection Rules
Can be the first node after Only for services invoked synchronously
the start node
Can be placed before v Any synchronous transport node
v Any other component node except for a pass-through node
Can be placed after v Start node
v Any synchronous transport node
v Any other component node except for a pass-through node
Passes data unchanged Yes

XSL Translator
The Extensible Stylesheet Language (XSL) is used to transform XML documents
into display formats such as HTML.

In Sterling Selling and Fulfillment FoundationApplication, a classpath can be used


to find the XSL files included by the xsl:include directive. You can define the class
to provide a custom URIResolver during XSL processing using the
yfs.xsl.uriresolver property. By default, the value of this property is set to
com.yantra.interop.util.YantraDefaultURIResolver.

If you want to specify a different class name, modify the yfs.xsl.uriresolver


property in the <INSTALL_DIR>/properties/customer_overrides.properties file.
For additional information about overriding properties using the
customer_overrides.properties file, see the Sterling Selling and Fulfillment
Foundation: Properties Guide.

Note: If the yfs.xsl.uriresolver property is set to another class name, this new
class will be used in place of the default YantraDefaultURIResolver class. The new
class must implement the javax.xml.transform.URIResolver interface.

Configuration Properties

The following are the properties of this node:


Table 480. XSL Translator Configuration Properties
Property Description
XSL Name Enter the XSL template name. The location is relative to
the CLASSPATH of the integration adapter.

614 Sterling Selling and Fulfillment Foundation: Application Platform Configuration Guide
Connection Properties

The following are the XSL Translator node's connection properties:


Table 481. XSL Translator Connection Properties
Connection Node Connection Rules
Can be the first node after Only for services invoked synchronously
the start node
Can be placed before v Any transport node except for FTP or File I/O
v Any other component node
Can be placed after v Start node
v Any transport node except for FTP or File I/O
v Any other component node
Passes data unchanged Yes. The XSL translator can manipulate data streams to fit
specific business integration needs.

Defaulting Component
This component applies defaulting based on configured properties and invokes a
class to apply additional overrides. It can also be used to localize data in the XML.

The input to this component is an XML and the output is the same XML with the
defaults applied. The properties of this component define the XML attributes to
which the defaults are applied. The attributes themselves are defined through the
notation used in other service components.

For example, in the createOrder() API assume the unit of measure on the <Item>
element in the <OrderLine> node needs to be defaulted. The component property
is defined as:
Attribute=/Order/OrderLines/OrderLine/Item/@UnitOfMeasure
Default Value = "EACH"
Overrride = Y

If the input XML is:


<Order>
<OrderLines>
<OrderLine>
<Item ItemID="" />
</OrderLine>
</OrderLines>
</Order>

A UnitOfMeasure attribute is added with a value of EACH to the Item element. The
override property indicates if the attribute in the input XML needs to be
overridden irrespective of the existence of the attribute.

The configuration properties for the defaulting component defined in the following
table are optional.
Table 482. Defaulting Component Configuration Properties
Property Description
General Tab

Chapter 24. Transport Nodes 615


Table 482. Defaulting Component Configuration Properties (continued)
Property Description
Defaulting Template Enter the path for the defaulting template. This template
consists of a set of attributes and their default values. For
example:
<Overrides>
<Override
AttributeName="/Order/OrderLines/OrderLine/Ite
m/@UnitOfMeasure" AttributeValue="EACH"
Override="Y" />
</Overrides>

Note that the attribute path is an XPath variable.


Custom Class Enter the custom class that provides the defaulting
attributes. This class gets the original input to the
component, modified XML by the defaulting template and
apply any additional overrides and return the modified
output XML. This class implements the
YIFXXMLAttrOverride interface. For more information
about this interface, see the Sterling Selling and Fulfillment
Foundation: JavadocsJavadocs.

This class can also verify the existence of order and apply
or override the defaults applied previously. This class is
primarily used to default based on lookup of data from
the database or to reverse the defaulting, in the case of a
modification.
LocaleCode Path Enter the locale code path within the input document as
an XPath expression.

You can specify the Localize Attribute in the custom


overrides rather than specifying a static attribute value.
For example the XML file can contain the type as:
<Overrides>
<Override
AttributeName="//Organization/@OrganizationCod
e" Type="LOCALIZE" />
</Overrides>
Custom Overrides Tab
Element Path Specifies the path of the element for the custom overrides.
This is an Xpath expression.
Attribute Specifies the name of the attribute.
Value Specifies the value of the attribute.
Adding a Custom Override
Element Path Enter the Xpath of the element for the custom overrides.
Attribute Name Enter the name of the XML attribute that you wish to
override.
Localize Attribute Select this option if the attribute value is localized. The
path for localization is specified in the LocaleCode.
Use Static Attribute Value Select this option if you want to use a static attribute
value.

Once this option is selected you can enter the value and
check the override for an existing value.
Attribute Value Enter the value for the attribute.

616 Sterling Selling and Fulfillment Foundation: Application Platform Configuration Guide
Table 482. Defaulting Component Configuration Properties (continued)
Property Description
Always override Existing value Check this box if you want to always override the existing
value with the new value entered above.

Data Security
The data security component enables users to configure an attribute of the XML
that is coming in or flowing through the service to be validated against the list of
enterprises. This enables you to secure data based on the user groups discussed in
Section 4.3 Defining User Groups".

For enterprise validation, the list of enterprises that the user can access is
determined and validated for the attribute value provided. Once the user is
determined, the data security ID for that user is picked from the YFS_USER table
and the list of enterprises the user can access is determined and the value of the
attribute is validated.

For custom validation, you can implement a YIFSecurityValidator interface to set


and validate the user ID. The class that implements this interface is created, the
user is set in that component, and the input XML is parsed to obtain a list of
attribute values, which are then passed to a validating method.

For more information about the YIFSecurityValidator, see the JavadocsSterling


Selling and Fulfillment Foundation: Javadocs.

If the security component access validation succeeds, the input XML is passed to
the next component. If the validation fails an error is thrown back to the caller
indicating that the security access failed.

This data security component can be used in a service where an XML is flowing
through. If the component is configured after a component that does not output an
XML, a runtime error is thrown.
Table 483. Data Security Panel Configuration Properties
Property Description
General Tab
Enterprise Validation Select this option if you want the user group to be
validated against a list of enterprises.

If this option is selected, the Attributes to Validate must


be entered.
Attributes to Validate Required, only if enterprise validation is selected. Enter
the XPath to an attribute that needs to be validated.
Custom Validation Select this option if you choose to do a custom validation.

The class name should be provided if this option is


selected.
Class Name Required, only if custom validation is selected. Enter the
name of the custom class that you wish to implement for
the custom validation.

Chapter 24. Transport Nodes 617


Table 483. Data Security Panel Configuration Properties (continued)
Property Description
User Identification Select one of the following options to set the user
information for the custom or enterprise validation.

User ID: Select the user ID from the drop-down list.

YFSEnvironment: Select this option to use the user ID


from YFSEnvironment.
Arguments Tab
Argument Name The name of the parameter to be passed to the validator
method.
Argument Value The value of the parameter to be passed to the validator
method.

Jasper Printer Component


This component is used to automatically print a document based on an event.
Additionally, you can also generate the PDF or an RTF object of a document. It is a
standard XML-based component: accepts XML as input and provides an identical
output XML.

For example, printing a pick list in a store for store pick-up is an example where
the store does not maintain the inventory. In this case, the website where the order
is placed or a call center captures orders for store pick-up. These orders are sent
down to the store for processing. A store inventory control associate periodically
checks to see if there are any orders to be picked. If there are, the associate can
print a paper pick list to pull the products required off the retail floor. In some
cases, the print can be triggered automatically when an order is received at the
store.

A document can be printed conveniently by a single click from the console. This is
supported by using flow execution and the printer component.

Jasper Print component can be used to generate a PDF report and stream it down
via HTTP response. This can be done by configuring a service with a Jasper Print
component and selecting the "Jasper Print Object" option. You can also use the
Jasper Print component to generate a rich text format (RTF) report and stream it
through an HTTP response. This service is now invoked by making a HTTP call to
the "InteropJasperServlet" servlet and passing the input XML "locale" to the service
and the name of the service that you created for generating PDF objects. These
services are created in the Service Definition Framework (SDF). For more
information about SDF and how to create service, see Chapter 3. The PDF or RTF
report that is generated is streamed back by the servlet and formatted according to
the options set in the InteropJasperServlet.

You can also audit the success and failure of the printing events using the print
transaction defined under the general process type. This transaction is configurable
and has two events: Print.ON_SUCCESS and Print.ON_FAILURE. The
ON_FAILURE event is raised only for service suspend exceptions such as print
failures.

The following table provides the Jasper printing configuration properties:

618 Sterling Selling and Fulfillment Foundation: Application Platform Configuration Guide
Table 484. Jasper Printing Configuration Properties
Field Description
General Tab
Jasper Report This is a compiled Jasper file. The file name supports variables
in both a standard and enhanced variable format as explained
in the Sterling Selling and Fulfillment Foundation: Customization
Basics.
Report Select Exp Specify the element to be sent as the root of the report. By
default, the entire XML is used. An error is thrown, if this field
is given but does not resolve to an element.
Locale Specify the locale for translating the literals in the report. The
data in the XML can be localized using the defaulting
component discussed in “Defaulting Component” on page 615.
Use Sterling Selling and If checked, all literals in the report are translated to the
Fulfillment requested locale using the Sterling Selling and Fulfillment
FoundationApplication FoundationApplication Resource Bundle.
Resource Bundle
Output Tab
Printer Select this option to specify a printer to use.
Printer Name Enter the XML path pointing to the printer to use.
Number of Copies Enter the number of copies you wish to print.
Jasper Print Object Select this option to generate a PDF or an RTF object. The
report object option is set in the InteropJasperServlet.
Variables Tab
Variable Name The name of the parameter to be passed to the validator
method.
Variable Value The value of the parameter to be passed to the validator
method.

To allow custom print formats, the configuration of the print component supports
changing report file names based on an input XML. For example, if the input XML
contains the file name:
${jasperfolder}/compiled/${orgcode}/report.${doctype}.jasper

First, all variables are resolved against the variables defined in the Variables tab:

orgcode g xml:/Order/@OrganizationCode

doctype g xml:/Order/@DocumentType

The remaining variables are resolved against the yfs.properties file. In this case,
the ${jasperfolder} variable is resolved from the yfs.properties definition:
jasperFolder=/someCustomJasperFolder. To modify this property, add an entry for
it in the <INSTALL_DIR>/properties/customer_overrides.properties file. For
additional information about overriding properties using the
customer_overrides.properties file, see the Sterling Selling and Fulfillment
Foundation: Properties Guide.

So, with the input of <Order OrganizationCode="DEFAULT" DocumentType="0001"


.... /> the expression resolves to: /someCustomJasperFolder/compiled/DEFAULT/
report.0001.jasper.

Chapter 24. Transport Nodes 619


An exception is thrown if an error occurs when processing the report. For example,
an exception is thrown if the file name is invalid. A service suspend exception is
thrown while printing the report enabling the ability to pause an asynchronous
service.

Adapter Nodes
The Service Definition Framework provides hooks to connect to external systems
like IBM Sterling B2B Integrator through custom adapters. Sterling Selling and
Fulfillment FoundationApplication currently provides the standard adapter Sterling
GISIBM Sterling B2B Integrator.

Sterling GISIBM Sterling B2B Integrator


This adapter is used for communicating with the IBM Sterling B2B Integrator
product over the HTTP protocol. It is capable of streaming XML over HTTP
connection as opposed to sending name-value pairs resulting in better
performance. However, if you want to use name-value pairs you need to be on a
specific GIS fix pack. For more information about the fix pack appropriate for your
JDK version, see the Sterling Selling and Fulfillment Foundation: Installation Guide.

Configuration Properties

The following are the properties of this adapter:


Table 485. IBM Sterling B2B Integrator Configuration Properties
Property Description
URL Enter the URL to which the message is to be posted.
Stream XML Document Select this field if you want to send and receive streaming XML
documents. If selected, the "HTTP Post Variable" entry box is
disabled.
HTTP Post Variable Enter the variable name to which the HTTP post data is to be
assigned.
Is Secure If this field is selected, the message is encrypted when being
posted to the URL specified.
Key Store Type If Is Secure is checked, set this value to JKS (Java Key Store).
Key Store If Is Secure is selected, enter the key store for storing client side
digital certificates. If you are using variables instead of the full
path names ensure that the variable is defined in the
<INSTALL_DIR>/properties/customer_overrides.properties
file. For additional information about overriding properties
using the customer_overrides.properties file, see the Sterling
Selling and Fulfillment Foundation: Properties Guide.
Key Store Passwd If Is Secure is selected, enter the password to access the key
store.
Trust Store If Is Secure is selected, enter the trust store for storing server
side digital certificates. If you are using variables instead of the
full path names ensure that the variable is defined in the
<INSTALL_DIR>/properties/customer_overrides.properties
file. For additional information about overriding properties
using the customer_overrides.properties file, see the Sterling
Selling and Fulfillment Foundation: Properties Guide.

620 Sterling Selling and Fulfillment Foundation: Application Platform Configuration Guide
Table 485. IBM Sterling B2B Integrator Configuration Properties (continued)
Property Description
Trust Store Passwd If Is Secure is selected, enter the password to access the trust
store.

If you want to use name-value pairs enter the HTTP post variable name. If you
need to specify any additional name-value pairs enter the name and value in the
Post Variables tab. In this tab, select and follow the information given in the
following table:
Table 486. IBM Sterling B2B Integrator Post Variable Properties
Fields
Post Variable Name Enter the name of the post variable.
Post Variable Value Enter the value of the post variable name.

Chapter 24. Transport Nodes 621


622 Sterling Selling and Fulfillment Foundation: Application Platform Configuration Guide
Chapter 25. Text Translator Reference
Occasionally, service nodes require files to be configured, in addition to the
graphical user interface.

Understanding File Formats


A flat file usually contains a series of records (or lines), where each record is
usually a sequence of fields.

A flat file format can be any of the following types:


v Positional
v Delimited
v XML

Positional Flat Files


A positional flat file has fields that have a fixed maximum length and records that
have a common end-of-record terminator.

For example, if a positional flat file on a UNIX system has a Name field that is
fixed at a maximum of fifteen characters, a Color field that is fixed at a maximum
of ten characters, white space padding the end of each field, and the \n new line
feed character, it would appear as shown in the example below:

NAME COLOR \n
Sam turquoise \n
David red \n
Elizabeth orange \n

Figure 34. Fragment of a Positional Flat File

Delimited Flat Files


A delimited flat file contains one or more records set off from each other by a
specified delimiter, or separator. For example, each record may be terminated by
the operating system's line separator and each field within a record may be
separated by a comma.

Delimiters are not read in as part of the data. However, if the delimiter character
does appear as data, the data can be formatted so the data and the delimiter are
distinguishable. For example, the field in which a delimiter character displays can
be enclosed in quotation marks to indicate that the delimiter character is to be
treated as data and not as a delimiter. For example, if you choose to use an asterisk
(*) as the delimiter and it also displays in a data field following the word Special,
then it should exist in the flat file as "Special*". In other words, the complete data
field should be within quotation marks (" ").

For example, if a delimited flat file on a UNIX system has fields that are delimited
by commas, it would appear as shown below.

© Copyright IBM Corp. 1999, 2011 623


NAME, COLOR
Sam, turquoise \n
David, red \n
Elizabeth, orange \n

Figure 35. Fragment of a Delimited Flat File

XML Flat Files


In some cases, legacy applications produce XML files. These native XML files need
to be translated into a format that is usable by Sterling Selling and Fulfillment
FoundationSterling Application Platform by means of an XSL.

If the input flat files are XML files, then the source XML must contain a root
element, followed by a sequence of one or more child elements. Each child element
under the root element is treated as the input for the flat file receiver service. For
example, if the source XML is like so:
<?xml version="1.0" encoding="UTF-8"?>
<Orders>
<Order name="A1">....</Order>
<Order name="A2">....</Order>
<Order name="A3">....</Order>
</Orders>.

then the input XML is processed to create three different XMLs, as follows:
<Order name="A1"/>
<Order name="A2"/>
<Order name="A3"/>

The API that has been configured for this flat file receiver is executed three times,
each with a different XML as shown above.

For examples of flat files using the createOrder() API as input, see the
<INSTALL_DIR>/xapidocs/code_examples/flatfile/ directory.

The location of the data in the flat file is specified as the incoming directory within
the configuration. The flat file is used as input to a Sterling Selling and Fulfillment
FoundationSterling Application Platform API, as determined by the XSD.

Text Translator Components


XSD Files
The Text Translator uses XSD files, a type of XML file, to convert flat files to and
from XML format. Sterling Selling and Fulfillment FoundationSterling Application
Platform supplies four XSDs—two XSDs for data coming in from positional and
delimited files and two XSDs for data from Sterling Selling and Fulfillment
FoundationSterling Application Platform to convert to positional and delimited flat
files.

These files follow the standards defined by the World Wide Web Consortium
(W3C); for information about this standard, see http://www.w3.org/XML/
Schema.

624 Sterling Selling and Fulfillment Foundation: Application Platform Configuration Guide
All four XSD files are designed specifically to correspond with the Sterling Selling
and Fulfillment FoundationSterling Application Platform APIs, and so they cannot
be modified. However, you do need to refer to the XSDs when defining and
implementing schema files.

Each of the following XSD files is described within this chapter:


v Text Translator Positional Receiver XSD File
v Text Translator Delimited Receiver XSD File
v Text Translator Positional Sender XSD File
v Text Translator Delimited Sender XSD File

These files are archived in the ycpbe.jar file in order to be used by Sterling Selling
and Fulfillment FoundationSterling Application Platform.

Schema Files
The Text Translator uses schema files, a type of XML file, that describe the
structure of each flat file. The format of the schema determines how the data is
translated by a service and should unambiguously determine the parsing of the
flat file data.

File schemas are required on a per API per file format basis (for example, you may
need to create a positional createOrder schema or a delimited createOrder schema),
so you need to write least one unique schema per API you intend to execute.

The translation step can be independent of the source of the input data. The same
data could arrive through a flat file store or through a JMS queue, and the
translation specification applies in either case.

The schema file for byte count check is 0-based for the file header and 1-based for
the file trailer. Therefore, you must take this into account when creating the file
schema. When specifying the FileTrailerLength in the positional schema file, you
must account for a new line if the file trailer ends with a new line. On UNIX, a
new line has one byte, and on Windows a new line has two bytes. The length of
the new line character has to be added to the FileTrailerLength.

The schema file is stored in any location accessible as a CLASSPATH variable. For
sample schema files that correspond to the provided sample input files, see the
files in the <INSTALL_DIR>/xapidocs/code_examples/flatfile/ directory.

Note: IBM recommends that you periodically check for files within the /error/
and /complete/ directories that contain errors or are unprocessed.

Defining a Schema File


The schema file describes the structure of your incoming data file. The format of
the schema determines how the data is translated by the service and should
unambiguously determine the parsing of the flat file data.

File schemas are required on a per API per file format basis (for example, you may
need to create a positional createOrder schema or a delimited createOrder schema),
so you need to write least one unique schema per API you intend to execute. A
schema file is written using XML.

Chapter 25. Text Translator Reference 625


The schema file is stored in any location accessible as a CLASSPATH variable. For
sample schema files that correspond to the provided sample input files, see the
files in the <INSTALL_DIR>/xapidocs/code_examples/flatfile/ directory.

XML to XML translation does not require a schema or XSD file.

Verifying the Text Translator Setup


Before deploying a service, you should create a few test files and run them
through the entire process to ensure that all data is being captured and used
correctly.

If any errors are encountered while processing a flat file, these errors are logged in
two files as specified in the Flat File Receiver configuration file.
v Error file - logs a list of each incident where an error occurs
v Error data file - contains the actual records that are in error

For example, if you have specified that both error files use the default suffix (.err)
and you want to process data from an incoming file named text.in, the Text
Translator creates error log files when it encounters an error, and thereafter, any
additional errors are appended to the end of each of the following files:
v text.in.err - lists the error incidents
v text.in.err.dat - contains the records that are in error

Error Messages
In order to cover a wide variety of situations, error messages typically have more
than one parameter. Each parameter points to either field names or field positions.
The following table lists all possible error conditions. At run-time, the parameters
in braces ({}) are filled in with context-specific data.

Note: You should periodically check for files within the /error and /complete
directories that contain errors or remain unprocessed.
Table 487. Possible Errors in the Error File
Error Code Description
YIF_OVERLAPPING Field {0} intersects Field {1} in Record {2} This error code
_FIELDS indicates that two fields in the same record have overlapping
positions
YIF_INVALID_ Field {0} has invalid bounds: startPos={1} endPos={2} This
FIELD_BOUNDS error code indicates that the startPosition of a field is greater
than the end position of the field
YIF_INVALID_ The position of the record type field is invalid.
RECORD_TYPE_POS
YIF_EMPTY_ Record {0} does not have a record type identifier. When the
RECORD_TYPE data contains a record whose record type has not been
declared in the schema.
YIF_EMPTY_ No fields exist to match for a record. The data contains a
RECORD_FOUND record with a record type identifier but the individual fields
do not exist

626 Sterling Selling and Fulfillment Foundation: Application Platform Configuration Guide
Table 487. Possible Errors in the Error File (continued)
Error Code Description
YIF_INVALID_ Record {0} should not have a gap [Field {1} endPosition={2}]
FIELD_GAP and [Field {3} startPosition={4}]. n a positional format, two
fields should not have a gap. It is fixed width, so
unaccounted gaps cannot exist. Fixed width. Period.
YIF_FIELD_ In Record {0}, the field {1}[startPos={2}, endPos={3}] overlaps
OVERLAPS_ record type field {4} [startPos={5}]. In a positional format,
RECORD_TYPE when a field datum overlaps with the boundary of a record
type identifier.
YIF_FIELD_ In Record {0}, the field {1}[position={2}] overlaps record type
OVERLAPS_ field {3} [position={4}]. In a delimited format, when a field
RECORD_TYPE datum overlaps with the boundary of a record type identifier
_FIELD
YIF_SCHEMA_ Schema contains a cycle starting at element: {0} and ending
CONTAINS_CYCLE before element: {1}. The schema description does not allow
for cyclical containment. If it does, the above error code is
reported.
YIF_RECORD_ Record Id {0} is too large. Record Identifiers have a fixed
ID_TOO_LARGE width, this error is reported when the size is exceeded.
YIF_FIELD_ Field {0} in attribute map does not exist in record {1}. When
NOT_DEFINED translating from XML to positional/delimited format, if the
_IN_RECORD field that an XML attribute maps to does not exist.
YIF_TOO_ Number of attribute maps = {0} in elementMap {1} exceeds
MANY_ the number of fields = {2} in record {3}. The number of
ATTRIBUTE attributes in an XML element that need to be mapped to
_MAPS fields, cannot exceed the number of fields in the
corresponding record.
YIF_INVALID_ RecordIdStartPos: {0} must be less than the RecordIdEndPos:
RID_BOUNDS {1}. In a positional format, the bounds of the record identifier
must be correct.
YIF_RECORD_ Could not match record id: {0} with any record declared in
ID_NOT_ the schema
MATCHED
YIF_INCORRECT_ Record length is incorrect.
RECORD_
LENGTH
YIF_RECORD_ Too few fields. Min fields = {0} Found = {1}
LENGTH_
TOO_SMALL
YIF_TOO_FEW Found few fields for record id: {0}. Expected = {1} Found =
_FIELDS_ {2}
FOR_RECORD
YIF_TOO_MANY Too many fields for record id: {0}. Expected = {1} Found = {2}
_FIELDS_
FOR_RECORD
YIF_RECORD_ Too many fields. Max fields = {0} Found = {1}
LENGTH_TOO
_LARGE
YIF_RECORD_TOKEN Scanned record name: {0} is not fully matched. Current Token:
_NOT_FULLY {1}
_MATCHED

Chapter 25. Text Translator Reference 627


Table 487. Possible Errors in the Error File (continued)
Error Code Description
YIF_INCOMPLETE Record Set preceding scanned record name: {0} is not
_PREVIOUS completely matched.
_MATCH
YIF_MAX_ Number of matches exceeds Max matches for record: {0}
OCCURENCE_
EXCEEDED
YIF_FILE_ File length: {0} must exceed the sum of the
VIOLATES_ fileHeaderLength:{1} and the fileTrailerLength: {2}
CONTROL_INFO
YIF_FILE_ Expected file header id: {0} is not found
HEADER_
DOES_NOT
_EXIST
YIF_FILE_TRAILER_ Expected file trailer id: {0} is not found
DOES_NOT_EXIST
YIF_FILE_HEADER Expected file header id: <{0}> does not match found: <{1}>
_DOES_
NOT_MATCH
YIF_FILE_TRAILER Expected file trailer id: <{0}> does not match found: <{1}>
_DOES_NOT
_MATCH
YIF_UNABLE_ Unable to set the bounds on input stream ScanLength= <{0}>
TO_BOUND_ ScanStartPosition=<{1}>
INPUT_STREAM
YIF_DIR_DOES The specified directory: {0} does not exist.
_NOT_EXIST
YIF_DIR_IS_ The specified directory: {0} does not have write permissions.
NOT_WRITEABLE
YIF_INVALID_INCLUDES The includes pattern: {0} is not a valid regular expression.
_PATTERN

Text Translator XSD Files

Text Translator Positional Receiver XSD File


The positional receiver XSD file defines how the data in flat, positional files should
be transformed to XML data. The following table lists the essential XSD elements
and attributes.

“Newline” is the only supported record delimiter used by the Positional Receiver
XSD file.
Table 488. Elements in the Positional Flat File Receiver XSD File
Property Description
ParserDefaults Element
RecordIdStartPosition Required. Integer. This field indicates the start position of the
RecordId for each record.

628 Sterling Selling and Fulfillment Foundation: Application Platform Configuration Guide
Table 488. Elements in the Positional Flat File Receiver XSD File (continued)
Property Description
RecordIdEndPosition Required. Integer. This field indicates the end position of the
RecordId for each record.
DefaultRecordDelimiter Optional. The default record delimiter is Newline.
DefaultEscapeCharacter Optional. CharacterType. The default escape character is \.
DefaultPadCharacter Required. String. Minimum length=1. Maximum length=1.
Fills the non-data portion of a field with any single
character. Valid values include a space or zero as well as any
other character. The default value is #.

For example if you specify trailing ###'s in a field, they are


ignored.

This character is used for visual convenience when you want


to space out the fields correctly and do not want to rely on
the blank space.
SkipCarriageReturn Optional. Boolean. Defaults to true.
FileHeader Element

The header that is written to a file before writing anything else. This can be used as control
information. Each transaction set starts with a header record. If it contain internationalized
text, its length must be byte accounted.

For example, a Sales Order record set has an OrderHeader record that specifies the
beginning of the transaction set.

This element is optional. However, if FileHeader element is provided the FileTrailer


element must also be present. These two elements are used to include text at the beginning
and end of each file respectively.
FileHeaderName Optional. String. The descriptive name of the FileHeader.
However, this is not used for processing.
FileHeaderId Required. String. This attribute provides the text to match, at
the start of each file.
FileHeaderStartPos Required. Integer. The starting position of the header.
FileHeaderLength Required. Integer. The length of the header.
FileTrailer Element

The trailer that is written to the end of a file. This can be used as control information to
verify if a file is indeed complete. If it contain internationalized text, its length must be
byte accounted.
FileTrailerName Optional. String. The descriptive name of the FileTrailer.
However, this is not used for processing.
FileTrailerId Required. String. This attribute provides the text to match, at
the end of each file.
FileTrailerStartPos Required. Integer. The starting position of the trailer.
FileTrailerLength Required. Integer. The length of the trailer.
CharacterType Element

This element specifies the character type of all the elements and attributes used in the XSD
file. Required. String. Minimum length=1. Maximum length=1.

Chapter 25. Text Translator Reference 629


Table 488. Elements in the Positional Flat File Receiver XSD File (continued)
Property Description
Root Element

The elements and attributes defined under Root elements portrays the organization of the
input flat file.
Name Required. NMTOKEN. The name of the root element. This is
the same root-element name of the XML you are building.
Description Optional. String. The description of the root element. This
attribute is not used for processing.
XMLName Optional. Name of the root entity in the translated XML.
Header Element

Required. This is the first record that is read under Root element.
Name Required. NMTOKEN. The name of the header element. This
is the tag name in your XML file.
RecordName Required. NMTOKEN. The name of the record. This field
must match the Name attribute of the Record element. This
name is the identifier for the RecordName used in the flat file.
MinOccurence Optional. Integer. Minimum number of times this sequence
can occur. By default, this sequence should occur at least
once. A value of 0 means that the occurrence of this
sequence is optional. Defaults to 1.
MaxOccurence Required. Integer. The maximum number of times this
sequence can occur. A value of 0 means that this sequence
can occur an unlimited number of times. Defaults to 1.
Terminal Element

Defines a record that is not a part of a sequence or a choice entity. A terminal entity is a
leaf node in the hierarchy.
MinOccurence Optional. Integer. Minimum number of times this sequence
can occur. By default, this sequence should occur at least
once. A value of 0 means that the occurrence of this
sequence is optional. Defaults to 1.
MaxOccurrence Optional. Integer. The maximum number of times this
sequence can occur. A value of 0 means that this sequence
can occur an unlimited number of times. Defaults to 1.
Name Required. NMTOKEN. Name of the terminal node.
RecordName Required. NMTOKEN. Name of the record that corresponds
with this terminal node.
Sequence Element

This element is required and is of type SequenceType.

The record corresponding to a sequence entity which indicates the beginning of a


sequence. This record may have sub-record of multiple types like, Terminal, Sequence or
Choice elements.

For example, an order transaction could contain an order line, and an order line could
contain a sequence of one or more line items. In this case, the order line record
corresponds to a sequence entity, and this sequence entity contains another sequence entity
corresponding to a line item as a child.

630 Sterling Selling and Fulfillment Foundation: Application Platform Configuration Guide
Table 488. Elements in the Positional Flat File Receiver XSD File (continued)
Property Description
MinOccurence Optional. Integer. Minimum number of times this sequence
can occur. By default, this sequence should occur at least
once. A value of 0 means that the occurrence of this
sequence is optional. Defaults to 1.
MaxOccurence Optional. Integer. The maximum number of times this
sequence can occur. A value of 0 means that this sequence
can occur an unlimited number of times. Defaults to 1.
Name Required. NMTOKEN. The name of the sequence element.
RecordName Required. NMTOKEN. The record name of the sequence
element identified in the flat file.
Choice Element

This element is required and is of ChoiceType.

The choice entity declaration defines one entity in a group of child elements that displays
in the data. The choice entity does not correspond to a record. It is simply a grouping of a
record's child elements, specifying that exactly one of its child elements can occur.
However, each child element can correspond to a sequence element or a terminal element.
MinOccurence Optional. Integer. Minimum number of times this sequence
can occur. By default, this sequence should occur at least
once. A value of 0 means that the occurrence of this
sequence is optional. Defaults to 1.
MaxOccurence Optional. Integer. The maximum number of times this
sequence can occur. A value of 0 means that this sequence
can occur an unlimited number of times. Defaults to 1.
Name Required. NMTOKEN. The name of the choice element.
RecordDefinitions\Record Element

A record describes a line in the flat file. This record definition is translated into an XML
element.
RecordId Required. NMTOKEN. This is the RecordId in the source
XML file.
Name The name of the record. This is used to associate with a
Header, Terminal, Sequence or Choice Name attribute.
Description String. The description of the name. This is not used while
processing the file.
XMLName Required. NMTOKEN. The tag name of the output element.
Field Element

Each record consists of fields, which are translated into attributes or child elements
depending on the ContainmentType.
Name Required. NMTOKEN. The name of the field. This name
must be unique within a record.
XMLName Required. NMTOKEN. The output attribute or element name
of the XML.
Description Optional. String. The description on the field.

Chapter 25. Text Translator Reference 631


Table 488. Elements in the Positional Flat File Receiver XSD File (continued)
Property Description
ContainmentType This is either an Attribute or Element in the XML. If it is an
Attribute, a new attribute is set to this field's value. If it is an
Element, a new child element is created with the tag name
set to XMLName and the value set to value of this field.

Defaults to Attribute.
StartPosition Required. Integer. The StartPosition should be one number
greater than the EndPosition of the previous record or field,
so that these two fields or records are contiguous.
EndPosition Required. Integer. The ending position of the field.
fileLayoutType Element Required. String. Values are

Positional - flat file with fixed-length fields

Delimited - flat file with varying-length fields

XML - flat file with fields denoted by XML tags


recordLayoutType Element Required. String. Values are:

Positional

Delimited
Justification Optional. Specifies the alignment of data.

Right - Aligns data to the right.

Left - Aligns data to the left when the data is less than the
maximum field length. This also aligns data to the left when
the amount of data is less than the minimum length
requirement. Default.
DefaultValue Optional. NMTOKEN.
PadCharacter Required. String. Minimum length=1. Maximum length=1.
Fills the non-data portion of a field with any single
character. Valid values include a space or zero.
PadCharacterType Element
Required. String. Minimum length=1. Maximum length=1.
Fills the non-data portion of a field with any single
character. Valid values include a space or zero.
JustificationType Element
Optional. Specifies the alignment of data.

Right - Aligns data to the right.

Left - Aligns data to the left when the data is less than the
maximum field length. This also aligns data to the left when
the amount of data is less than the minimum length
requirement. Default.

Text Translator Delimited Receiver XSD File


The Text Translator delimited receiver XSD file defines how the data in delimited
flat files should be transformed to XML data. The following table defines the
essential elements and attributes.
632 Sterling Selling and Fulfillment Foundation: Application Platform Configuration Guide
The Root, FileHeader and FileTrailer element definitions remain the same as
explained in “Text Translator Positional Receiver XSD File” on page 628.
Table 489. Elements in the Delimited Flat File receiver XSD File
Property Description
ParserDefaults Element
RecordIdStartPosition Required. Integer. Indicates the start position of a record.
DefaultRecordDelimiter Required. RecordDelimiterType. The default delimiter
between records is Newline.
DefaultFieldDelimiter Optional. CharacterType. The default field delimiter between
the fields is comma [,].
DefaultEscapeCharacter Optional. CharacterType. The default escape character is \.
DefaultPadCharacter Required. String. Minimum length=1. Maximum length=1.
Fills the non-data portion of a field with any single character.
Valid values include a space or zero as well as any other
character. The default value is #.

For example if you specify trailing ###'s in a field, they are


ignored.

This character is used for visual convenience when you want


to space out the fields correctly and do not want to rely on
the blank space.
DefaultWrapCharacter The Wrapping/Quote character is parameterized. One can
define the default wrapping character in the Flat
file-Delimited-Schema (Service component specific).

A sample entry is given below:


<?xml version="1.0" encoding="UTF-8"?>
<FlatfileDelimitedSchema xmlns:xsi=
"http://www.w3.org/2001/XMLSchema-instance"
xsi:noNamespaceSchemaLocation=
’delimitedreceiver.xsd’> <ParserDefaults
DefaultRecordDelimiter="Newline"
DefaultFieldDelimiter="|"
DefaultPadCharacter="#"
RecordIdStartPosition="1"
DefaultWrapCharacter="@">
...
</ParserDefaults>
</FlatfileDelimitedSchema>

In the above example, the Wrap/Quote character is set to


_@_.
Note: The default wrap character attribute is optional, and by
default has a value of "". If DefaultWrapCharacter="NONE",
then no wrap character is used.
SkipCarriageReturn Optional. Boolean. Defaults to true.
TranslationProperties Attributes
SchemaXMLFile Required. String. the relative path to the XSD description file
of the translation from XML input to a flat file. The location is
relative to the CLASSPATH of the FileSendAgent.

For example, if the flat file XSD XML file is located in the
<INSTALL_DIR>/bin/test.xml file, and <INSTALL_DIR> is in the
CLASSPATH, then the value of the attribute is /bin/test.xml
file.

Chapter 25. Text Translator Reference 633


Table 489. Elements in the Delimited Flat File receiver XSD File (continued)
Property Description
RecordDefinitions\Record Element

A record describes a line in the flat file. This record definition is translated into an XML
element.
Recorded Required. NMTOKEN. This is the RecordId in the source
XML file.
Name The name of the record. This is used to associate with a
Header, Terminal, Sequence or Choice Name attribute.
Description String. The description of the name. This is not used while
processing the file.
Smiling Required. NMTOKEN. The tag name of the output element.
Field Element

Each record consists of fields, which are translated into attributes or child elements
depending on the ContainmentType.
Name Required. NMTOKEN. The name of the field. This name must
be unique within a record.
Smiling Required. NMTOKEN. The output attribute or element name
of the XML.
Field Position Required. Integer The position of this field within the record.
If the Recorded is at position 1, then the numbering of fields
should begin at position 2.
Containment Type This is either an Attribute or Element in the XML. If it is an
Attribute, a new attribute is set to this field's value. If it is an
Element, a new child element is created with the tag name set
to Smiling and the value set to value of this field.

The default value is Attribute.

Text Translator Positional Sender XSD File


The Text Translator positional sender XSD file defines how XML data should be
transformed into a flat, positional file. The following table lists the essential XSD
elements and attributes.

The FileHeader and FileTrailer element definitions remain the same as explained
in “Text Translator Positional Receiver XSD File” on page 628.
Table 490. Elements in the Positional Flat File Sender XSD File
Property Description
Parser Defaults Element
Record Id Start Position Required. Integer. This field indicates the start position of the
Recorded for each record.
Record Id End Position Required. Integer. This field indicates the end position of the
Recorded for each record.
Default Record Delimiter Required. Record Delimiter Type. The default delimiter
between records is Newline.
Default Escape Character Optional. Characterizes. The default escape character is \.

634 Sterling Selling and Fulfillment Foundation: Application Platform Configuration Guide
Table 490. Elements in the Positional Flat File Sender XSD File (continued)
Property Description
Default Pad Character Required. String. Minimum length=1. Maximum length=1.
Fills the non-data portion of a field with any single
character. Valid values include a space or zero as well as any
other character. The default value is #.

For example if you specify trailing ###'s in a field, they are


ignored.

This character is used for visual convenience when you want


to space out the fields correctly and do not want to rely on
the blank space.
SkipCarriageReturn Optional. Boolean. Defaults to true.
ElementMapList Element

This element maps the elements in the XML to the records in the flat file.
ElementMap Element
ElementName Required. NMTOKEN. The name of the element in the XML
file.
RecordId Required. NMTOKEN. The record identifier to write.
AttributeMap Element
AttributeName Required. NMTOKEN. The name of the attribute.
FieldName Required. NMTOKEN. The field corresponding to the
attribute. This field corresponds to the Name attribute of the
Field element.
TruncateData Optional. Boolean. Defaults to true.
RecordDefinitions\Record Element

A record describes a line in the flat file. This record definition is translated into an XML
element.
RecordId Required. NMTOKEN. This is the RecordId in the source
XML file.
Name The name of the record. This is used to associate with a
Header, Terminal, Sequence or Choice Name attribute.
Description String. The description of the name. This is not used while
processing the file.
XMLName Required. NMTOKEN. The tag name of the output element.
Field Element

Each record consists of fields, which are translated into attributes or child elements
depending on the ContainmentType.
Name Required. NMTOKEN. The name of the field which is used
as a reference in the AttributeMap. This name must be
unique within a record.
XMLName Required. NMTOKEN. The output attribute or element name
of the XML.
StartPosition Required. Integer. The StartPosition should be one number
greater than the EndPosition of the previous record or field,
so that these two fields or records are contiguous.
EndPosition Required. Integer. The ending position of the field.

Chapter 25. Text Translator Reference 635


Table 490. Elements in the Positional Flat File Sender XSD File (continued)
Property Description
PadCharacter Required. String. Minimum length=1. Maximum length=1.
Fills the non-data portion of a field with any single
character. Valid values include a space or zero.
Justification Optional. Specifies the alignment of data.

Right - Aligns data to the right.

Left - Aligns data to the left when the data is less than the
maximum field length. This also aligns data to the left when
the amount of data is less than the minimum length
requirement. Default.

Text Translator Delimited Sender XSD File


The Text Translator delimited Sender XSD file defines how to transform XML data
to delimited files. The following table lists the essential elements and attributes.

The Root, FileHeader and FileTrailer element definitions remain the same as
explained in “Text Translator Positional Receiver XSD File” on page 628.
Table 491. Elements in the Delimited Flat File Sender XSD File
Property Description
ParserDefaults Element
RecordIdStartPosition Required. Integer. Indicates the start position of a record.
DefaultRecordDelimiter Required. RecordDelimiterType. The default delimiter
between records is Newline.
DefaultFieldDelimiter Optional. CharacterType. The default field delimiter
between the fields is comma [,].
DefaultEscapeCharacter Optional. CharacterType. The default escape character is \.
DefaultPadCharacter Required. String. Minimum length=1. Maximum length=1.
Fills the non-data portion of a field with any single
character. Valid values include a space or zero as well as
any other character. The default value is #.

For example if you specify trailing ###'s in a field, they are


ignored.

This character is used for visual convenience when you


want to space out the fields correctly and do not want to
rely on the blank space.
SkipCarriageReturn Optional. Boolean. Defaults to true.
SuppressEORFieldDelimiter Optional. Boolean. Defaults to False. This attribute when
passed as True does not print the delimiter at the end of the
record.
ElementMapList Element

This element maps the elements in the XML to the records in the flat file.
ElementMap Element
ElementName Required. NMTOKEN. The name of the element in the XML
file.

636 Sterling Selling and Fulfillment Foundation: Application Platform Configuration Guide
Table 491. Elements in the Delimited Flat File Sender XSD File (continued)
Property Description
RecordId Required. NMTOKEN. The record identifier to write.
AttributeMap Element
AttributeName Required. NMTOKEN. The name of the attribute.
FieldName Required. NMTOKEN. The field corresponding to the
attribute. This field corresponds to the Name attribute of the
Field element.
TruncateData Optional. Boolean. Defaults to true.
RecordDefinitions\Record Element

A record describes a line in the flat file. This record definition is translated into an XML
element.
RecordId Required. NMTOKEN. This is the RecordId in the source
XML file.
Name The name of the record. This is used to associate with a
Header, Terminal, Sequence or Choice Name attribute.
Description String. The description of the name. This is not used while
processing the file.
XMLName Required. NMTOKEN. The tag name of the output element.
WriteRecordId The default value is Y. If set to N, no record ID is written to
the output file.
Field Element

Each record consists of fields, which are translated into attributes or child elements
depending on the ContainmentType.
Name Required. NMTOKEN. The name of the field which is used
as a reference in the AttributeMap. This name must be
unique within a record.
XMLName Required. NMTOKEN. The output attribute or element
name of the XML.
FieldPosition Required. Integer The position of this field within the
record. If the RecordId is at position 1, then the numbering
of fields should begin at position 2.

Running the Text Translator


The Text Translator uses scripts located in the <INSTALL_DIR>/bin/ directory.

If you want to ensure that the file schemas and XSDs are parsed correctly and
understood, you can add the following line to the startup script:
"-Djavax.xml.parsers.SAXParserFactory=org.apache.xerces.jaxp.SAXParserFactoryImp
l
-Djavax.xml.parsers.DocumentBuilderFactory=org.apache.xerces.jaxp.DocumentBuilde
rFactoryImpl"

For example, the entire Java line in the startIntegrationServer.sh script might
resemble the following example:

Chapter 25. Text Translator Reference 637


java
-Djavax.xml.parsers.SAXParserFactory=org.apache.xerces.jaxp.SAXParserFactoryImpl
-Djavax.xml.parsers.DocumentBuilderFactory=org.apache.xerces.jaxp.DocumentBuilde
rFactoryImpl com.yantra.integration.adapter.IntegrationAdapter TextTranslatorJMS

638 Sterling Selling and Fulfillment Foundation: Application Platform Configuration Guide
Chapter 26. Document Types
This chapter provides a reference for the different document types used by Sterling
Selling and Fulfillment FoundationSterling Application Platform.
Table 492. Document Types
Document Type Number Description
Order
Sales Order 0001 This document type is used to sell items or services,
either from business to business or business to
customer.
Planned Order 0002 This document type is used to plan an order that takes
place in the future.
Return Order 0003 This document type is used for returning items to the
seller.
Template Order 0004 This document type is used to create a template that
future orders can be modeled from.
Purchase Order 0005 This document type is used by a business to purchase
items or services from another business.
Transfer Order 0006 This document type is used to transfer items from one
organization to another (for example, a warehouse to a
distribution center, a warehouse to another warehouse,
a distribution center to a store).
Master Order 0007 This document type is used to sell items that ship in a
timed sequence, either from business to business or
business to customer.
Quote 0015 This document type is used to provide quotes for a
sales opportunity.
Load
Load 1001 This document type is used for a delivery plan which
consolidates multiple shipments into a single delivery.
General
General 2001 This document type is used for transactions and
services that do not fall under any other document
types.
Putaway 2002 This document type is used for transactions and
services that are used for the putaway related
processes (to specify the location where the products
coming into the warehouse would be putaway).
Layout 2003 This document type is used for transactions and
services that are used for configuring the warehouse
layout and related processes.
Inventory 2004 This document type is used for transactions and
services that are used for inventory tracking,
maintenance, and related processes.
Trailer 2005 This document type is used for transactions and
services that are used for the trailer loading and
unloading related processes.

© Copyright IBM Corp. 1999, 2011 639


Table 492. Document Types (continued)
Document Type Number Description
Task 2006 This document type is used for transactions and
services that plan all tasks that need to be done within
a warehouse.
Move Request 2007 This document type is used for transactions and
services that describe how products should be moved
from one location to another within a warehouse.
Manifest 2008 This document type is used for transactions and
services that relate to the manifest process, and
provide the carrier that describes what is in the
shipment.
Over Pack 2009 This document type is used for transactions and
services that relate to the overpacking process, which
involves packing one or more outbound containers
into another outbound container.
Count
Count 3001 This document type is used for transactions and
services that relate to performing a physical count of
inventory in the warehouse.
Container
Container 5001 This document type is used for transactions and
services that relate to containers used to pack
outbound goods.
Wave
Outbound Picking 4001 This document type is used for transactions and
services that relate to the outbound picking process.
Work Order
Work Order 7001 This document type is used in two different contexts:
v WMS: Tasks that need to be done in the warehouse,
typically against items (tagging, kitting, etc.)
v DOM: When a Provided Service is ordered, a Work
Order gets created, typically for tasks like
installation and repairs.
Opportunity
Opportunity 0020 This document type is used to provide sales
opportunities for customers.

640 Sterling Selling and Fulfillment Foundation: Application Platform Configuration Guide
Chapter 27. Condition Builder Attributes
Condition Builder Attributes
Statements in the condition builder are built using attributes that are defined
throughout the Applications ManagerConfigurator.

These attributes are grouped as follows:

Sales Order
v Order fulfillment
v Order negotiation
v Outbound shipment
v Receipt

Planned Order
v Planed order execution
v Planned order negotiation

Return Order
v Reverse logistics
v Return shipment
v Return receipt

Template Order
v Template order

Purchase Order
v Purchase order execution
v Purchase order negotiation
v Inbound shipment
v Purchase order receipt

Transfer Order
v Transfer order execution
v Transfer order delivery
v Transfer order receipt

Master Order
v Master order fulfillment

Quote
v Quote fulfillment

Load
v Load execution

© Copyright IBM Corp. 1999, 2011 641


General
v General
v WMS putaway
v WMS layout definition
v WMS inventory
v Trailer loading
v Task execution
v Move request execution
v Manifesting
v Over pack build

Count
v Count execution

Container
v Pack process

Wave
v Outbound picking

Work Order
v VAS process

Opportunity
v Opportunity fulfillment

Item-Based Allocation (IBA)


v Item-based allocation (IBA) order

Sales Order

Order Fulfillment
The Condition Builder attributes for Order Fulfillment, Order Execution, Quote
Fulfillment, Transfer Order Execution, and Template Order are identical.
Table 493. Order Fulfillment Condition Builder Attributes
Attribute Description
Order Attributes
Condition Variable 1 A variable that can be used for condition building. This is an
existing field in the YFS_ORDER_LINE database table, and
can be used to create conditions without extending the
database.
Condition Variable 2 A variable that can be used for condition building. This is an
existing field in the YFS_ORDER_LINE database table, and
can be used to create conditions without extending the
database.
Delivery Method The delivery method of the order (shipment, pickup or
delivery).

642 Sterling Selling and Fulfillment Foundation: Application Platform Configuration Guide
Table 493. Order Fulfillment Condition Builder Attributes (continued)
Attribute Description
Disposition Code The disposition code of the item. This field is only applicable
for Reverse Logistics and Supply Collaboration.
Line Type The type of the order line. Sterling Selling and Fulfillment
Foundation has no application logic associated with the order
line type. This field can be set up as per your business
practices.
Order Type The type of the order. Sterling Selling and Fulfillment
Foundation has no application logic associated with the order
type. This field can be set up as per your business practices.
Payment Status The payment status of the order.
Sale Voided The flag indicating whether the order is voided.
Transaction ID The ID of the last transaction that was run on the order.
Participant Attributes
Bill To ID The ID of the bill to address for the order.
Buyer Organization Code The code of the organization that is buying the goods or
services.
Enterprise Code The code of the enterprise on the order.
Receiving Node The node that receives the shipment for the order.
Seller Organization Code The code of the organization that is selling the goods or
services.
Ship Node The node that ships the shipment for the order.
Ship Node Interface Type The interface type of the ship node on the order (External
Application, Console, Sterling WMS, or WMS 6.2).
Ship To ID The ID of the ship to address for the order.
Supplier Code The code of the supplier for the order.
Item Attributes
Item ID The ID of the item on the order line.
Item Group Code The group code of the service item. For example, if the
service is a provided service item, then the item group code
is PS.
Product Line The product line of the item on the order line.
Sourcing Attributes
Fulfillment Type The fulfillment type of the order.
Intentional Backorder The flag indicating whether the order was intentionally
dropped into backordered status at order creation.
Is Firm Predefined Node The flag indicating whether the node on the order is a firm
predefined node.
Order Sourcing The order sourcing classification of the order.
Classification
Reservation Mandatory The flag indicating whether the reservation is mandatory.
Related Order Attributes
Chain Type The chain type of the order.
Is Chained Line The flag indicating whether the order line is chained with
another order line.

Chapter 27. Condition Builder Attributes 643


Table 493. Order Fulfillment Condition Builder Attributes (continued)
Attribute Description
Is Derived Line The flag indicating whether the order line is derived from
another order line.
Order Purpose The purpose of the order. If this is an exchange order, this
field is set to EXCHANGE.
{Enter Your Own A customizable condition builder attribute. For more
Attribute} information about customizing this field, see the Sterling
Selling and Fulfillment Foundation: Extending the Condition
Builder.

This field is limited only to unexposed key attributes that are


pre-defined by Sterling Selling and Fulfillment Foundation as
opposed to any XML attribute that you can enter.

Order Negotiation
The Condition Builder attributes for Order Negotiation and Planned Order
Negotiation are identical.
Table 494. Order Negotiation Condition Builder Attributes
Attribute Description
Enterprise Code The code of the enterprise on the order.
Initiator Organization The code of the organization that initiates the negotiation.
Code
Negotiator Organization The code of the organization that can accept, counter-offer, or
Code reject the initiator's offer.
Negotiation Pipeline Key The key of the negotiation pipeline this order is going
through.
Negotiation Number The negotiation number of this order.
Negotiation Rule Key The key of the negotiation rule for this order.
Header Entity The entity for which the negotiation was initiated. Currently,
the only applicable entity is Order.
Negotiation Status The status of the negotiation for this order.
Document Type The document type for this order. Typical value is Sales
Order.
Freight Terms The freight terms for this order.
Payment Terms The payment terms for this order.
{Enter Your Own A customizable condition builder attribute. For more
Attribute} information about customizing this field, see the Sterling
Selling and Fulfillment Foundation: Extending the Condition
Builder.

This field is limited only to unexposed key attributes that are


pre-defined by Sterling Selling and Fulfillment Foundation as
opposed to any XML attribute that you can enter.

644 Sterling Selling and Fulfillment Foundation: Application Platform Configuration Guide
Outbound Shipment
The condition builder attributes for Outbound Shipment, Inbound Shipment,
Transfer Order Delivery, and Return Shipment are identical.
Table 495. Outbound Shipment Condition Builder Attributes
Attribute Description
Enterprise Code The code of the enterprise on the outbound shipment.
Buyer Organization Code The code of the organization that is buying the goods or
services.
Seller Organization Code The code of the organization that is selling the goods or
services.
Ship Node The node that ships this shipment.
Ship Node Interface Type The interface type of the ship node on the order (External
Application, Console, Sterling WMS, or WMS 6.2).
Receiving Node The node that receives this shipment.
Ship Mode The shipment mode that is used for the shipment. For
example, Parcel, Truck Load, Less-Than Truck Load.
Freight Terms The freight terms for this shipment.
Carrier Type The shipment's carrier type for this shipment.
Hazardous Materials Flag The flag indicating whether these materials are hazardous.
ESP Check Required The flag indicating whether an Economic Shipping
Parameters check is required at shipment consolidation time.
Is Appointment Required The flag indicating whether an appointment is required for a
service execution.
Routing Guide Maintained The flag indicating whether a routing guide is maintained for
this shipment.
Carrier The carrier for the shipment.
Real-time Integration with The flag indicating whether the node this shipment is
WMS 6.2 shipping from is integrating with the Sterling Warehouse
Management System. Setting this field to N means that you
are integrating with WMS 6.2, or any other warehouse
management system.
Manually Entered The flag indicating whether or not the shipment was entered
through the Console.
Delivery Code The code of the entity that pays for the transportation costs.
Country/Region The country or region that the shipment is being shipped to.
Delivery Method The delivery method of the shipment (shipment, pickup or
delivery).
Is Serial Requested The flag indicating whether the shipment has any line with a
specific serial number passed. If that is the case, a different
outbound shipment process can be selected in the pipeline.
Is Provided Service The flag indicating whether the shipment has an associated
provided service item.
Shipment Type Indicates a set of shipments that are of the same nature.

Chapter 27. Condition Builder Attributes 645


Table 495. Outbound Shipment Condition Builder Attributes (continued)
Attribute Description
{Enter Your Own A customizable condition builder attribute. For more
Attribute} information about customizing this field, see the Sterling
Selling and Fulfillment Foundation: Extending the Condition
Builder.

This field is limited only to unexposed key attributes that are


pre-defined by Sterling Selling and Fulfillment Foundation as
opposed to any XML attribute that you can enter.

Receipt
The Receipt condition builder attributes are identical to the Return Receipt
attributes.

Planned Order

Planned Order Execution


The Planned Order Execution condition builder attributes are identical to the Order
Fulfillment attributes.

Planned Order Negotiation


The Planned Order Negotiation condition builder attributes are identical to the
Order Negotiation attributes.

Return Order

Reverse Logistics
Table 496. Return Fulfillment Condition Builder Attributes
Attribute Description
Order Attributes
Condition Variable 1 A variable that can be used for condition building. This is an
existing field in the YFS_ORDER_LINE database table, and
can be used to create conditions without extending the
database.
Condition Variable 2 A variable that can be used for condition building. This is an
existing field in the YFS_ORDER_LINE database table, and
can be used to create conditions without extending the
database.
Delivery Method The delivery method of the return (shipment, pickup or
delivery).
Disposition Code The disposition code of the item.
Line Type The type of the return line. Sterling Selling and Fulfillment
Foundation has no application logic associated with the
return line type. This field can be set up as per your business
practices.

646 Sterling Selling and Fulfillment Foundation: Application Platform Configuration Guide
Table 496. Return Fulfillment Condition Builder Attributes (continued)
Attribute Description
Order Type The type of the return. Sterling Selling and Fulfillment
Foundation has no application logic associated with the
return type. This field can be set up as per your business
practices.
Payment Status The payment status of the return.
Sale Voided The flag indicating whether the return is voided.
Transaction ID The ID of the last transaction that was run on the return.
Participant Attributes
Bill To ID The ID of the bill to address for the return.
Buyer Organization Code The code of the organization that is buying the goods or
services.
Enterprise Code The code of the enterprise on the return.
Receiving Node The node that receives the shipment for the return.
Seller Organization Code The code of the organization that is selling the goods or
services.
Ship Node The node that be ships the shipment for the return.
Ship Node Interface Type The interface type of the ship node on the return (External
Application, Console, Sterling WMS, or WMS 6.2).
Ship To ID The ID of the ship to address for the return.
Supplier Code The code of the supplier for the return.
Item Attributes
Item ID The ID of the item on the return line.
Item Group Code The group code of the service item. For example, if the
service is a provided service item, then the item group code
is PS.
Product Line The product line of the item on the return line.
Sourcing Attributes
Fulfillment Type The fulfillment type of the return.
Intentional Backorder The flag indicating whether the return was intentionally
dropped into backordered status at return creation.
Is Firm Predefined Node The flag indicating whether the node on the return is a firm
predefined node.
Order Sourcing The order sourcing classification of the return.
Classification
Reservation Mandatory The flag indicating whether the reservation is mandatory.
Related Order Attributes
Chain Type The chain type of the return.
Is Chained Line The flag indicating whether the return line is chained with
another return line.
Is Derived Line The flag indicating whether the return line is derived from
another return line.
Order Purpose This field is only applicable to sales orders.

Chapter 27. Condition Builder Attributes 647


Table 496. Return Fulfillment Condition Builder Attributes (continued)
Attribute Description
{Enter Your Own A customizable condition builder attribute. For more
Attribute} information about customizing this field, see the Sterling
Selling and Fulfillment Foundation: Extending the Condition
Builder.

This field is limited only to unexposed key attributes that are


pre-defined by Sterling Selling and Fulfillment Foundation as
opposed to any XML attribute that you can enter.

Return Shipment
The Return Shipment condition builder attributes are identical to the Outbound
Shipment attributes.

Return Receipt
The Condition Builder attributes for Receipt, Purchase Order Receipt, Return
Receipt, Transfer Order Receipt are identical.
Table 497. Return Receipt Condition Builder Attributes
Attribute Description
Document Type The document type on the receipt. Typical value is Return
Order.
Enterprise Code The code of the enterprise that owns the receipt.
Seller Organization Code The code of the organization that is selling the goods or
services.
Ship Node The node where the shipment was shipped out of.
Buyer Organization Code The code of the organization that is buying the goods or
services.
Receiving Node The node where the shipment was received.
Receiving Node Interface The interface type of the receiving node on the order
Type (External Application, Console, Sterling WMS, or WMS 6.2).
Ship Mode The shipment mode that is used for the shipment. For
example, Parcel, Truck Load, Less-Than Truck Load.
Freight Terms The freight terms on the receipt.
Carrier Type The carrier type on the receipt.
Is Hazardous Material The flag indicating whether there are hazardous materials
that are being received.
Is Inspection Pending The flag indicating whether there is an inspection pending on
this return.
Is Receiving Node The flag indicating whether the receiving node is integrating
Integrated Real Time with WMS 6.2, or with another WMS system.

648 Sterling Selling and Fulfillment Foundation: Application Platform Configuration Guide
Table 497. Return Receipt Condition Builder Attributes (continued)
Attribute Description
{Enter Your Own A customizable condition builder attribute. For more
Attribute} information about customizing this field, see the Sterling
Selling and Fulfillment Foundation: Extending the Condition
Builder.

This field is limited only to unexposed key attributes that are


pre-defined by Sterling Selling and Fulfillment Foundation as
opposed to any XML attribute that you can enter.

Template Order
The Template Order condition builder attributes are identical to the Order
Fulfillment attributes.

Purchase Order

Purchase Order Execution


Table 498. Purchase Order Execution Condition Builder Attributes
Attribute Description
Order Attributes
Condition Variable 1 A variable that can be used for condition building. This is an
existing field in the YFS_ORDER_LINE database table, and
can be used to create conditions without extending the
database.
Condition Variable 2 A variable that can be used for condition building. This is an
existing field in the YFS_ORDER_LINE database table, and
can be used to create conditions without extending the
database.
Delivery Method The delivery method of the inbound order (shipment, pickup
or delivery).
Disposition Code The disposition code of the item.
Line Type The type of the inbound order line. Sterling Selling and
Fulfillment Foundation has no application logic associated
with the inbound order line type. This field can be set up as
per your business practices.
Order Type The type of the inbound order. Sterling Selling and
Fulfillment Foundation has no application logic associated
with the inbound order type. This field can be set up as per
your business practices.
Payment Status The payment status of the inbound order.
Sale Voided The flag indicating whether the inbound order is voided.
Transaction ID The ID of the last transaction that was run on the inbound
order.
Participant Attributes
Bill To ID The ID of the bill to address for the inbound order.
Buyer Organization Code The code of the organization that is buying the goods or
services.

Chapter 27. Condition Builder Attributes 649


Table 498. Purchase Order Execution Condition Builder Attributes (continued)
Attribute Description
Enterprise Code The code of the enterprise on the inbound order.
Receiving Node The node that receives the shipment for the inbound order.
Seller Organization Code The code of the organization that is selling the goods or
services.
Ship Node The node that ships the shipment for the inbound order.
Ship Node Interface Type The interface type of the ship node on the inbound order
(External Application, Console, Sterling WMS, or WMS 6.2).
Ship To ID The ID of the ship to address for the inbound order.
Supplier Code The code of the supplier for the inbound order.
Item Attributes
Item ID The ID of the item on the inbound order line.
Item Group Code The group code of the service item. For example, if the
service is a provided service item, then the item group code
is PS.
Product Line The product line of the item on the inbound order line.
Sourcing Attributes
Fulfillment Type The fulfillment type of the inbound order.
Intentional Backorder The flag indicating whether the inbound order was
intentionally dropped into backordered status at inbound
order creation.
Is Firm Predefined Node The flag indicating whether the node on the inbound order is
a firm predefined node.
Order Sourcing The order sourcing classification of the inbound order.
Classification
Reservation Mandatory The flag indicating whether the reservation is mandatory.
Related Order Attributes
Chain Type The chain type of the inbound order.
Is Chained Line The flag indicating whether the inbound order line is chained
with another inbound order line.
Is Derived Line The flag indicating whether the inbound order line is derived
from another inbound order line.
Order Purpose This field is only applicable to sales orders.
{Enter Your Own A customizable condition builder attribute. For more
Attribute} information about customizing this field, see the Sterling
Selling and Fulfillment Foundation: Extending the Condition
Builder.

This field is limited only to unexposed key attributes that are


pre-defined by Sterling Selling and Fulfillment Foundation as
opposed to any XML attribute that you can enter.

Purchase Order Negotiation


Table 499. Purchase Order Negotiation Condition Builder Attributes
Attribute Description
Enterprise Code The code of the enterprise on the inbound order.

650 Sterling Selling and Fulfillment Foundation: Application Platform Configuration Guide
Table 499. Purchase Order Negotiation Condition Builder Attributes (continued)
Attribute Description
Initiator Organization The code of the organization that initiates the negotiation.
Code
Negotiator Organization The code of the organization that can accept, counter-offer, or
Code reject the initiator's offer.
Negotiation Pipeline Key The key of the negotiation pipeline this inbound order is
going through.
Negotiation Number The negotiation number of this inbound order.
Negotiation Rule Key The key of the negotiation rule for this inbound order.
Header Entity The entity for which the negotiation was initiated. Currently,
the only applicable entity is Order.
Negotiation Status The status of the negotiation for this inbound order.
Document Type The document type for this inbound order. Typical value is
Purchase Order.
Freight Terms The freight terms for this inbound order.
Payment Terms The payment terms for this inbound order.
{Enter Your Own A customizable condition builder attribute. For more
Attribute} information about customizing this field, see the Sterling
Selling and Fulfillment Foundation: Extending the Condition
Builder.

This field is limited only to unexposed key attributes that are


pre-defined by Sterling Selling and Fulfillment Foundation as
opposed to any XML attribute that you can enter.

Inbound Shipment
The Inbound Shipment condition builder attributes are identical to the Outbound
Shipment attributes.

Purchase Order Receipt


The Purchase Order Receipt condition builder attributes are identical to the Return
Receipt attributes.

Transfer Order

Transfer Order Execution


The Transfer Order Execution condition builder attributes are identical to the Order
Fulfillment attributes.

Transfer Order Delivery


The Transfer Order Delivery condition builder attributes are identical to the
Outbound Shipment attributes.

Chapter 27. Condition Builder Attributes 651


Transfer Order Receipt
The Transfer Order Receipt condition builder attributes are identical to the Return
Receipt attributes.

Master Order Fulfillment


Table 500. Master Order Fulfillment Condition Builder Attributes
Attribute Description
Master Order Attributes
Condition Variable 1 A variable that can be used for condition building. This is an
existing field in the YFS_ORDER_LINE database table, and
can be used to create conditions without extending the
database.
Condition Variable 2 A variable that can be used for condition building. This is an
existing field in the YFS_ORDER_LINE database table, and
can be used to create conditions without extending the
database.
Delivery Method The delivery method of the order (shipment, pickup or
delivery).
Disposition Code The disposition code of the item. This field is only applicable
for Reverse Logistics and Supply Collaboration.
Line Type The type of the order line. Sterling Selling and Fulfillment
Foundation has no application logic associated with the order
line type. This field can be set up as per your business
practices.
Order Type The type of the order. Sterling Selling and Fulfillment
Foundation has no application logic associated with the order
type. This field can be set up as per your business practices.
Payment Status The payment status of the order.
Sale Voided The flag indicating whether the order is voided.
Transaction ID The ID of the last transaction that was run on the order.
Participant Attributes
Bill To ID The ID of the bill to address for the order.
Buyer Organization Code The code of the organization that is buying the goods or
services.
Enterprise Code The code of the enterprise on the order.
Receiving Node The node that receives the shipment for the order.
Seller Organization Code The code of the organization that is selling the goods or
services.
Ship Node The node that ships the shipment for the order.
Ship Node Interface Type The interface type of the ship node on the order (External
Application, Console, Sterling WMS, or WMS 6.2).
Ship To ID The ID of the ship to address for the order.
Supplier Code The code of the supplier for the order.
Item Attributes
Item ID The ID of the item on the order line.

652 Sterling Selling and Fulfillment Foundation: Application Platform Configuration Guide
Table 500. Master Order Fulfillment Condition Builder Attributes (continued)
Attribute Description
Item Group Code The group code of the service item. For example, if the
service is a provided service item, then the item group code
is PS.
Product Line The product line of the item on the order line.
Sourcing Attributes
Fulfillment Type The fulfillment type of the order.
Intentional Backorder The flag indicating whether the order was intentionally
dropped into backordered status at order creation.
Is Firm Predefined Node The flag indicating whether the node on the order is a firm
predefined node.
Order Sourcing The order sourcing classification of the order.
Classification
Reservation Mandatory The flag indicating whether the reservation is mandatory.
Related Master Order Attributes
Chain Type The chain type of the order.
Is Chained Line The flag indicating whether the order line is chained with
another order line.
Is Derived Line The flag indicating whether the order line is derived from
another order line.
Order Purpose The purpose of the order. If this is an exchange order, this
field is set to EXCHANGE.
{Enter Your Own A customizable condition builder attribute. For more
Attribute} information about customizing this field, see the Sterling
Selling and Fulfillment Foundation: Extending the Condition
Builder.

This field is limited only to unexposed key attributes that are


pre-defined by Sterling Selling and Fulfillment Foundation as
opposed to any XML attribute that you can enter.

Quote Fulfillment
The Quote Fulfillment condition builder attributes are identical to the Order
Fulfillment condition builder attributes.

Load Execution
Table 501. Load Execution Condition Builder Attributes
Attribute Description
Load Type The type of the load document.
Enterprise Code The code of the enterprise on the load document.
Owner Organization Code The code of the organization that owns the load document.
Carrier The carrier used to carry the load.
Carrier Service Code The code of the carrier service used to carry the load.
Ship Mode The shipment mode that is used for the shipment. For
example, Parcel, Truck Load, Less-Than Truck Load.

Chapter 27. Condition Builder Attributes 653


Table 501. Load Execution Condition Builder Attributes (continued)
Attribute Description
Hazardous Material The flag indicating whether hazardous materials are being
carried in this load.
Origin Node The node where the load originated from.
Destination Node The node where the load is being shipped to.
Multiple Load Stop The flag indicating whether or not a shipment goes through
multiple stops to load or unload additional shipments.
{Enter Your Own A customizable condition builder attribute. For more
Attribute} information about customizing this field, see the Sterling
Selling and Fulfillment Foundation: Extending the Condition
Builder.

This field is limited only to unexposed key attributes that are


pre-defined by Sterling Selling and Fulfillment Foundation as
opposed to any XML attribute that you can enter.

General
The following Condition Builder attributes are identical to those for WMS Putaway,
WMS Layout Definition, WMS Inventory, Trailer Loading, Task Execution, Move
Request Execution, Manifesting, and Over Pack Build.
Table 502. General Condition Builder Attributes
Attribute Description
Enterprise Code The code of the enterprise.
Organization Code The code of the organization.
Provider Organization The code of the organization that provides the service.
Code
Ship Node The node that ships this shipment.
Supply Type The supply type associated with the inventory status. Typical
values are Onhand, Held, etc.
Item ID The ID of the item on the order line.
Unit Of Measure The unit of measure of the item.
Product Class The inventory classification of an item based on the product's
characteristics. Typical values are FQ - First Quality, SQ -
Second Quality, etc.
Inventory Status The inventory sub classification of the product, based on the
results of the inventory control processes within the
warehouse. Typical values are Good - Good Inventory,
Damaged - Damaged inventory, Qlty-Hold - Quality Hold,
etc.
Adjustment Type The type of inventory adjustment. Typical values are Cycle
Count, Receipt, Picking, Packing, Shipping, etc.
Alert Type The type of alert raised when an exception occurs.
Carrier The carrier used to carry the shipment.
Task Type The Task Type applicable to a task. Typical values are Receipt,
QC, Count, Replenishment, Retrieval, Putaway, VAS, Pack,
Shipping, and Picking.

654 Sterling Selling and Fulfillment Foundation: Application Platform Configuration Guide
Table 502. General Condition Builder Attributes (continued)
Attribute Description
Assigned To User ID The ID of the user to whom the task is assigned.
Task Status The Task Status within the pipeline that the task travels
through. Typical values are Open, Suggested, In Progress,
Held, Completed, Canceled, etc.
Document Type The document type for this order. Typical values are Sales
Order, Purchase Order, Transfer Order, and Return Order.
SC UI Client Version The Rich Client Platform application version number.
Activity Group ID The identifier for the activity group.
{Enter Your Own A customizable condition builder attribute. For more
Attribute} information about customizing this field, see the Sterling
Selling and Fulfillment Foundation: Extending the Condition
Builder.

This field is limited only to unexposed key attributes that are


pre-defined by Sterling Selling and Fulfillment
FoundationSterling Application Platform as opposed to any
XML attribute that you can enter.

WMS Putaway
The WMS Putaway condition builder attributes are identical to the General
attributes.

WMS Layout Definition


The WMS Layout Definition condition builder attributes are identical to the
General attributes.

WMS Inventory
The WMS Layout Inventory condition builder attributes are identical to the
General attributes.

Trailer Loading
The Trailer Loading condition builder attributes are identical to the General
attributes.

Task Execution
The Task Execution condition builder attributes are identical to the General
attributes.

Move Request Execution


The Move Request Execution condition builder attributes are identical to the
General attributes.

Chapter 27. Condition Builder Attributes 655


Manifesting
The Manifesting condition builder attributes are identical to the General attributes.

Over Pack Build


The Over Pack Build condition builder attributes are identical to the General
attributes.

Count Execution
Table 503. Count Execution Condition Builder Attributes
Attribute Description
Enterprise Code The code of the enterprise for which the count request is
created.
Request Type The type of count requested.
Count Program Name The name of the count program for which the count request
is created.
Node Key The node where the count request is processed.
Zone ID The zone where the count must be performed.
Location Size Code The capacity of the location where the count must be
performed.
Is LPN Level The flag indicating whether the count tasks are be performed
at the LPN level.
Is Case Level The flag indicating whether the count tasks are be performed
at the case level.
Is Pallet Level The flag indicating whether the count tasks are be performed
at the pallet level.
Is Item Level The flag indicating whether the count tasks are be performed
at the item level.
Is Resolvable The flag indicating whether variance can be resolved for this
count result.
Product Class The inventory classification of an item based on the product's
characteristics. Typical values are FQ - First Quality, SQ -
Second Quality, etc.
Unit Of Measure The unit of measure of the item that was counted.
Item Classification 1 The first item classification attribute for determining the
Count Strategy.
Item Classification 2 The second item classification attribute for determining the
Count Strategy.
Item Classification 3 The third item classification attribute for determining the
Count Strategy.
Has Variance The flag indicating whether the count request has a variance.
Has Absolute Variance The flag indicating whether the count request has an absolute
variance.
Variance Quantity The difference in quantity (+/-) between the count result and
system quantity.

656 Sterling Selling and Fulfillment Foundation: Application Platform Configuration Guide
Table 503. Count Execution Condition Builder Attributes (continued)
Attribute Description
Absolute Variance The absolute difference between the count result and system
Quantity quantity.
Variance Value The difference in cost/value (+/-) between the count result
and system quantity.
Absolute Variance Value The absolute difference in cost/value between the count
result and system quantity.
Has Variance With The flag indicating whether the variance between the current
Previous Count count result and previous count results displays.
{Enter Your Own A customizable condition builder attribute. For more
Attribute} information about customizing this field, see the Sterling
Selling and Fulfillment Foundation: Extending the Condition
Builder.

This field is limited only to unexposed key attributes that are


pre-defined by Sterling Selling and Fulfillment Foundation as
opposed to any XML attribute that you can enter.

Pack Process
Table 504. Pack Process Condition Builder Attributes
Attribute Description
Node Attributes
Ship Node The node that ships this shipment.
Receiving Node The node that receives this shipment.
Ship from Ship Node The interface type of the ship node from which the shipment
Interface Type is shipped (External Application, Console, Sterling WMS, or
WMS 6.2).
Ship from Supplier Code The code of the supplier that is shipping the shipment.
Ship from DCM The flag indicating whether the node from which the
Integration Real Time shipment is shipped uses WMS 6.2.
Ship from Country/Region The code of the country or region from which the shipment is
being shipped.
Ship to Ship Node The interface type of the ship node to which the shipment is
Interface Type shipped (External Application, Console, Sterling WMS, or
WMS 6.2).
Ship to Supplier Code The code of the supplier to whom the shipment is being
shipped.
Ship to DCM Integration The flag indicating whether the node to which the shipment
Real Time is shipped uses WMS 6.2.
Ship to Country/Region The code of the country or region to which the shipment is
being shipped.
Organization Attributes
Enterprise Code The code of the enterprise that owns the shipment.
Buyer Organization Code The code of the organization that is buying the goods or
services.
Seller Organization Code The code of the organization that is selling the goods or
services.

Chapter 27. Condition Builder Attributes 657


Table 504. Pack Process Condition Builder Attributes (continued)
Attribute Description
Shipment Attributes
Ship Mode The shipment mode that is used for the shipment. For
example, Parcel, Truck Load, Less-Than Truck Load.
Carrier The carrier used to carry the shipment.
Freight Terms The freight terms of the shipment.
Delivery Code The code of the entity that pays for the transportation costs.
Pack And Hold The flag indicating whether the shipment needs to be packed
and put away for retrieval at a later date.
Shipment Container Count The number of containers in the shipment.
Shipment Containerized The flag indicating the containerization state of the shipment.
Flag The values are: 01 - not containerized, 02 - containerization in
progress and 03 - containerization completed.
Container Attributes
Is Shipment Container The flag indicating whether the container belongs to a
shipment.
Is Load Container The flag indicating whether the container is part of a load.
Is Inventory Pallet The flag indicating whether the container is an inventory
pallet.
Is Converted From LPN The flag indicating whether the inventory container has been
converted to a shipment container.
Is Serial Capture Pending The flag indicating whether the serial capture is pending for
the container.
Is Pack Process Complete The flag indicating whether any more pack activities are
pending for the container.
Is Product Placing The flag indicating whether placing the product into the
Complete container according to the system's suggestion has been
completed.
Requires VAS The flag indicating whether the container requires value
added services.
Has Child Containers The flag indicating whether a container is a parent container
having other containers.
Number of Items The number of items contained in the container.
Container Type The attribute that specifies whether a shipment container is a
case or pallet.
{Enter Your Own A customizable condition builder attribute. For more
Attribute} information about customizing this field, see the Sterling
Selling and Fulfillment Foundation: Extending the Condition
Builder.

This field is limited only to unexposed key attributes that are


pre-defined by Sterling Selling and Fulfillment Foundation as
opposed to any XML attribute that you can enter.

658 Sterling Selling and Fulfillment Foundation: Application Platform Configuration Guide
Outbound Picking
Table 505. Outbound Picking Condition Builder Attributes
Attribute Description
Activity Group ID The identifier for the activity group.
Shipment Group ID The identifier for the shipment group.
{Enter Your Own A customizable condition builder attribute. For more
Attribute} information about customizing this field, see the Sterling
Selling and Fulfillment Foundation: Extending the Condition
Builder.

This field is limited only to unexposed key attributes that are


pre-defined by Sterling Selling and Fulfillment Foundation as
opposed to any XML attribute that you can enter.

VAS Process
Table 506. VAS Process Condition Builder Attributes
Attribute Description
Enterprise Code The code of the enterprise that owns the item or license plate.
Provider Organization The code of the organization that provides the service.
Code
Node Key The node, where the work orders are run.
Purpose The purpose for the work order (ORDER / STOCK / SHIP)
Service Item Group Code The code of the service item group (KIT/DKIT/COMPL/
INVC/PS)
Service Item ID The identifier for the service Item.
Segment Type The type of segment. This may be MTO (made to order) or
MTC (made to customer).
Segment The segment to which the inventory involved in the work
order belongs.
Has Components The flag indicating whether the work order has component
items.
Status The status of the work order.
Pre Call Status The flag indicating the status of the pre-call process.
Appt Status The status of the appointment. This is in sync with the
service order line. The appointment status is used in case of
provided service work order.
Number Of Attempts The number of attempts made to run the work order.
Number Of Hours until The number of hours left before the appointment for the
Appointment service item.
Number Of Hours After The number of hours after the last appointment for the
Appointment service item.
Number Of Hours After The number of hours after the last attempt to run the service.
Last Execution
Last Execution Success The flag indicating whether the last attempt to run the service
was successful or not.

Chapter 27. Condition Builder Attributes 659


Table 506. VAS Process Condition Builder Attributes (continued)
Attribute Description
Open Work Order Flag The flag indicating whether the execution of the work order
has ended or not.
{Enter Your Own A customizable condition builder attribute. For more
Attribute} information about customizing this field, see the Sterling
Selling and Fulfillment Foundation: Extending the Condition
Builder.

This field is limited only to unexposed key attributes that are


pre-defined by Sterling Selling and Fulfillment Foundation as
opposed to any XML attribute that you can enter.

Opportunity Fulfillment
Table 507. Opportunity Fulfillment Condition Builder Attributes
Attribute Description
Opportunity Attributes
Opportunity ID The ID of the opportunity.
Opportunity Name The name of the opportunity.
Status The status of the opportunity.
Currency Value The currency value of the opportunity.
Probable Success Rate The likelihood of whether an order will be created from the
opportunity.
Participant Attributes
Bill To ID The ID of the bill to address for the opportunity.
Buyer Organization Code The code of the organization that may buy the goods or
services.
Enterprise Code The code of the enterprise for the opportunity.
Owner User ID The user ID of the opportunity owner.
Co-Owner User ID The user ID of the opportunity co-owner.
Customer Contact ID The ID of the customer contact for the opportunity.
Team Code The code of the team that manages the opportunity.
{Enter Your Own A customizable condition builder attribute. For more
Attribute} information about customizing this field, see the Sterling
Selling and Fulfillment Foundation: Extending the Condition
Builder.

This field is limited only to unexposed key attributes that are


pre-defined by Sterling Selling and Fulfillment Foundation as
opposed to any XML attribute that you can enter.

Item-Based Allocation (IBA) Order


Table 508. IBA Attributes
Attribute Description
Order Attributes
Exchange Type The exchange type of the order.

660 Sterling Selling and Fulfillment Foundation: Application Platform Configuration Guide
Table 508. IBA Attributes (continued)
Attribute Description
Priority Code Customizable priority code of the order.
Priority Number The numeric priority code of the order.
Document Type The document type for this order. Typical value is 0001 (Sales
Order).
Order Type The order classification attribute. This field can be used for
reporting purposes or to build conditions for modeling your
business process. Sterling Selling and Fulfillment
FoundationSterling Application Platform has no default logic
based on this field.
Entry Type The channel through which this order was created.
Department Code Department code to which the order was placed.
Search Criteria 1 Customizable field for allowing searches.
Search Criteria 2 Customizable field for allowing searches.
Order Line
Line Type The line type can be used in process modeling for pipeline
determination or conditional processing.
Condition Variable 1 A user-defined variable that can be used for condition
building in process modeling.
Condition Variable 2 A user-defined variable that can be used for condition
building in process modeling.
Shipping Attributes
Level of Service The order or the line's level of service.
Ship To ID The ship-to identifier. If a customer definition representing
the buyer organization exists within Sterling Selling and
Fulfillment FoundationSterling Application Platform, the
ship-to ID can represent the Customer ID. Otherwise, the
ship-to ID can represent the PersonID of the ship-to address
or the receiving node of the order.
Carrier Service Code The code of the carrier service used to carry the load.
Participant Attributes
Enterprise Code The code of the enterprise on the order.
Buyer Organization Code The code of the organization that is buying the goods or
services.
Seller Organization Code The code of the organization that is selling the goods or
services.
Bill To ID The identifier of the customer to whom the order is being
billed.
{Enter Your Own A customizable condition builder attribute. For more
Attribute} information about customizing this field, see the Sterling
Selling and Fulfillment Foundation: Extending the Condition
Builder.

This field is limited only to unexposed key attributes that are


pre-defined by Sterling Selling and Fulfillment Foundation as
opposed to any XML attribute that you can enter.

Chapter 27. Condition Builder Attributes 661


662 Sterling Selling and Fulfillment Foundation: Application Platform Configuration Guide
Chapter 28. Configuring Change Project Management
Exporting Database Changes
Many users implement new features or database changes as separate projects. The
database changes can be implemented first on a staging or a testing environment,
which is a replica of the production environment, before implementing them on a
production environment, to minimize operational errors. The changes are exported
to the production environment when change project management is enabled in a
resource XML file, changeDataManagementRules.xml.

Database changes are stored in the table, YFS_ENTITY_CHANGE.

Database changes are published on the production environment based on the


project rules specified for each deployment. The agents, Change Data Export Agent
and Change Data Import Agent are used to publish the changes on the target
environment. The agents, Change Data Export Agent and Change Data Import
Agent are run at interval to publish the changes. For details on the agents, refer to
the Change Data Export Agent and Change Data Import Agent topics under the
section, Business Process Time-Triggered Transactions.

Note: For publishing the database changes on the target environment, ensure that
the target environment is a replica of the source environment to maintain the same
primary keys of the database across all deployments.

Note: Database changes of a specific enterprise cannot be exported separately;


changes of all enterprises are exported simultaneously.

Configuring Rules for Publishing Database Changes


For publishing the changes on the production environment, each installation or
deployment must define its own project rules:
v Export projects: Projects in a "Developer" environment must be exported to a
"Staging" environment. When projects are approved, they must be moved to the
"Production" environment.
v Maintain entity changes: Entity changes must be logged to send modified data
to another environment. The logging is turned off for "Production" environment.

The project rules are stored in a resource XML file called


changeDataManagementRules.xml. For example,
<ChangeDataManagementRules DeploymentName="STAGING">
<Rules>
<Rule Name="MaintainEntityChanges" Value="Y">
<TableTypeList>
<TableType Type="CONFIGURATION"/>
<TableType Type="MASTER"/>
</TableTypeList>
</Rule>
<Rule Name="EnableChangeProjectManagement" Value="Y"/>
<Rule Name="ChangeProjectIDPrefix" Value="ST"/>
<Rule Name="ExportProjects" Value="N"/>
<Rule Name="PreventTableImport" Value="Y">
<TableList
<Table Name="YFS_USER"/>

© Copyright IBM Corp. 1999, 2011 663


<Table Name="PLT_USER_UI_STATE"/>
</TableList>
</Rules>
</ChangeDataManagementRules>

Set the following rules in changeDataManagementRules.xml:


DeploymentName
Define the installation or deployment. For example, "Development",
"Staging".
MaintainEntityChanges
Set this rule to "Y" to track changes for the table types configured under
the rule.
EnableChangeProjectManagement:
Set this rule to "Y" to track changes through default project.
ChangeProjectIDPrefix
A prefix used to generate Project IDs. Specify a unique prefix for each
deployment. For example, ST for Staging, DV for development.
ExportChangeProjects
Set this rule to "Y" to export Change Project definitions to another
environment.
PreventTableImport
You can prevent certain tables from being imported as part of entity
transformation. Set this rule to "Y" to prevent import of tables specified
under the rule.

Note: Add the table, PLT_USER_UI_STATE in the list of tables to be


prevented from import under PreventTableImport rule when using Sterling
Business Center for making changes to entities such as items or price lists.

Entity Transformation

Configuration parameters differ for different environments. For example, the


configuration (URLs, IP addresses etc.) of a "Developer" environment is different
from that of a "Staging" environment. When data from one environment is
exported to another environment, the configuration also must be changed to suit
the target environment. For example, when data from "Staging" environment is
exported to "Production", the IP addresses for records must be changed to
10.10.20.81 from 10.10.20.80. This is called "Entity Transforms", which is defined for
an entity and is associated with a source-target pair deployment.

The entity transforms for export and import of records is defined and stored in a
resource XML file, entityTransforms.xml. For example:
<Transformations>
<Table Name="YFS_SUB_FLOW>
<Columns>
<Column Name="CONFIG_XML>
<Transform Match="t3://localhost:7001
Replace="${PROVIDER_URL}" XPath
="xml:/SubFlowConfig/Link/Properties/@ProviderURL">
</Column>
</Columns>
</Table>
</Transformations>

664 Sterling Selling and Fulfillment Foundation: Application Platform Configuration Guide
During export, configuration parameters of the source environment for an entity
are replaced with the configuration parameters of the target environment, which is
specified in entityTransforms.xml. The entityTransforms.xml is present in the
<INSTALL_DIR>/repository/xapi/template/merged/resource folder.

Properties to be Set Before Publishing Database Changes


The following properties must be set before publishing changes to the target
environment:

Properties to be set in customer_overrides.properties

The following properties must be set in customer_overrides.properties file before


the Change Data Export agent is run:
v yfs.ChangeDataPublisherExportDirectory
v yfs.ChangeDataPublisherWorkingDirectory
v yfs.ChangeDataPublisherFilePrefix

Properties to be set in sandbox.cfg

The following property must be set in sandbox.cfg after installation:

OVERRIDE_LOAD_DEFAULTS_PK_GEN

For details on the above properties, refer to the Properties Guide.

Chapter 28. Configuring Change Project Management 665


666 Sterling Selling and Fulfillment Foundation: Application Platform Configuration Guide
Notices
This information was developed for products and services offered in the U.S.A.

IBM may not offer the products, services, or features discussed in this document in
other countries. Consult your local IBM representative for information on the
products and services currently available in your area. Any reference to an IBM
product, program, or service is not intended to state or imply that only that IBM
product, program, or service may be used. Any functionally equivalent product,
program, or service that does not infringe any IBM intellectual property right may
be used instead. However, it is the user's responsibility to evaluate and verify the
operation of any non-IBM product, program, or service.

IBM may have patents or pending patent applications covering subject matter
described in this document. The furnishing of this document does not grant you
any license to these patents. You can send license inquiries, in writing, to:

IBM Director of Licensing

IBM Corporation

North Castle Drive

Armonk, NY 10504-1785

U.S.A.

For license inquiries regarding double-byte character set (DBCS) information,


contact the IBM Intellectual Property Department in your country or send
inquiries, in writing, to:

Intellectual Property Licensing

Legal and Intellectual Property Law

IBM Japan Ltd.

1623-14, Shimotsuruma, Yamato-shi

Kanagawa 242-8502 Japan

The following paragraph does not apply to the United Kingdom or any other
country where such provisions are inconsistent with local law:
INTERNATIONAL BUSINESS MACHINES CORPORATION PROVIDES THIS
PUBLICATION "AS IS" WITHOUT WARRANTY OF ANY KIND, EITHER
EXPRESS OR IMPLIED, INCLUDING, BUT NOT LIMITED TO, THE IMPLIED
WARRANTIES OF NON-INFRINGEMENT, MERCHANTABILITY OR FITNESS
FOR A PARTICULAR PURPOSE. Some states do not allow disclaimer of express or
implied warranties in certain transactions, therefore, this statement may not apply
to you.

This information could include technical inaccuracies or typographical errors.


Changes are periodically made to the information herein; these changes will be

© Copyright IBM Corp. 1999, 2011 667


incorporated in new editions of the publication. IBM may make improvements
and/or changes in the product(s) and/or the program(s) described in this
publication at any time without notice.

Any references in this information to non-IBM Web sites are provided for
convenience only and do not in any manner serve as an endorsement of those Web
sites. The materials at those Web sites are not part of the materials for this IBM
product and use of those Web sites is at your own risk.

IBM may use or distribute any of the information you supply in any way it
believes appropriate without incurring any obligation to you.

Licensees of this program who wish to have information about it for the purpose
of enabling: (i) the exchange of information between independently created
programs and other programs (including this one) and (ii) the mutual use of the
information which has been exchanged, should contact:

IBM Corporation

J46A/G4

555 Bailey Avenue

San Jose, CA 95141-1003

U.S.A.

Such information may be available, subject to appropriate terms and conditions,


including in some cases, payment of a fee.

The licensed program described in this document and all licensed material
available for it are provided by IBM under terms of the IBM Customer Agreement,
IBM International Program License Agreement or any equivalent agreement
between us.

Any performance data contained herein was determined in a controlled


environment. Therefore, the results obtained in other operating environments may
vary significantly. Some measurements may have been made on development-level
systems and there is no guarantee that these measurements will be the same on
generally available systems. Furthermore, some measurements may have been
estimated through extrapolation. Actual results may vary. Users of this document
should verify the applicable data for their specific environment.

Information concerning non-IBM products was obtained from the suppliers of


those products, their published announcements or other publicly available sources.
IBM has not tested those products and cannot confirm the accuracy of
performance, compatibility or any other claims related to non-IBM products.
Questions on the capabilities of non-IBM products should be addressed to the
suppliers of those products.

All statements regarding IBM's future direction or intent are subject to change or
withdrawal without notice, and represent goals and objectives only.

All IBM prices shown are IBM's suggested retail prices, are current and are subject
to change without notice. Dealer prices may vary.

668 Sterling Selling and Fulfillment Foundation: Application Platform Configuration Guide
This information is for planning purposes only. The information herein is subject to
change before the products described become available.

This information contains examples of data and reports used in daily business
operations. To illustrate them as completely as possible, the examples include the
names of individuals, companies, brands, and products. All of these names are
fictitious and any similarity to the names and addresses used by an actual business
enterprise is entirely coincidental.

COPYRIGHT LICENSE:

This information contains sample application programs in source language, which


illustrate programming techniques on various operating platforms. You may copy,
modify, and distribute these sample programs in any form without payment to
IBM, for the purposes of developing, using, marketing or distributing application
programs conforming to the application programming interface for the operating
platform for which the sample programs are written. These examples have not
been thoroughly tested under all conditions. IBM, therefore, cannot guarantee or
imply reliability, serviceability, or function of these programs. The sample
programs are provided "AS IS", without warranty of any kind. IBM shall not be
liable for any damages arising out of your use of the sample programs.

Each copy or any portion of these sample programs or any derivative work, must
include a copyright notice as follows:

© IBM 2011. Portions of this code are derived from IBM Corp. Sample Programs. ©
Copyright IBM Corp. 2011.

If you are viewing this information softcopy, the photographs and color
illustrations may not appear.

Trademarks

IBM, the IBM logo, and ibm.com® are trademarks or registered trademarks of
International Business Machines Corp., registered in many jurisdictions worldwide.
Other product and service names might be trademarks of IBM or other companies.
A current list of IBM trademarks is available on the Web at “Copyright and
trademark information” at http://www.ibm.com/legal/copytrade.shtml.

Adobe, the Adobe logo, PostScript, and the PostScript logo are either registered
trademarks or trademarks of Adobe Systems Incorporated in the United States,
and/or other countries.

IT Infrastructure Library is a registered trademark of the Central Computer and


Telecommunications Agency which is now part of the Office of Government
Commerce.

Intel, Intel logo, Intel Inside, Intel Inside logo, Intel Centrino, Intel Centrino logo,
Celeron, Intel Xeon, Intel SpeedStep, Itanium, and Pentium are trademarks or
registered trademarks of Intel Corporation or its subsidiaries in the United States
and other countries.

Linux is a registered trademark of Linus Torvalds in the United States, other


countries, or both.

Notices 669
Microsoft, Windows, Windows NT, and the Windows logo are trademarks of
Microsoft Corporation in the United States, other countries, or both.

ITIL is a registered trademark, and a registered community trademark of the Office


of Government Commerce, and is registered in the U.S. Patent and Trademark
Office.

UNIX is a registered trademark of The Open Group in the United States and other
countries.

Java and all Java-based trademarks and logos are trademarks or registered
trademarks of Oracle and/or its affiliates.

Cell Broadband Engine is a trademark of Sony Computer Entertainment, Inc. in the


United States, other countries, or both and is used under license therefrom.

Linear Tape-Open, LTO, the LTO Logo, Ultrium and the Ultrium Logo are
trademarks of HP, IBM Corp. and Quantum in the U.S. and other countries.

Connect Control Center®, Connect:Direct®, Connect:Enterprise®, Gentran®,


Gentran®:Basic®, Gentran:Control®, Gentran:Director®, Gentran:Plus®,
Gentran:Realtime®, Gentran:Server®, Gentran:Viewpoint®, Sterling Commerce™,
Sterling Information Broker®, and Sterling Integrator® are trademarks or registered
trademarks of Sterling Commerce™, Inc., an IBM Company.

Other company, product, and service names may be trademarks or service marks
of others.

670 Sterling Selling and Fulfillment Foundation: Application Platform Configuration Guide
Index
A API nodes 606
Application menu
business documents
classifying 294
Abort Processing on Error field 303 modifying 268 business models 1
access policies 210 application rules side panel 7 buyer documents 99, 101, 295
Account Number With Hub field 24, application versions Buyer Documents tab 99
107 creating 239 buyers 2, 28, 104
Action Code field 177 deleting 239 configuring data access 212
Action Group field 178 modifying 239 packaging parameters 51
Action Name field 68, 177 Applications Manager print format preferences 56
actions 176 actions 17
creating 176 Context-Sensitive Help 21
deleting 180
modifying 180
document types 18
entering dates/times 21
C
Active field 189 Calendar ID field 110
lists 20
adapter nodes 181, 182 calendar inheritance 109
lookup functionality 18
Administered By field 27 child calendar 109
special characters 22
Advanced XML Condition limitations 109
troubleshooting 22
Advanced XML field 174 parent calendar 109
users 20
Condition Cases field 174 calendars
layout 5
Condition Group field 174 creating an exception 112
starting 5
Condition ID field 174 defining an organization's 108
work area 14
Condition Name field 174 defining defaults 111
applicationversionandcode 238
Source View field 174 inheritance See also calendar
Apply SCM on all cases field 53
AdvancedXML field 172 inheritance 109
Apply SCM on all shipping units
Agent Criteria Group field 67 Call DB Extension field 179
field 53
Agent Server field 146 Call HTTP Extension field 179
Appointment Required field 41
Alert Console template 178 Call Java Extension field 179
asynchronous transport nodes 181
alert nodes 603 Can Enterprise Configure Event Handler
Attribute Location field 302
Alert Queue Name field 146, 602 field 154
Audit Queue field 306
alert queues 305 capacity consolidation level 229
Authority Type field 107
based on size 306 Capacity Organization Is field 94
Available field 189, 213
creating 305 capacity organizations 94
deleting 309 CAPACITYPRG purge rule 219
modifying 309 carrier documents 104, 106, 295
unassigned alerts 307 B Carrier Documents tab 104
unresolved alerts 308 Backup Protocol field 100, 102, 105 Carrier field 80
user list 308 backwards compatibility Carrier Service Code field 48
Alert Type field 602 order hold deprecated carrier services 57
alerts 35, 39, 305 functionality 231 Carrier/Service field 49, 61
Allow Chained Order Creation field 128 bar codes 227 carriers 29, 104
Allow Demand Updates For The Seller Base Currency field 263 defining attributes 57
Organization field 127 base document types 119 defining less-than truckload carrier
Allow Inventory Check During Schedule base repositories 132 services 60
And Release field 127 Base Transaction Name field 143 defining parcel carrier services 63
Allow Invoice Creation field 127 base transactions 140 defining truckload carrier
Allow Other Inventory Operations While Batch Sheet for picking 329 services 57
Physical Count Is On 89, 91 Billing Address field 189 roles
Allow Payment Processing field 127 Binding field 281 carriers 29
Allow Payment Processing flag 127 BOL Prefix field 67 Cart Manifest for picking 329
Allow Price Calculation For Confirmed Break Bulk Node field 49 catalog
Orders field 128 building index building 386
Allow Price Calculation For Draft Orders catalog index 386 Catalog Defined By field 93
field 127, 129 business communication components 4, catalog model 229
Allow Pro Forma Invoice Creation For 291 catalog organization 93
Shipments flag 127 business document codes 293 catalogs 93
Allow Propagation Of Changes To document format codes 292 Chained Document Type field 143
Derived Parent field 128 protocol codes 291 chained orders 74, 128
Allow Shipping Of Hazardous Materials business document codes Chained Procurement Purchase Order
field 59, 62, 65 creating 293 Document Type field 128
Allow Supply Updates For The Buyer deleting 294 Chained Procurement Transfer Order
Organization field 127 modifying 294 Document Type field 128
API Name field 279 Check Digit Determination field 81

© Copyright IBM Corp. 1999, 2011 671


Check for Prior Exception field 602 Cost Factor Group to be Used for date/time formats (continued)
child organizations Physical Kit Cost Calculations field 35 creating 259
viewing 108 Cost Factor Group to be Used for deleting 259
Class Name field 172, 179, 299 Standard Cost Calculations field 35, 39 modifying 259
Client Date Time Format field 266 cost factor preferences 34, 38 dates
Client Time Format field 266 Cost Factor Preferences tab 35, 38 calculations 69
Close Window On Complete field 282 count execution process type 120 Schedule date calculations 69
Code Description field 299 country or region Day Display Date Format field 266
Code Name field 299 locale 266 DCS 6.2 database node 551
Code Value API field 299 country or region codes defining defaults 551
common codes 286 creating 253, 355 error processing 551
communication 4 deleting 254, 356 interface tables 551
communication protocols 97 modifying 254, 355 sender 552
creating 97 Country/Region field 48, 314 DCS 6.2 database nodes
deleting 99 Create Reservation On Order Creation DCS 6.2 database receiver
modifying 98 field 127 properties 552
Compliance Service field 55 Create Shipments For Products Included DCS 6.2 database sender
compliance services 53 In Work Order field 128 properties 552
creating 54 currency conversions 262 receiver 552
deleting 56 creating 262 DCS 6.2 database receiver
modifying 55 deleting 264 properties 552
component nodes 181, 182, 603 modifying 263 DCS 6.2 database sender properties 552
composite service nodes 608 currency definitions 260 Default Declared Value field 67
condition builder 660 creating 260 Default Delivery Method Based On
using 172 deleting 261 Catalog field 126, 129
Condition Group field 172 modifying 261 Default Document Type Access
condition groups 172, 174 Currency field 266 field 205, 208
Condition ID field 172 custom common code types 286 Default Effective From field 110
Condition Name field 172 creating 286 Default Effective To field 110
condition nodes 608 deleting 287 Default Enterprise Access field 205, 207
Condition Properties field 172 modifying 287 Default Label Format 331
Condition Value field 172 custom common code values Default No of Copies field 34, 38, 57
conditions 170 deleting 288 defaulting component 615
creating 171 modifying 288 configuration properties 616
deleting 174 custom common codes Delay shipment by not more than
modifying 173 adding values to 287 field 42
viewing affected entities 175 custom error codes 289 Demand Type for Release field 127
configuration screens adding 289 Demand Type For Schedule field 126
accessing 8 deleting 290 demand types 126
configuration version labels modifying 290 Department Abbreviation field 114
creating 345 searching 289 Department Code field 41, 53, 188
deleting 346 Customer PO # field 41, 53 departments
modifying 346 creating 114
Connector node 181 deleting 115
console actions 281
console APIs 278
D modifying 115
viewing 114
data access policies 210
console entities 273 Derived Document Type field 143
data security component 617
console icons 282 derived transactions
custom validation 617
console inner panels 280 creating 163
enterprise validation 617
console links 282 detail view components
data security groups 204
console list views 277 anchor pages
configuring component 204
console related entities 274 defining 276
creating 204
console search view 275 device attributes 324
deleting 206
Consolidate New Order Releases device Attributes 324
modifying 206
field 128 Device ID 324
database nodes 547
Consolidate up to volume threshold of device sub types 324
database receiver properties 549
field 42 creating 319
database sender properties 547
Consolidate up to weight threshold of defining 319
database receiver properties 549
field 42 deleting 321
database sender properties 547
Consolidator field 48, 49 modifying 321
Date Format field 266
Constant field 303 device types 319, 324
date formats
Contact Address field 189 creating 317
creating 256
Conversion Rate From Base field 263 deleting 319
deleting 257
Conversion Rate To Base field 263 modifying 319
modifying 256
Corporate Address field 28 devices
Date Time Format field 266
Cost Factor Group to be Used for Landed creating 323
Date/Hour/Minute Format field 266
Cost Calculations field 35, 39 creating new from existing 326
date/time formats 258

672 Sterling Selling and Fulfillment Foundation: Application Platform Configuration Guide
devices (continued)
defining 321
enterprises (continued)
defining attributes (continued)
G
deleting 327 removing associated general base document type 119
device attributes organizations 33 general process type 120
setting up 324 print format preferences 34 Get Capacity Real Time field 94
modifying 327 Entity Key Name field 280 Get External Supply Real Time flag 88,
dimension unit of measure Entity Transformation 664 91
creating 241, 243, 244 error codes Get Inventory Real Time field 91
creating conversion rate 241, 243, 245 customizing 289 GLN field 67
deleting 242, 244, 246 Escalate Alert After field 307, 308 Group Description field 194
deleting conversion rate 242, 244, 246 Escalate If Number of Unresolved Alert Group ID field 194, 205
modifying 241, 243, 245 Exceeds field 307 Group Name field 194
modifying conversion rate 242, 244, Euro currency 260 Group Type field 194
245 Euro currency membership 260
Dimension UOM field 266 event handlers
Display Error Details field 196 defining 155 H
Distance Per Day field 59, 62, 65 Event ID field 154 Has Freezer field 59, 62, 65
Do not apply SCM field 53 Event Name field 154 Hide Maximum Records Field field 275
Do Not Generate field 80 events 143 Hide Navigation Panel field 276
Document Classification field 125, 129 adding to a transaction 153 Hide Title Bar field 277
document definitions 30 deleting 154 holds
Document Description 330 modifying 154 putting on 231
Document field 100, 102, 105 Events field 143 This Transaction Can Be Stopped
document format codes Exception Group field 602 From Processing Orders That Are
creating 292 exception handling 547, 601 On Hold 143
deleting 293 Exception Reference Name field 602 Host Code field 58, 61, 64
modifying 293 Exception Reference Value field 603 Hour/Minute Time Format field 266
document templates 130 Exception References tab 602 HP LaserJet 5P 319
Document Type field 122, 162, 225, 274 Exception tab 601 HTTP nodes 566
document types 120, 221 exchange rates 262 Hub 29, 133
configuring 119 Execute field 179
modifying description 123 Exemption Certificate field 107
saving as new 121
DocumentType attribute 274
Expedite shipment by not more than
field 42
I
draft orders 127, 129 Export License Number field 67 i18n tag 274
Driver Date field 125 EXPORTTBLPRG purge rule 219 Icon field 270
drop statuses 167 Extended Ship Mode field 58, 61, 64 Identified By Parent As field 67
adding 156 extended statuses Ignore Default API checkbox field 278
deleting 157 creating 167 Ignore Default API field 275, 276
Drop Statuses field 144 deleting 169 Implement As A Java Class field 162,
DUNS Number field 24, 27 modifying 168 225
Dynamic field 172 extended transactions 141 Implement As A Service field 162, 225
External Application field 68 IMPORTTBLPRG purge rule 219
Externally Generated field 80 In a Synchronous Mode field 184
In an Asynchronous Mode field 184
E externally-triggered transactions 140
Externally-triggered transactions inbound shipment process type 120
E-mail nodes 609 INBOXPRG purge rule 219
defining 144
E-mail Protocol field 230 index
E-mail Server IP Address field 230 catalog search 386
E-mail Server Listener Port field 230 Inherit Calendar definition field 110
E-mail Server Name field 230 F inheritance
E-mail template 179 File IO nodes 556 determining 8
Economic shipping parameters File IO receiver node properties 557 Inherited Document Type Access
maintained field 42 File IO sender nodes 556 field 208
Effective From field 263 File transfer protocol. See FTP 562 Inherited Enterprise Access field 208
Effective Period field 112 Fixed Transit Days field 58, 61, 65 initial context factory codes 234
Effective To field 263 Format field 100, 102, 105 creating 235
EJB nodes 554 From field 48 deleting 235
Electronic Code field 58, 61, 64 From Node field 75 modifying 235
end nodes 183 From Organization field 301 Initial Context Factory field 147
End Time field 110, 112 From System field 301 Input Key Name field 282
Enterprise Code field 54 FTP (File Transfer Protocol) 562 Input Name Space field 281
enterprises 2, 29, 30 FTP nodes 562 installation rules 226
defining attributes 31 FTP receiver properties 564 Integration Service field 100, 103, 105
adding organizations 32 FTP sender properties 562 internationalization rules 253
modifying associated country or region codes 253
organizations 33 currency conversions 262
currency definitions 260

Index 673
internationalization rules (continued)
date formats 256
load execution process type 120
locale
N
date/time formats 258 country or region 266 Name field 98
language codes 254 ISO-3166 code 266 No. of Threads field 146
time formats 257 ISO-639 code 266 Node field 49
inventory consolidation levels 228 language 266 node properties
inventory costing factors 34, 38 Locale Code field 188, 266 configuring 185
Inventory Monitor Rules tab 35, 39 Locale Description field 266 Node Type field 67
inventory monitoring rules 35, 39 Locale field 24, 27 nodes 30
Inventory Organization Is field 91 locales 265 configuring user access 214
inventory organizations 91 creating 265 defining attributes 66
INVENTORYPRG purge rule 219 deleting 267 defining LTL carrier
invoices modifying 267 preferences 78
Pro Forma 127 Loftware Label Manager 331 defining node operations 68
Invoke a Service field 278 Log Audits For Draft Order field 126, defining parcel carrier
Invoke an API field 279 129 preferences 71
Invoke following services as part of this Log File Name field 221 defining primary information 66
action field 178 LTL (Less-than Truck Load) 60 defining PRO Number 78
Invoked Services List field 178 LTL carrier preferences defining roles
Is Active field 154 nodes 78 defining node advanced
Is Reprocessible field 602 attributes 87
Is Supervisor field 189 roles
nodes 30
ISO-3166 code 266
ISO-639 code 266
M nomenclature 4
Maintain Inventory Cost field 68 nomenclature configuration
Issuing Authority field 107
Maintained Externally field 44 defining 300
Item Classification field 55
Mandate Serial information for serialized nomenclature definitions
Item ID field 53
items field 52 creating a mapping between 299
Mandate tag information for all tag Nomenclature field 303
controlled items field 52 nomenclature runtime components 297
J manifesting process type 120 nomenclature definitions 299
jasper printer component 618 MANIFESTPRG purge rule 219 Nomenclature runtime nodes 611
auditing 618 Mapping Type field 303 nomenclature transformation engine 297
configuration properties 619 Mapping XML File Name 334 Non-working day 113
variable file names 619 Mark For field 41, 53 Not Maintained field 43
Java Class field 162, 225 marketplaces 2, 29 Notification Service field 81
Java Server Page field 275, 276, 277, 280 master order fulfillment process Notification Threshold field 81
JavaScript field 281 type 120
JMS Queue Name field 146 Max Customer Assignments field 189
JMS Security 148, 571, 575, 580, 583, 588,
590, 594, 597
Maximum Length Of Ship Advice
Number field 233
O
JMS security properties 149 menu configuration 267 Only when receiving 88
JBoss 150, 151 defining menu items 269 Only when shipping, if the buyer
WebSphere 150 modifying application menu mandates 88
JMS security properties (Queue-based) details 268 opportunity base document type 119
WebLogic 150 saving a menu group as a new menu Order # field 41
jsp list 273 grouping 267 order base document type 119
JSP tag library Menu group 188 Order Creation Tab field 125
i18n 274 Menu Group field 188 order fulfillment process type 120
menu groups 267 order holds
Menu groups deprecated functionality 231
order negotiation process type 120
L saving as a new grouping 267
Menu ID field 269 order pipeline 231
Label Format field 34, 38, 57 Org Suffix 27
menu items
Label Format File Name 334 Organization Code field 24, 299
creating 269
Label Format Name 334 Organization Defines Its Own Catalog
deleting 271
language field 93
modifying 270
locale 266 Organization Is An Enterprise field 24
menu sequence 270
language codes organization levels 8
Menu Sequence field 270
creating 255 rules 10
monitor rule types 137
deleting 256 Organization Name field 24
Monitoring rules
modifying 255 organization rules 10
defining 136
Language field 266 loading another organization's
Month Display Date Format field 266
legal entity 27 rules 13
Move Alert To Different Queue
Legal Entity field 27 overriding 11
field 307, 308
less-than truckload. See LTL 60 organizational hierarchies 116
move request execution process
License Expiration Date field 67 adding organizations to 116
type 120
load base document type 119 creating 116
multi-divisional corporations 1, 29

674 Sterling Selling and Fulfillment Foundation: Application Platform Configuration Guide
organizational hierarchies (continued) outbound shipment process type 120 print format preferences
removing organizations from 116 Output Name Space field 275, 276, 277 defining 34, 37, 56
organizations over pack build process type 120 Printer ID 192, 203
assigning participant associations 28 OverPick For Voice Based Tasks 89 printers 319
assigning roles 28 Override Entity ID field 280 prints
communication protocols 97 Override Freight Terms field 49 defining 329
creating 97 Override Modification Rules field 196 label formats
deleting 99 Override Ship To field 49 creating 332
modifying 98 defining 332
communication standards deleting 334
buyer documents 99, 101
carrier documents 104, 106
P modifying 334
Loftware
pack process process type 120
communication protocols 97 label formats 332
Package Level Integration field 59, 62,
creating 99, 102, 104 mapping XML file 332
65
deleting 101, 103, 106 Loftware Label Manager 332
packaging parameters 51
modifying 101, 103, 106 printer - station association 190, 201
Packing 89
seller documents 101, 102, 103 printer preferences
packing slip 329
creating 23 setting up 190
Parameter Name 325
defining calendars 108 users 190
Parameter Name field 149
creating an exception 112 user printer preferences
Parameter Value 325
defining defaults 111 defining 190, 201
Parameter Value field 149
defining payment information 106 Prior Errors User Exit field 602
parcel carrier preferences 73
defining primary information 26 Priority field 49
nodes 71
defining roles Pro Forma invoices 127
parcels 63
adding associated PRO Number End field 80, 81
Parent Organization field 27
organizations 32 Pro Number Generation Scheme field 80
Parent Team ID field 207
defining carrier attributes 57, 60, PRO Number Prefix field 80
participant modeling 2
63 PRO Number Set - 1 field 80
creating an organization 23
defining Carrier attributes 57 PRO Number Set - 2 field 80
participants 23
defining enterprise attributes 31, PRO Number Sets field 80
pass-through nodes 183
32, 33 PRO Number Start field 80
Password field 188
defining less-than truckload carrier process modeling 3, 119
Password Policy field 189
services 60 process modeling tree
payment information
defining LTL carrier viewing 121
defining an organization's 106
preferences 78 Process Type field 125
permissions 194
defining node attributes 66, 68, Process Type Name field 125
list of users 195
71, 78 process type pipelines 132
PERSONIFOPRG purge rule 219
defining node operations 68 process types 3, 120, 123
PERSONINFOHISTPRG purge rule 219
defining parcel carrier count execution 120
pickup statuses 167
preferences 71 defining primary information 124
adding 155
defining primary information 66 defining templates 130
deleting 156
defining seller attributes 37, 40 general 120
pickup Statuses field 144
defining truckload carrier inbound shipment 120
pipeline determination 132
services 57 load execution 120
pipelines
modifying associated manifesting 120
creating 133
organizations 33 master order fulfillment 120
defining monitoring rules 136
removing associated move request execution 120
modifying 135
organizations 33 order fulfillment 120
planned order execution process
setting up parcel carrier order negotiation 120
type 120
services 63 outbound picking 120
planned order negotiation process
departments outbound shipment 120
type 120
creating 114 over pack build 120
Postal Codes Define This Region
deleting 115 pack process 120
field 315
modifying 115 planned order execution 120
presentation 3
modifying 115 planned order negotiation 120
PRICELISTPRG purge rule 219
setting up roles purchase order execution 120
Pricing
setting up carrier preferences 34, purchase order negotiation 120
defining 95
38 purchase order receipt 120
Pricing organization 8, 10
setting up enterprise quote fulfillment 120
Primary Enterprise field 25
attributes 34, 35, 38, 39 return receipt 120
primary enterprises 31, 97
setting up inventory monitoring return shipment 120
Primary URL field 27
rules 35, 39 reverse logistics 120
Print Document field 34, 38, 57
viewing child organizations 108 task execution 120
print documents 330
viewing departments 114 template order 120
creating 330, 337, 340, 341
Other Currency field 263 trailer loading 120
deleting 331, 339, 341, 344
Other tab 142 transfer order delivery 120
modifying 331, 339, 340, 342
outbound picking process type 120 transfer order execution 120

Index 675
process types (continued)
transfer order receipt 120
R reverse logistics process type 120
RF Scanners 319
VAS process 120 Raise Action field 307, 308 roles
WMS inventory 120 Re-Alert After field 307, 308 assigning to a yard 97
WMS layout definition 120 Receipt Processing Time (Hours) assigning to an organization 30
WMS putaway 120 field 70 buyers 28
Procure To Ship Allowed field 69 Receipt Processing Time for Forwarding multiple organizations 30
procurement 69 (Hours) 70 organization 28
chained orders 69 receiver 182 sellers 30
purchase orders 69 Receiving 89 Rollback Segment field 220
transfer orders 69 Receiving Calendar field 70 router nodes 612
Procurement Placed Supply Type Redirector View field 277 routing guide lines
field 127 region definition 4 creating 46
procurement purchase orders 128 region definitions 311 definition 46
procurement transfer orders 128 region levels 311 deleting 50
Product Class field 53 region schemas 313 modifying 49
Program field 179 regions 314 routing guides 43
protocol codes 291 Region Level Name field 312 creating 44
creating 291 region levels deleting 45
deleting 292 creating 311 fields 43
modifying 291 deleting 312 modifying 45
Protocol field 98, 100, 102, 105 modifying 312 VICS 43
Provider URL field 148 Region Name field 314 Run Quantity field 55
Publish Data field 179 Region Schema For Routing field 43 Runtime ID field 600
purchase order execution process Region Schema Name field 314 Runtime tab 600
type 120 region schemas
purchase order negotiation process creating 313
deleting 316
type 120
purchase order receipt process type 120 modifying 315 S
regions Save Directory 331
Purge Code field 220
creating 314, 315 SCM not required field 52
purge criteria 219
deleting 315 SCM required with content field 53
modifying the system's 219
related entity 275 SCM required without content field 53
purges 219
Related Entity field 275 security 3, 187
repositories 132 data access policies 210
REPROCESSPRG purge rule 219 security management 187
Q Requested Delivery Date field 125 Select Algorithm field 81
QCF Lookup field 147 Requested Ship Date field 125 Selection Key Name field 281
qualified tag types Requires Backward Compatibility seller 101
creating 349 field 154, 162, 225 seller documents 102, 103, 295
deleting 350 Resource ID 270 Seller Documents tab 102
modifying 350 Resource ID field 270, 272 sellers 2, 30, 104
qualified tag version compatibility Resource Identifier 27 configuring data access 214
configuring 352 Resource Planning Enabled field 67 defining attributes 37
deleting 353 Resource Sequence field 273 print format preferences 37
modifying 353 resource sequencing 273 Send E-Mail field 179
qualified tags Resource Type field 273 Send Fax field 179
creating 351 resources 271 Send to Alert Console field 178
deleting 352 console actions 281 sender 182
modifying 351 console APIs 278 Server Name field 601
Queue Description field 306 console detail views Server tab 601
Queue ID field 306 console detail views 276 service definitions 180, 222
queue management 4, 317, 329, 335, 337, console entities 273 creating 183
349 viewing jsp list 273 Service Description field 58, 61, 64
Queue management 305 viewing user list 273 Service Group Name field 178, 184
Queue Name field 178, 306, 600 console icons 282 Service Name field 162, 178, 184, 225,
Queue Priority field 306 console inner panels 280 278
queues 305 console links 282 service nodes 181
based on size 306 console list views 277 Set up data for System Generated scheme
creating 305 console related entities 274 field 80
deleting 309 console search view 275 Shift Name field 110, 112
modifying 309 Restrict Access To A Specific List Of Shift Valid For field 112
unassigned alerts 307 Enterprises field 205, 208 shifts 70, 110
unresolved alerts 308 Restrict List To A Specific List Of Ship By Air field 59, 62, 65
user list 308 Document Types field 205, 208 Shipment Level Integration field 59, 62,
quote fulfillment process type 120 Retention Days field 220 65
defining primary information 128, return receipt process type 120 Shipping 89
129 return shipment process type 120 Shipping Calendar field 70

676 Sterling Selling and Fulfillment Foundation: Application Platform Configuration Guide
shipping labels 329 third-party logistics 29 transactions (continued)
Skip Automatic Execution field 279 nodes 67 time-triggered 141
sourcing region selection third-party logistics models 2 defining 145
defining 357 Third-party logistics models 2 user-triggered 141
Spawning process type field 143 This Organization Is A Capacity transfer order delivery process type 120
Spawns another process? field 143 Organization field 94 transfer order execution process
start nodes 182 This Organization Is An Inventory type 120
Start Time field 110, 112 Organization field 91, 92 transfer order receipt process type 120
State field 48 This Region Level Can Be Defined By A transfer orders 74
Static field 172 Set Of Postal Codes field 312 transfer schedules 74
STATISTICSPRG purge rule 219 This Service Provides Real-Time Response transport nodes 181, 547
status change listeners field 184 truckloads 57
creating 163 This Transaction Can Be Stopped From
status monitoring rule 169 Processing Orders That Are On Hold
status monitoring rule definitions
defining 169
field 143
This Transaction Is Derived From
U
UCC-128 329
statuses 167, 231 Abstract field 143
Unit Of Measure field 53
Sterling WMS 68 This transaction is task based field 143
UOMs (Units of Measure)
Store# field 48, 49 Time 346
modifying 241
Stored Procedure field 179 Time Format field 266
UPS Standard carrier labels 329
Subscribed field 190, 213 time formats
URL field 179
Substitution Is Allowed field 70 creating 257
Use as a Template Order field 125
Supports Integration for Return Shipping deleting 258
Use Default Values field 303
Label field 59 modifying 258
Use End Of Shift Time field 70
Suspend API field 602 time unit of measure
Use Numeric Ship Advice Number
Suspend Wait Time field 602 creating 250
flag 233
synchronous MQSeries nodes 570, 596 creating conversion rate 250
Use Template Order For Defaulting
synchronous transport nodes 181 deleting 251
field 126
synchronous WebLogic nodes 570 deleting conversion rate 251
Use units of measure from buyer catalog
System Generated field 80 modifying 250
field 52
System ID field 179 modifying conversion rate 251
user 187
System Name field 298 Time Zone field 266
configuring data access 210
time-triggered transactions 141
creating and modifying 187
defining 145
deleting 192
T To field 48
To Node field 75
User Exit Implementation Notes
task execution process type 120 field 163, 226
To Organization field 301
Tax Exempt field 107 user exit implementations
To System field 301
Tax Jurisdiction field 107 defining 223
trailer loading process type 120
Tax Payer ID field 107 user exits 159, 221
transaction completion 157
Team field 189 user groups 193
events 159
Team ID field 207 administering resource
status based transactions 157
teams 189, 206 permissions 194
supported transactions
creating 207 creating and modifying 193
custom 157
deleting 210 deleting 203
extended 157
modifying 209 viewing subscribed users 201
Transaction ID field 142
Template Document Type field 126 User ID field 178, 188
Transaction Name field 142
Template field 178, 179 user interface extensibility 3
transactions 119, 140
template order process type 120 user list 273
adding events 153
templates 130 User Name field 188
creating 141
text translator components user-triggered transactions 141
creating a derived transaction 163
schema files 625 defining 152
creating a status change listener 163
XSD files 624 USERACTAUDITPRG purge rule 219
defining as externally-triggered 144
delimited receiver 632 USERACTIVITYPRG purge rule 219
defining as user-triggered 152
delimited sender 636
defining event handlers 155
positional receiver 628
deleting 166
positional sender 634
text translator file formats
deleting an event 154 V
drop statuses Validate Item During Order Creation/
delimited 623
adding 156 Modification field 125, 129
positional 623
deleting 157 Value field 98
XML 624
externally-triggered 140 Variant field 266
text translator nodes 613
managing user exits 159 VAS process type 120
Theme field 189, 285
modifying 166 Version field 162, 225
themes 284
modifying an event 154 Version Label Id 346
creating 284
pickup statuses Version Label Id Description 346
deleting 285
adding 155 VICS 43
modifying 285
deleting 156 VICS Bill Of Lading (BOL) 329
Third Party Logistics Node field 67

Index 677
View Group ID field 276, 277, 278, 281
View ID field 281
View Values field 299
volume unit of measure
creating 246
creating conversion rate 247
deleting 248
deleting conversion rate 248
modifying 247
modifying conversion rate 247
Volume UOM field 266

W
wave release prints document set 329
WebServices nodes 567
weight unit of measure
creating 248
creating conversion rate 249
deleting 250
deleting conversion rate 249
modifying 248
modifying conversion rate 249
Weight UOM field 266
When Agent/Integration Server
Terminates Unexpectedly field 236,
238
When Application Server Goes Down
field 236
When Monitoring Threshold Reached or
Exceeded field 236
When performing any node
operation 88
WMS 6.2 field 68
WMS inventory process type 120
WMS layout definition process type 120
WMS putaway process type 120
Work Day Hours field 67
Work Order Creation Is Allowed
field 70
workflows 119
working days 113
Works based on data from field 143
Write to Log File field 220

X
XML binding 281, 283
XML Name field 301, 302
XML templates 130
XSL translator nodes 614

Z
Zebra 170 319
Zip Code field 48

678 Sterling Selling and Fulfillment Foundation: Application Platform Configuration Guide


Printed in USA

You might also like