IP Library Granted Patent US 9,373,094
Granted Patent B2
US 9,373,094 · App. 14/182,218 · Granted Jun 21, 2016

Dynamic web services system and method

Inventors: Vishal Chalana (Panchkula, IN); Amit Sharma (Chandigarh, IN); Piyush Nagar (Chandigarh, IN); Vishal Sharma (Meerut, IN); Vikram Chalana (Bothell, WA)
Assignee: Winshuttle, LLC
G06Q10/06G06F9/541H04L47/748
View Patent ↗
Loading inventors, assignments & file history…
Monitor This Case
Get email alerts when status or documents change.
Order Certified Copies
Most orders are placed with the USPTO same day — all within 24 business hours.
Order via The Patent Place →
Pre-filled with this patent's details
Quick Facts
Patent No.
US 9,373,094
App. No.
14/182,218
Granted
Jun 21, 2016
Kind
B2
Abstract

A Dynamic Web Service server may facilitate custom Enterprise Application interface development with little or no developer input by dynamically creating a web service for performing a particular transaction according to a transaction map. An Enterprise Application client device may create a transaction map by “recording” a transaction between an Enterprise Application client and an Enterprise Application server and mapping transaction fields to a custom interface generated to collect data for re-performing the recorded transaction. The Enterprise Application client device may call the dynamic web service, and the Dynamic Web Service server may then perform the recorded transaction using input data collected in the custom interface.

Claims (84)

1. A dynamic-web-services-server-implemented method for publishing a dynamic web service, the method comprising:

receiving, by said dynamic-web-services server from a first enterprise-resource-planning client, a recorded transaction map describing a recorded transaction between said first enterprise-resource-planning client and an enterprise-resource-planning server, said recorded transaction map including metadata corresponding to a plurality of transaction fields;

generating, by said dynamic-web-services server, a service description framework for a new dynamic web service corresponding to said recorded transaction, including for each of said plurality of transaction fields, defining an input corresponding to the current transaction field and storing said defined input in said service description framework;

determining, by said dynamic-web-services server, a unique service identifier for invoking said new dynamic web service;

persisting, by said dynamic-web-services server, said unique service identifier, said service description framework, and said recorded transaction map in a data store;

receiving, by said dynamic-web-services server, a first request from a second enterprise-resource-planning client to invoke said new dynamic web service according to a package of input data, said first request indicating said unique service identifier, said package of input data being received in a first format according to a first calling mechanism;

retrieving, by said dynamic-web-services server, said recorded transaction map from said data store according to said unique service identifier;

according to said recorded transaction map, determining, by said dynamic-web-services server, at least one Enterprise Application API call for performing said recorded transaction, said at least one Enterprise Application API call requiring a second calling mechanism, different from said first calling mechanism;

repackaging, by said dynamic-web-services server, said package of input data in said first format into repackaged input data in a second format that complies with said second calling mechanism; and

invoking, by said dynamic-web-services server, an Enterprise Application server to perform said recorded transaction according to said second calling mechanism, said at least one Enterprise Application API call, and said repackaged input data.

2. The method of claim 1 , further comprising:

receiving a second request from said first enterprise-resource-planning client or said second enterprise-resource-planning client for said service description framework, said second request indicating said unique service identifier;

retrieving said service description framework from said data store according to said unique service identifier; and

sending said service description framework to said first enterprise-resource-planning client or said second enterprise-resource-planning client.

3. The method of claim 1 , further comprising:

receiving from said enterprise-resource-planning server process output data corresponding to the invocation of said enterprise-resource-planning server;

packaging said process output data according to said first calling mechanism into packaged process output data; and

providing said packaged process output data to said first enterprise-resource-planning client or said second enterprise-resource-planning client.

4. The method of claim 1 , wherein performing said recorded transaction according to said package of input data comprises invoking said at least one Enterprise Application API call according to said second calling mechanism and said repackaged input data.

5. The method of claim 1 , wherein:

said first calling mechanism comprises Simple Object Access Protocol (“SOAP”);

said first format comprises Extensible Markup Language (“XML”); and

said second calling mechanism comprises a remote function call (“RFC”).

6. The method of claim 1 , wherein:

said first calling mechanism conforms to Representational State Transfer (“REST”) constraints and uses HTTP methods; and

said second calling mechanism comprises a remote function call (“RFC”).

7. The method of claim 1 , wherein causing said recorded transaction to be invoked comprises invoking an Enterprise Application server to perform said recorded transaction.

8. The method of claim 1 , wherein said first request is received via a transaction client software process on said second enterprise-resource-planning client.

9. A computing apparatus for publishing a dynamic web service, the apparatus comprising a processor and a memory storing instructions that, when executed by the processor, configure the apparatus to:

receive, from a first enterprise-resource-planning client, a recorded transaction map describing a recorded transaction between said first enterprise-resource-planning client and an enterprise-resource-planning server, said recorded transaction map including metadata corresponding to a plurality of transaction fields;

generate a service description framework for a new dynamic web service corresponding to said recorded transaction, including for each of said plurality of transaction fields, defining an input corresponding to the current transaction field and storing said defined input in said service description framework;

determine a unique service identifier for invoking said new dynamic web service;

persist said unique service identifier, said service description framework, and said recorded transaction map in a data store;

receive a first request from a second enterprise-resource-planning client to invoke said new dynamic web service according to a package of input data, said first request indicating said unique service identifier, said package of input data being received in a first format according to a first call mechanism;

retrieve said recorded transaction map from said data store according to said unique service identifier;

according to said recorded transaction map, determine at least one Enterprise Application API call for performing said recorded transaction, said at least one Enterprise Application API call requiring a second call mechanism, different from said first call mechanism;

repackage said package of input data in said first format into repackaged input data in a second format that complies with said second call mechanism; and

invoke an Enterprise Application server to perform causing said recorded transaction according to said second call mechanism, said at least one Enterprise Application API call, and said repackaged input data.

10. The apparatus of claim 9 , wherein the memory stores further instructions that further configure the apparatus to:

receive a second request from said first enterprise-resource-planning client or said second enterprise-resource-planning client for said service description framework, said second request indicating said unique service identifier;

retrieve said service description framework from said data store according to said unique service identifier; and

send said service description framework to said first enterprise-resource-planning client or said second enterprise-resource-planning client.

11. The apparatus of claim 9 , wherein the memory stores further instructions that further configure the apparatus to:

receive from said enterprise-resource-planning server process output data corresponding to the invocation of said enterprise-resource-planning server;

package said process output data according to said first call mechanism into packaged process output data; and

provide said packaged process output data to said first enterprise-resource-planning client or said second enterprise-resource-planning client.

12. The apparatus of claim 9 , wherein perform said recorded transaction according to said package of input data comprises invoking said at least one Enterprise Application API call according to said second call mechanism and said repackaged input data.

13. The apparatus of claim 9 , wherein:

said first call mechanism comprises Simple Object Access Protocol (“SOAP”);

said first format comprises Extensible Markup Language (“XML”); and

said second call mechanism comprises a remote function call (“RFC”).

14. The apparatus of claim 9 , wherein:

said first call mechanism conforms to Representational State Transfer (“REST”) constraints and uses HTTP methods; and

said second call mechanism comprises a remote function call (“RFC”).

15. The apparatus of claim 9 , wherein causing said recorded transaction to be invoked comprises invoking an Enterprise Application server to perform said recorded transaction.

16. The apparatus of claim 9 , wherein said first request is received via a transaction client software process on said second enterprise-resource-planning client.

17. A non-transient computer-readable storage medium having stored thereon instructions that, when executed by a processor, configure the processor to:

receive, from a first enterprise-resource-planning client, a recorded transaction map describing a recorded transaction between said first enterprise-resource-planning client and an enterprise-resource-planning server, said recorded transaction map including metadata corresponding to a plurality of transaction fields;

generate a service description framework for a new dynamic web service corresponding to said recorded transaction, including for each of said plurality of transaction fields, defining an input corresponding to the current transaction field and storing said defined input in said service description framework;

determine a unique service identifier for invoking said new dynamic web service;

persist said unique service identifier, said service description framework, and said recorded transaction map in a data store;

receive a first request from a second enterprise-resource-planning client to invoke said new dynamic web service according to a package of input data, said first request indicating said unique service identifier, said package of input data being received in a first format according to a first call mechanism;

retrieve said recorded transaction map from said data store according to said unique service identifier;

according to said recorded transaction map, determine at least one Enterprise Application API call for performing said recorded transaction, said at least one Enterprise Application API call requiring a second call mechanism, different from said first call mechanism;

repackage said package of input data in said first format into repackaged input data in a second format that complies with said second call mechanism; and

invoke an Enterprise Application server to perform said recorded transaction to be performed according to said second call mechanism, said at least one Enterprise Application API call, and said repackaged input data.

18. The storage medium of claim 17 , having stored thereon further instructions that further configure the processor to:

receive a second request from said first enterprise-resource-planning client or said second enterprise-resource-planning client for said service description framework, said second request indicating said unique service identifier;

retrieve said service description framework from said data store according to said unique service identifier; and

send said service description framework to said first enterprise-resource-planning client or said second enterprise-resource-planning client.

19. The storage medium of claim 17 , having stored thereon further instructions that further configure the processor to:

receive from said enterprise-resource-planning server process output data corresponding to the invocation of said enterprise-resource-planning server;

package said process output data according to said first call mechanism into packaged process output data; and

provide said packaged process output data to said first enterprise-resource-planning client or said second enterprise-resource-planning client.

20. The storage medium of claim 17 , wherein perform said recorded transaction according to said package of input data comprises invoking said at least one Enterprise Application API call according to said second call mechanism and said repackaged input data.

21. The storage medium of claim 17 , wherein:

said first call mechanism comprises Simple Object Access Protocol (“SOAP”);

said first format comprises Extensible Markup Language (“XML”); and

said second call mechanism comprises a remote function call (“RFC”).

22. The storage medium of claim 17 , wherein:

said first call mechanism conforms to Representational State Transfer (“REST”) constraints and uses HTTP methods; and

said second call mechanism comprises a remote function call (“RFC”).

23. The storage medium of claim 17 , wherein causing said recorded transaction to be performed comprises invoking an Enterprise Application server to perform said recorded transaction.

24. The storage medium of claim 17 , wherein said first request is received via a transaction client software process on said second enterprise-resource-planning client.

Assignments (9)
MERGER Recorded May 13, 2025
From: WINSHUTTLE, LLC
To: PRECISELY SOFTWARE INCORPORATED
Reel/Frame 071094/0984 →
RELEASE OF SECURITY INTEREST Recorded Aug 17, 2022
From: WINSHUTTLE, LLC
To: WINSHUTTLE, LLC
Reel/Frame 060829/0770 →
RELEASE OF SECURITY INTEREST RECORDED AT REEL/FRAME 50009/0537 Recorded Jul 14, 2021
From: OBSIDIAN AGENCY SERVICES, INC.
To: WINSHUTTLE, LLC
Reel/Frame 057106/0836 →
SECOND LIEN INTELLECTUAL PROPERTY SECURITY AGREEMENT Recorded Jul 13, 2021
From: WINSHUTTLE, LLC; ENTERWORKS ACQUISITION, INC.
To: BARLCAYS BANK PLC, AS COLLATERAL AGENT
Reel/Frame 056847/0075 →
FIRST LIEN INTELLECTUAL PROPERTY SECURITY AGREEMENT Recorded Jul 13, 2021
From: WINSHUTTLE, LLC; ENTERWORKS ACQUISITION, INC.
To: JPMORGAN CHASE BANK, N.A., AS COLLATERAL AGENT
Reel/Frame 056846/0892 →
TERMINATION AND RELEASE OF PATENT SECURITY AGREEMENT Recorded Aug 12, 2019
From: PNC BANK, NATIONAL ASSOCIATION
To: WINSHUTTLE, LLC
Reel/Frame 050028/0566 →
SECURITY INTEREST Recorded Aug 9, 2019
From: WINSHUTTLE, LLC
To: OBSIDIAN AGENCY SERVICES, INC., AS COLLATERAL AGENT
Reel/Frame 050009/0537 →
SECURITY INTEREST Recorded May 2, 2018
From: WINSHUTTLE, LLC
To: PNC BANK, NATIONAL ASSOCIATION
Reel/Frame 045694/0500 →
ASSIGNMENT OF ASSIGNOR'S INTEREST Recorded Mar 26, 2014
From: CHALANA, VISHAL; SHARMA, AMIT; NAGAR, PIYUSH; SHARMA, VISHAL; CHALANA, VIKRAM
To: WINSHUTTLE, LLC
Reel/Frame 032536/0350 →
Continuity (4)
Continuation 13666344 · Nov 1, 2012
Continuation 13016704 · Jan 28, 2011
Provisional Application 61334099 · May 12, 2010
Related Publication 20140164497A1 · Jun 12, 2014